Question about memory usage and setting value by property node

[d1sturbanc3]

I'm currently setting a large (huge) spectrogram by passing a reference into my subVI and setting the value output by property node. I sometime get a memory error when I make my buffer in the program to large. I was wondering does it cost anything in term of setting a graph/spectrogram by using the value property node and by reference? Would a global variable be better in terms of memory cost? Would it be worth the effort? Thanks!

[JeffOverton]

A property node is a bad choice here for two reasons.  One, it will always slow things down because it forces the current action to run in the UI thread.  Two, it creates a copy of the data, which is why you're getting memory errors.  A better option would be to pass the data out of the subvi and directly to your chart, because LabVIEW is smart enough to do that in place.

[johnsold]

Another point: It makes no sense to send your graph more points than it has pixels to display the data. If more data is sent, then LV has to reduce that to the number of pixels. If it is a line graph, then it has no more pixels than the width of the graph (for each plot). Even on a large screen that is only about a thousand points. Reduce your data to what can be displayed and your memory problem will likely go away. Of course you may need all the data for other purposes, but it need not be displayed.

Lynn

[d1sturbanc3]

Thanks, but I really can't pass my data out of my subVI. My current design is a multithreaded design with multiple while loop running. Essentially what I have is one subVI doing heavy computation (lot's and lot's of FFTs, average, and statistical analysis). It's updating a 2by2 array which I want to display on intensity plot.

The plot in on my front panal UI which controls that subVI and other subVIs which does multiple logging of the analysed data and analysises on the previously logged data. The front pannel display data to the user in graph format.

What's the best way to pass the data out from the subVI that does the computation? A queue/notifier still would copy the data. Would a global copy the data? Could I do a intensity plot on a global?

[JeffOverton]

Actually, Lynn's idea is way better than mine, because even with repeated property node calls, passing 1000 datapoints will still be pretty quick.

[d1sturbanc3]

okay... So the recommendation is to still pass the data by reference point, but reduce the amount of data that is passed. I think I can do that. I'm passing out a STFT data, but the user isn't focused on the entire spectrum.

[JeffOverton]

And even if you limit which bands you display, you can still potentially reduce the number of datapoints you show because your graph is only so many pixels wide, reducing the data you have to copy in memory.

[d1sturbanc3]

yes that's true, but I'm giving my users the ability to pause live data and zoom in. I'm afraid if I start taking out points in the array, the graph won't look as nice when they zoom in.  Otherwise I'll have to write my own zoom function, which would be kind of hard. Got any suggestion on how to handle to zoom case?

It would seem to me that the graph itself should be able to determine what data to copy and what not to copy based on the current zoom/resolution and viewing area. It would be kind of silly for the user/developer who use the graph to determine that for the graph. Doesn't objects in Labview have that capability?


Message Edited by d1sturbanc3 on 06-23-2008 01:07 PM

[JeffOverton]

I think NI always tries to err on the side of giving the developer more control and power over their software.  And depending on how you set it up, a zoom case could be fairly easy.  Instead of letting the user zoom arbitrarily, give them 1X, 2X, 5X and 10X resolution for example.  Then you still know exactly how many datapoints you're passing and can easily pull them from the main array.

[JeffOverton]

This is a pretty horrible implementation, but it displays one of the ways you could realize your zoom feature.  Add on left and right arrows to control the index at which you start your zoom, some error checking to make sure you don't try to call an empty array or something, and you've got a robust setup.

Message Edited by JeffOverton on 06-23-2008 02:24 PM