How can I send commands from a single UI loop to different while loops?

[RavensFan]

See the attached modification which follows Lynn's recommendations.

[johnsold]

RavenFan,

Thanks.

Lynn

[jcannon]

Hi RavensFan,

Many thanks for this...

I checked the "RUN" loop time, which appears to be about 1-2 ms slower than the expected 100ms loop time... Timing is critical for may application, so I replaced the program while loop with a timed loop; however, it no longer works?

Any suggestions?

Regards,

Jack

[johnsold]

Jack,

Please be more specific.  What do you mean by "it no longer works"? Does the program not run? Does it produce errors? If so, what errors?

Of course the modifications by RavensFan did not produce exactly 100 ms loop time and neither will the timed loop version. Why? because the code inside the loop takes longer to execute than 100 ms.  If no new element is in the queue, the Dequeue will wait 100 ms before timing out. Then the code inside the case structure will execute. The Idle case has a Wait until Next ms Multiple set to 100 ms.  The Run case reads 100 ms worth of data and will wait if the data is not available. Then it manipluated the data and updates a chart on the front panel.  You are lucky if all this takes only 1-2 ms extra.

The first thing to try is a shorter timeout on the Dequeue.  The DAQmx Read will not happen any faster than once every 100 ms.  So a shorter timeout and the Read should get you closer to the timing you want.

What timing is critical? Reading the data from the DAQ device? Updating the display? (Are your users eyes calibrated to 1 ms resolution?) You may need to move the time critical part into a parallel loop of its own.

Lynn

[RavensFan]

It takes 100 msec to acquire the data by itself (200 samples at 2000 Hz).  You still have other operations to do after that such as the splitting of the waveform and merging of the waveform after the comparison operation.  So that will take some clock cycles as well.

What do you mean by "it no longer works" with the timed loop.  What is not working?  Is it crashing, error message, ....?

[jcannon]

Hi Lyn/RavensFan,

When I say not working no data is displayed when in the RUN state and when I select STOP, I get and error: Error -200088 occurred at DAQmx Stop Task.vi:1... No task available?

Based on what you have both indicated, perhaps I do not need a timed loop anyway?... The vi I am developing is for a deterministic(?) task; where the data are acquired at 2khz, displayed for the user who will manually (using a button control) trigger an AO when the signal reaches its max... Note the strain signal is obtained from a dynamometer during a voluntary human muscle contraction; so the signal fluctuates about the max value quite a bit... Athough the AO is triggered manually (and would not be very precise; may hit the trigger too early or too late), I would still like to be confident that the data displayedis as close to "real-time" as possible (and that the data saved to disk temporally accurate)...

I understand that the read time is 100ms per iteration (based on 200 samples at 2khz).... Does that mean that to ensure precise loop timing ALL processing (e.g. ptbypt filter) should be done in another loop? How can I be sure than the filtered (smoothed) strain signal is as close to being displayed in real-time as possible?... Please note that I have requested a software upgrade for next year that will include the real-time module (not sure if I really need it or not)... Also, I am never likely to sample more than 6-7 signals synchronously at a rate greater than 5khz (perhaps a stardard while loop will be fine at this relatively low rate?).

Also, with the VA_Instrument_Queued[Mod].vi; if I change states from RUN, to IDLE, wait some time, then change back to RUN, the display x axis rapidly updates the current time before data are displayed... This may take a few seconds in the user is in the IDLE for a while.. Any suggestions? Perhaps I need a graph rather than a chart?

Thanks,

Jack

[RavensFan]

I don't know why you'd be getting that error.  I doubt it is because you used a timed loop.

The reason you see a rapid update in the run state after you've been in idle for a while is because of the way you are collecting data.  You've set up a task with continuous samples then start it.  In your run state, you read 200 samples at a time.  In the event you spend time doing something else like idling, the DAQ task is still running and collecting data, but it is filling up the buffer.  When you get back to running, it goes to reading 200 samples at a time, but since they are already in the buffer, it takes no time to read them and the DAQmx read returns immediately.  That is why the screen is updating more quickly.  You are basically burning through the backlog of data points that have accumulated in the buffer.

What is the purpose of idle?  If you don't want to collect data during that time, you should pause the task and then unpause it when you are ready to start collecting again.

[jcannon]

Hi RavensFan,

The main purpoae of idle is to stop the data to chart so that the user can use the x scroll bar and graph palette tools to zoom and view the data, when needed.

So I need to pause?

Regard,
Jack

[RavensFan]

Yes.  You may be stopping data to the chart, but the data is still be collected in the DAQ buffer and is what is getting read out when you go back to Run.  You wind up with all the data, just delayed in time.