Real-time with parallel loops

[chris.mckenzie]

I've been using LabVIEW for a few months now, and have been work on part of a data equation, analyze and display program. Charts are an essential part of the display, but they slow the while loop iteration rate and hence sample rate. From the reading the forum I have tried to develop a parallel while loop system, with data being passed by queues. So that the equation can be done in one loop at a fast rate, and the graph display in another at a slower rate. This simplified VI is my attempt to reproduce an example I've seen.

My question are (1) Is this a correct implementation (2) I've tried using the x-scale multiplier to show the real time on the x axis, however if left to run it lags behind the elapsed time VI. It isn't a major difference for this simple example but in the real program its unacceptable. (previously I have used the elapsed time VI to build the data into waveforms, it worked but was messy for lots of graphs).

IS it something to do with delay time + processor time = cycle time, which is the actual time. Read a bit about it, but don't know how to incorporate it.

Help would be much appreciated. Sorry if I waffled.

Chris

[tst]

Your basic approach (seperate tasks) is correct. A few points:
1) using the property node forces the top loop to be executed in the UI thread, which is shooting yourself in the leg.
2) I modified the chart to display real time.
3) Flush queue does the work of your bottom loop.
4) There is no need to use a shift register for the queue. It doesn't change.
5) Your method of stopping the bottom loop is interesting, but I don't think it would be viable if this was the real application.

[chris.mckenzie]

Thanks for the tips, being a novice its hard to spot these things.

In my previous message I used the wrong terminology, I didn't actually mean real-time, I'd like to display the relative time elapsed in minutes and seconds since execution like the first attachment. The issue was, after a while the chart time started to lag behind that given by the elapsed time function (only a few seconds, but a more noticable problem in the real program).

Is there anything that can be done to correct this, perhaps finding a way of using the cycle time as the multiplier rather than the delay time (doesn't take into account processing time)?

Chris

[tst]

In that case my changes (the format and the offset property) are uncalled for.
The multiplier tells you the difference between each two points, but is a constant for the entire scale - if individual loops take more time you should drop the data. Using a wait until ms as multiple VI should pad the waiting time to fit, so if the actual execution of the code takes 2 ms and you input 5, it will wait another 3. However, if certain loops would take more than 5, there is nothing you can do. You might think about using a waveform graph instead of a chart and use the number of the sample as the basis for the time. You'll have to keep the array of previous values and make sure it doesn't get too big, but the timing should be exact.