Write to file timing

[Stigger]

Hi to the Community,

I'm writing a VI for a doctorate research project and am having difficulty with a timing issue with the files written via the 'write to measurement file' express VI. We using a cDAQ to measure Temps and pressures in an experimental rig. The cDAQ is set as 'continuous samples' at 10Hz.

The problem I'm having is the sample time that the waveform data, read from the cDAQ (thats at a dt of 0.1 constant), is not the same as the sample time of the numerical controls and boolean local variables. The difference in sample time seems to be cumulative as well which is unacceptable for tests that run for very long periods. Now I'm assuming that the difference in sample time is due to either the dependence of the local variables on the original control or the fact that the numerical and boolean controls are not linked to the cDAQ timing, or a combination of the two.

The requirements for the VI is that it sample at 10Hz constantly and that the numerical controls and boolean local variables must be written to file at the exact time that the measurement from the cDAQ is written, in other word I need to know the exact time that the controls on the front panel is changed related to the measured data.

I have no experience in any other programming language other than LabVIEW and even that is very limited.

So any help would be much appreciated.

[Stigger]

Apologies, it seems as though I had forgotten to attach the VI.

Message Edited by Stigger on 05-19-2008 02:40 AM

[GerdW]

Hi Stigger,

the source of your timing problem is probably the file write itself... The filewriting takes time and adds to your sample loop timing. So in each iteration you add a little more offset...

Put the filewriting in a separate loop, use a queue to move data between loops and try to reduce using local variables.
It's also senseless to put a DAQ-Stop/ClearTask behind the loop when the loop doesn't stop (wiring a constant to termination terminal?!).

[Stigger]

Thanks for the reply.

 I’ve tried your suggestion; let me know if I have done a terrible job with the queues.

write to file - queues.png

Unfortunately it doesn’t quite solve the timing issue, although they are all read at the same rate. 

The queue merges all the data to a set number of columns, is there any way to split the data so that it writes each channel from the cDAQ to a separate column. Unfortunately the local variables are absolutely necessary for the VI, unless I use notifiers, which I don’t think will make much of a difference.

The VI I posted was only portion of the complete one so the loop does have a Boolean control to stop it, hence the stop and clear DAQmx. Sorry for the confusion.

 

[johnsold]

I do not see anything which attempts to synchronize the two loops. The DAQ loop is timed by the acquisition. The lower loop is timed by the tick counter. The Saving data loop does not seem to have any timing at all.

Consider putting the enqueuing of the controls and indicators into the control loop. When an acquisition is finished, send a notification to the control loop. When it receives the notification, it enqueues the control and indicator values. This allows elimination of the local variables and eliminates a loop.

Put a timeout on the Dequeue function in the Save loop. If it times out, no data has been sent, so do not save.

Lynn