Counter/Timer
sub millisecond resolution clock in labview
Hi,
I've a pretty simple data collection task. I'm using Ni Daq to collect data. Now, I'd like to collect my data every 100ms and store it in a file once the data collection task is done. So, I used 'wait until next ms multiple' clock feature to execute my while loop every 100ms. However, I'm getting a couple of extra data points in the file. I can see that the loop doesn't always execute at every 100ms, but it ranges from 98-102ms (I get it from relative clock feature I'm using to record time difference between two successive points collection).
is there a way to make it execute every 100ms? I also tried 'high resolution wait time' but even then I'm getting a few extra points. My system runs on windows 11 if it helps to pin down the problem. Also, if I remove the wait time the loop takes about 7ms to execute.
Some jitter is expected, especially since you are not using a real-time OS (+ LabVIEW RT), are interactively building arrays, and update graphs inside the loop. A loop time of 98-102ms is probably the best you can do. Isn't that sufficient?
You might get a little tighter using a time loop. Have you tried?
Why don't you use hardware timing? What kind of hardware are you using?
Do you know the total number of points before the program starts?
@Vaib2020 wrote:
I don't understand what do you mean by hardware timing? But I'll go though the literature to get more info on that. To give you an idea of what I'm trying to do: I'm collecting data-points using USB6008 at an interval of 100ms. And yes I know the total no. of data-points to be collected as I'm scanning a surface with known area.
I am not familiar with your hardware, but most can be setup to define the sampling rate on the DAQ hardware, then you can read out whatever has been accumulated in the buffer at a more leisurely rate. I rarely do hardware, so look at the example ZY mentioned above.
@Vaib2020 wrote:
One more thing, what should be an ideal way of collecting and displaying the data since you mentioned that I'm building arrays and updating graph inside the while loop might be the issue?
Autoindexing on a while loop can be hard on the memory manager, because the compiler has absolutely no idea how big the arrays will get and might start with a reasonable estimate, just to be forced to reallocate more memory later and occasionally copy everything to the new location (arrays must be contiguous in memory!). In a FOR loop, the number of iterations are known from the beginning, so the exact final size is known. Since you know the final size exactly, allocate a correctly sized array in a shift register, then use replace array subset to fill with data as it arrives, keeping track of the correct index position in another shift register.
In general, I would recommend a simple state machine. You rates are not very high so you might even stream the data to disk using lowlevel file IO. It is always dangerous to save after the toplevel loop, because if the writing fails for some reason (malformed path, disk full, dialog canceled by accident, etc.), all data is irreversibly lost.
