LabVIEW
Delay between tabs with large dataset
Solved!
This is a small snippet I created from a much larger program. The problem I'm having is when I switch between tabs and the tab I'm switching to has a large dataset, there is a few second delay before the tab switches. I didn't find much info from my searches, so I was hoping somebody that knows what's going on can provide more information. If that's just the nature of LabView, then that's fine, but if there's an optimization, I'd like to be able to implement it.
You graph is severly taxing the UI thread. There is a nonzero cost graphing so much data:
3M x 24 x 8bytes/point is almost 600MB!!
It is not reasonable to graph that much data! Given that your graph only has about 400k pixels, it seem silly to graph 72M points on 0.4M pixels, right. Can't you decimate your data somehow?
Six or seven years ago, I heard a seasoned LabVIEW Developer talking about "What to do" and "What Not to Do". Among the latter advice was "Do Not Use Tab Controls", particularly if the reason for the Tab was to "cheat" and create a HUGE Front Panel, showing one Screen's worth at a time.
The advice (which can achieve the same basic result, still "cheating") was to use a sub-Panel. The code that you formerly executed in, say, Tab 1, you now execute in sub-VI "Tab 1.vi". The Front Panel of the Tab 1 VI has all of the Controls and Indicators that you had on the former Tab Control's Tab 1, and the sub-VI executes all of the code that you formerly had in the Case Statement corresponding to Tab 1 being selected. The difference is that in place of the (large) Tab Control, you have an equally-large sub-Panel, and when you want to execute the Tab 1 code, you load the Tab 1 sub-VI into the sub-Panel Control and it runs, allowing you to interact with the sub-VI's Front Panel just as you used to interact with the same Controls that were part of your Main VI.
This is a much more flexible technique than using Tab Controls. To get yourself started, create a blank VI, and on its Front Panel, go to the Layouts Palette and drop a sub-Panel. Size it as big as you need (like the size you formerly used for the Tab Control). Now look at the Block Diagram -- you'll see a method for your sub-Panel waiting for you to insert a reference to the VI you want to run in it. Write a little VI, with some Controls and Indicators you want to use. Be sure this VI uses Error In and Error Out. Now place this VI right after the "Insert VI" node, connecting the VI's Error In to the sub-Panel Method's Error Out. Finally, drop a Static VI Reference (Application Control Palette), right-click it and choose "Browse for Path" to find the path to the VI you just wired to be run after you stick its Front Panel in the Window, and wire this reference to the "VI Ref" input. Here's a picture (the above is < 1000 words, but getting uncomfortably close ...).
When your Main program gets here (here = the place in your code where you want to execute whatever was dealing with the Controls and Indicators on Tab Control 1), this little Snippet will run the Tab 1 VI (here I used a VI of my own called Find DAQ References -- I was too lazy to build a dummy Tab 1 VI), processing its Controls and Indicators in the VI you specify. When it is done, it just exits and whatever is next on the Error Wire runs and can use any of the data that Tab 1 VI puts on its Output Indicators. To switch Tabs, you simply put the VI representing, say, Tab 3 (or whatever Tab you want) there.
But how do you specify the Tab (or sub-Panel) you want? Any way you want! You can have a set of Boolean Buttons called Tab 1, Tab 2, etc, a Rotary Switch with these indicators, or something more inventive.
Bob Schor
@nickb34 wrote:I want the user to be able to zoom into the waveform (like you would on a scope), so eliminating too much of the data (or any at all) might mean that they can't see a spike or dropout on a waveform. I realize the amount of data is significant, but LabView seems to be able to handle it just fine in most situations. The speed in which LabView generates and graphs that amount of data is incredible... I'm just looking to see if there was a setting or something that I missed that could optimize what I'm trying to do
I do this all the time. Decimate your data, when the user zooms in or out, take a different part of your data and re-decimate if necessary.
mcduff
PS Turn Anti-aliasing and smooth updates off, should increase speed somewhat, but that is not your rate limiting step.
I wanted to share my solution, hoping that it may help somebody down the road. Decimation is a simple concept, but implemenation is a whole other story.
