01-11-2012
07:24 AM
- last edited on
04-25-2025
05:49 PM
by
Content Cleaner
Note that adding extra Y-axes to your graph may cost you performance. Whether this is a problem or not will depend on how many Y-axes and how many data points you are plotting. If you are plotting more than a few thousand points, you may want to do some benchmarking and/or look into decimation for display.
01-11-2012 07:31 AM
Found here.
Ben
01-11-2012 08:09 AM
Dear DFGray,
Performance is a critical issue and thats the reason i went for Labview. We need to recieve the samples from a third party device along with its historical storage in Citadel at maximum sample rate of 100ms per sample. However i assume that the Citadel will be taking the values directly from network variables using Shared Variable Engine.
So do you think if i create 10 plots in one graph and assuming the x-axis range of 30 mins, the total samples are 18000, it will create some CPU load which might make me compromise on the 100ms sample rate ?
Cheers
01-11-2012 08:10 AM
Exactly 🙂 This is what the customer wants. An 82" screen !! and im not joking
01-11-2012 08:44 AM
@Turri wrote:
Exactly 🙂 This is what the customer wants. An 82" screen !! and im not joking
Is tht all?
This app was designed to run on a pair of 40 inch displays and it ran fine (note: not DSC)
Regarding your performance requirements.
I recomend you work-up a quick test to see if you get the performance you require.
In the old days of BridgeVIEW I could state that the tag engine scaled well and handled high tag counts well ( was it 4000 tags from PLCs...?) but with the new SV version, I have never seen benchmarks or whitpapers on this subject so...
Test the extreme up front before investing a lot of time building on a horse that can't pull that plow.
Ben
01-12-2012 08:17 AM - edited 01-12-2012 08:19 AM
18,000 samples total is a fairly modest amount. I usually start to worry about one million. Plotting the points should not be an issue. I would gather them in one loop and plot in another (use producer/consumer architecture to do this - producer is read, consumer is plot). This will allow LabVIEW to thread optimize the operations.
This assumes a relatively modern computer. You can probably pull it off with an 800MHz machine, but would need to be very careful. From you description, it sounds like getting the data will probably be your bottleneck (I will also admit I am almost always wrong about bottlenecks - that's why I benchmark a lot).