Data acquisition set for 1 second is periodically skipping a second

[Atwalsh]

LabJack,

Over the course of a few hours I missed about 12 seconds. The labjack I am using is a U12 device. I am not at the field site so I had a labmate take a picture of the code and send it to me. I can post a better one tomorrow. If you look at the top right of the code is where I have my wait timer set up, however, this is not the same setup. I previously had a simple wait timer with 1000 ms as a constant and it was still missing a second here or there. Ignore all the other jumble that is near the new wait timer.

[Michael_78]

It will work much better if you replace the stopwatch wait for the metronome wait!!! Check my last post for the names 🙂

[Dennis_Knutson]

You should get rid of the slow write to measurement file. Switch to a producer/consumer design.

[ogk.nz]

I'm not sure that a shift to a producer consumer cycle is completely necessary given the slow update frequency and the inherent complications of having to redesign the code. At this stage I would simply recommend adjusting the code to handle the timing. Either you or your workmate need to reconfigure the code to resemble 

If you wish to redesign the data storage method at a later stage I would probably recommend moving to a write to CSV or TDMS method, both of which are reasonably simple to do and should dramatically reduce your data write times. 

[LabJackSupport]

As mentioned above, the metronome is likely a very easy fix for you.  The metronome is an interval timer rather than just a sleep or delay.  Look at any of our examples with a loop.

The U12 is our oldest and slowest device, so your loop jitter might be something like +/-20ms, but still if one loop takes 1020ms the next one will likely take about 980ms to make up for it if you use the metronome.

Looking at the picture of your VI, I see 4 U12 calls (~20ms each) plus a chart update and file write (perhaps 1ms each), so everything in your loop should be <100ms and thus you should have no problem iterating with a 1000 ms interval.

To check inefficient file writing speed I did a quick test in LabVIEW by making a loop that does Write To Spreadsheet File in a loop over and over.  This is an open-write-close type of file write so should be the least efficient.  10000 iterations writing 1 value per iteration only takes 1300ms, so 0.13ms per file write, which is faster than I expected.  10000 iterations writing 10 values per iteration only takes 1800ms, so 0.18ms per file write, which still seems super fast.