09-09-2008 03:41 PM
09-10-2008 08:32 AM
For this particular case, if you want a sub-vi, then the code's architecture needs to change. You could make the code work using the original code, but it would be messy and not the better way to do it.
Have a look at the attached VI's.
I did modify the original code but preferred not showing a bad example. That is why these are named [3].
R
09-10-2008 10:55 AM
I'm going all the way back to the initial question and then stepping back a bit to see the forest for the trees.
If you display at a slower rate than you acquire, then you are displaying *less* data than you acquire. It will be *lossy*. And having a lossy display is often not a bad thing at all -- I for one do it regularly.
So once you explicitly decide to have a lossy display, a lot of your data handling gets simpler. You can decimate by averaging to reduce the amount of data being slung around. And you can use a Notifer instead of a Queue to do the slinging, so you won't start running out of memory if your "consumer" loop stops consuming.
I don't have LV handy here to look at the vi's being posted. Just wanted to chime in with some "big picture" comments.
-Kevin P.
09-10-2008 11:13 AM - edited 09-10-2008 11:14 AM
Hi Kevin,
I agree with you that there may be better techniques to implement a solution. However, there were not many details ( or specifications) given about the overall functionality, requirements or constraints. It is an unfortunate side effect at this forum where many people ask for help without offering enough details in order to offer a precise example. 😞 So we try to guess at what they are trying to do based on the available information.
The example does keep track of all data but only displays the last set in the waveform chart.
R
09-10-2008 01:06 PM
I think this is what I wanted. I didn't want any loss of data. I'll implement it my larger VI and hope it will work.
Thanks very much for your help.
09-11-2008 10:50 AM
I made a small mistake in one of the vi's. Here is the corrected version.
R