Occasionally missing data from output - Issue with Elapsed Time, Sample Compression, or something else?

[Jwang3]

Hi all,

Hope you can help with the following. I have:

• A DAQ Assistant reading from 2 thermocouples at 1 Hz
• Sample Compression (factor of 60) to obtain the average every minute (not rolling average)
• Producer/consumer setup
• Elapsed Time which enables Write to Measurement (xlsx) every 60 seconds

I ran this from 3:50pm to 7:22am the following morning. It seems to have worked, but I noticed that about once an hour, a data point is missing. Is this an issue with timing or how I set up the VI? Please advise.

Thanks!

[Jwang3]

Forgot to mention - I edited the Sample Compression VI so I could have a terminal to control size.

[RavensFan]

My guess, there is a slight discrepancy between the acquisition rate of the DAQ system and the clock rate from Windows, with the error being caused on the Windows side.  Windows clock is notoriously unreliable.  If you ever  open it up and watch it tick, you can often see it take a slightly longer pause before the second hand jumps.

About every 61 or 62 minutes, the data coming from the DAQ is happening at 1 Hz, but the 10 second elapsed timer that is derived from the windows clock is just not up yet.  It might be at 9.999 seconds or something like that.  The output is false, and you have to wait another second for the next sample to come in through the queue, now 10.998 seconds have passed and the value is true.

I would suggest sampling the data at a much higher rate, perhaps 10 or 100 times per second. 

[Bob_Schor]

To restate RavensFan's comment, the problem here is that you have two "clocks" running, one in the DAQ system (gag -- I hate the DAQ Assistant and Signal Wires -- do a Web search on "Learn 10 Functions in NI-DAQmx" and improve your DAQmx code), where the "clock" is probably in the DAQ hardware and designed to be precise, and the other in the Elapsed Time (sigh -- another Express VI) where you are using Windows' somewhat-unreliable, certainly not precise, clock.  If the clocks are not perfectly synchronized (and they almost certainly are not), it is only a matter of time before data are lost.

The "solution" is a single clock, in particular the DAQ clock.  I have no idea how you have your Assistant configured, but if you are getting samples every second, say, and want to do something every X seconds, then each time you get a sample, count it, and when you reach X, reset the count to 0 and "do your thing".  This forces the processes to run in synch.

Bob Schor 

[Jwang3]

Thank you for the explanation. After removing Elapsed Time and configuring the VI to perform a task every 60 iterations, it no longer skips data points. However, the data output seems to lag behind the current time. I ran the program for 2 hrs, and only 1 hr and 45 minutes of data were written to the spreadsheet. Even now I can see from the chart that data are being taken at the current time, but when I look at the spreadsheet, it's 15 minutes behind. Is there a reason why the consumer is lagging behind than the producer? Is there a "catch-up" period where the most recent data are output? Thanks.

[RavensFan]

First, I would put the Enqueue function in the case structure.  You really don't want to send the "default" blue dynamic data type through the queue.

I would get rid of the shift register on the error wires.  You don't want a random error to prevent any future iteration of the Write to Measurement File from working.

I actually think that is your problem.  Did you open up your file while the program was running?  I'm thinking that if Excel had the file open, it put a lock on the file.  When the VI tried to write data to it, it was blocked, threw an errror,  the data never got written, and the error persisted in the shift register to never actually execute that Write TDMS again because of the incoming error.

Put an indicator on that error wire and see if you are getting errors.