MAX Clock Settings vs. Timed While Loop

[flywithme]

I have a very simple .VI that has reads and records to file accelerometer data using a task set up in MAX.  My question concerns the timing and data being written to file.  

Maybe someone else has had this issue/misunderstanding and there is a previous posting I haven't found?

 - Setup -

               In MAX, the clock settings of this particular task:

                            # of channels = Samples to Read

                            Rate = 1k (Hz)

              The .VI executes a timed while loop running off the 1kHz clock, Period set to 1000ms and Write LVM Express VI to write waveforms to file. 

 - Issue -

It appears there is lag in the data being recorded to the LVM.  The time stamp in the recorded waveform data shows 1000 Hz, however, it appears to have been sampled much faster. 

I was under the impression this setup would sample at 1kHz and write to file accordingly.  What am I missing/misunderstanding? It should be so simple!

[DFGray]

Please post your code so we can debug it.

[flywithme]

does that help?

[DFGray]

The VI helps, but we need to DAQ task, as well, to fully debug the issue.  In particular, how many data points are you trying to take and is your acquisition continuous or on demand?

If you are fetching 1000 or more data points and your collection frequency is 1kHz, the timed loop is guaranteed to always be late.  The VI reads data from the DAQ board, then creates a new file and writes N text values into it.  Creating a new file is a slow operation, and will get worse as each file is written, because the Express VI verifies that the next file name iteration is not already on disk.  In addition, saving to a text file, in general, is slow, and the LVM file adds a header to each file to slow it down even more.  There are several things you can do to fix the problem, all of which are not necessary.

1. Instead of using the timed loop, use the timing capabilities of the DAQ board itself.  It will be far more accurate than the operating system clocks (what OS are you running this under?)
2. Consider adding to one file instead of creating a new on every time.  This could have the side effect of creating a very large file.
3. Consider using TDMS or HWS (binary formats) instead of a text format.  TDMS has a plug-in to allow it to be read by Excel, and is a native file format of DIAdem.  HWS is based on HDF5, so can be read by anything that reads HDF5 (most analysis programs).  HWS was designed for this sort of data streaming to disk.
   
4. Consider putting your data storage in a different loop.  You can pass data from one loop to another using queues.  This allows you to acquire and save data in parallel instead of sequentially.  If you are using a multi-threaded OS, LabVIEW will take advantage of it.

If this doesn't help, post your DAQ task and we can look at that and try to figure out what is going on.

[flywithme]

I cannot access that pc right now. but the task is just a simple voltage setup with 5 channels, on continuous acquisition at 5 samples for 1kHz.  It runs fine when tested in MAX.

The issue is more of a concern that the time stamp is not accurate.  The data (when written to file) appears to have delay.  I have the Express VI to write a new data file every minute.  Where  does the time stamp really come from?  does it come from the loop setting or from MAX?

[DFGray]

The timestamp comes from the DAQ board.  Since you have a continuous acquisition, the DAQ board is taking data at 1kHz.  However, according to your latest information, you are only fetching five samples per second.  So, every second, you get 995 samples behind, resulting in a timestamp (and data) that is "incorrect."  I am somewhat surprised you have not had buffer overflow issues.

Solve the issue by changing from continuous to N samples for the acquisition mode.  This will necessitate a bit more code, but not much.

Hope this helps.