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.
- 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?)
- 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.
- 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.
- 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.
This account is no longer active. Contact ShadesOfGray for current posts and information.