Jump to content

Refreshing main.vi graph from subvis...


Recommended Posts

Hello everybody.

I'm working on a big code, using lots of subvis for acquisition, signal processing etc...

I have been inspired by the DAQ Reference Design for architecture.

My goal is to find the best(fast) way to update a graph in the main vi front panel from other subvis.

I think there is at least those possibilities :

- send data to plot through a global variable and read and plot it in the main

- using references of the graphs in the main and update graph using Value reference node in the sub vi (my actual solution)

Maybe there are others ways.... My problem is that updating 2 XY plots from a subvi (one with a spectrum, let's say its 20000 points) and another one with a time trace (100 points) using references takes 100 - 200 ms.

So it's very slow compared to the rate at which datas are arriving.

Maybe there is a more clever / efficient way to do so ?

Any help would be greatly appreciate !!

Thanks

Link to comment

My goal is to find the best(fast) way to update a graph in the main vi front panel from other subvis.

They are a bit weird to work with, but you might consider subpanels. Then you can have your graph in the subvi, which is great for debugging, and show the panel in the main VI with no extra programming.

However if your data is coming from different acquisition VIs and aggregated in the graph it may be the right solution.

Link to comment

There are alternative methods such as sending the data via queues and using a database amongst others. It really depends on how fast (what is the acquisition rate?) and how fresh he data needs to be (would the user really see if data was delayed 100ms as long as it was continuous). Besides. There are not enough pixels on a screen to represent 20,000 data points, so you don't need all of them to display to the user.

Of the two choices you have given, I would probably go for the global with a single write and limited readers (data-pool). That is the old method before things like queues/events and doesn't limit you to running the acquisition in the UI thread. But queues are the most commonly used since they also break the coupling between the UI and the acquisition and are very efficient. There are some examples shipped with LabVIEW that demonstrate this technique for waveforms.

Link to comment

Thanks for those comments.

I didn't think about subpanel, cause i thought it was a bit dirty to do that...

Anyway I made this code, is it a good way to test those different solutions ?

I get the following results while benchmarking it :

1k iterations give me :

1000 ms for direct plotting

8000 ms for reference plotting

1900 ms for subpanel...

So subpanel seems a great solution !

Am I doing it right ?

Thanks again !

Test_refDirectSubpanel.zip

Link to comment

As ShaunR pointed out, 20000 points are too much to display - simply there are no monitors with that many pixels. :blink:

Furthermore, the human eye will see as continuous anything refreshed faster than 16 Hz, so it's pointless to update the display at any faster rate than that - it's simply a waste of time and valuable computer resources.

Except for very display sensitive applications (multi-media, simulation and very few others) simply just use the most practical method to display for your case (refs, sub-panels, queues, globals, functional globals, etc., it depends on what you're doing and how), decimate data AND updated displays only every 60 msec - 50 if you really cannot settle for less - but even 100 msec should be enough.

Link to comment

As ShaunR pointed out, 20000 points are too much to display - simply there are no monitors with that many pixels. :blink:

Furthermore, the human eye will see as continuous anything refreshed faster than 16 Hz, so it's pointless to update the display at any faster rate than that - it's simply a waste of time and valuable computer resources.

Except for very display sensitive applications (multi-media, simulation and very few others) simply just use the most practical method to display for your case (refs, sub-panels, queues, globals, functional globals, etc., it depends on what you're doing and how), decimate data AND updated displays only every 60 msec - 50 if you really cannot settle for less - but even 100 msec should be enough.

That being said, LabVIEW graphs have excellent decimation where they can take 20,000 points and draw them on a graph that is better than simple decimation, tending to favor the outliers. I would only try to improve on this if you are having a real performance problem, and I would first slow your update rate down before trying any fancy footwork with the dataset.

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.