10-21-2013 04:31 PM
Hi,
I've designed the following data acquisition program for thermocouple input.
The problem I'm seeing is that sometimes the system captures at a frequency
that is a bit off from what I set to. Therefore, I'm wondering if there's a
better way to implement what I'm intending to do.
Note that I've set the data acquisition system to the following:
0-180 seconds: 1 Hz
180-600 seconds: 0.1 Hz
600 - seconds : 0.0167 Hz
Thank you,
Mo
10-21-2013 04:58 PM
You do not say what kind of DAQ device you have. If the device is capable of hardware timed acquisition, I would set it to 1 Hz and let it run continuously. For the first 180 seconds use all the data. From 180 to 600 seconds use every tenth data point and discard the rest. After that use every sixtieth data point.
Depending on what you are doing with the data, you might consider averaging some of the data points in the later time segments to reduce noise.
Lynn
10-21-2013 05:02 PM
Thank you for your fast response. I've got a thermocouple module (NI9211).
Thanks
Mo
10-21-2013 05:11 PM
Mo,
It appears that that device does not have progammable hardware timed acquisition so what I suggested will not work.
If you are running on a Windows operating system (which is likely since you are using the DAQ Assistant), you will never get precise timing controlled by software. One thing which might help would be to use a Producer/Consumer architecture with the DAQ Assistant and a 1 second delay in the Producer loop and all the indicators and file operations in the Consumer loop. If a file operation takes longer than 1 second, it will not change the DAQ timing.
Lynn
10-23-2013 08:41 AM
Thank you for your reply. The problem is that I would like to use this program for 35 days monitoring where in the first few hours I'm going to monitor at my highest rate, 1 Hz, and for the majority of the test at 0.0167 Hz. If I capture at 1 Hz for 35 days, I'm not sure the producer-consumer algorithm would still solve the problem. Is there a progammable hardware timed acquisition extention to the device or even a whole new thermocouple module with such capability that I could buy?
Regards,
Mo
10-23-2013 07:12 PM
Mo,
I am not familiar with all the thermocouple measurement devices available. I suggest you contact your NI sales rep for assistance.
Sampling at 1 Hz for 35 days results in 3 million samples. Keeping that in memory would not be a problem. You could write data to a file every few minutes or as often as seems appropriate to your requirements. Then you do not need to keep large amounts of data in memory.
Also, you could discard the excess data after each minute when you are in the slow mode.
Lynn
10-24-2013 08:24 AM
What sort of carrier is your NI-9211 in? From your code, it appears to be in a USB cDAQ chassis (although it can also be used in an FPGA chassis). Assuming the cDAQ chassis, you should have hardware timing capabilities which will enable you to take data with hardware timed precision. Given your data rates, you could take it using the operating system, but the jitter on when data is taken could be on the order of 0.1s or more, depending upon what else is going on. Typical would be about 20ms to 50ms of jitter.
Lynn has already suggested one of the best ways to do this. Use a producer/consumer architecture (see the LabVIEW help for an example). The producer is your thermocouple reader, running at 1Hz read rate. The consumer is your logger. In the consumer, you log everything for the first time interval, then log only what you want after your intial inverval. Averaging points can be done in the logger, as well. It may be worthwhile using three loops - one to take data, one to process it by discarding or averaging, and the final loop to log. You could combine all this functionality into a single loop, since your data rates are so low, but I would not recommend it. Strange as it seems, it makes the code harder to modify and maintain if you need future additions.
Good luck! Let us know if you need further information.
10-24-2013 12:40 PM
Hello,
The NI 9211 does in fact have hardware timing available. This means that you should be able to run continuously and implement the solution that Lynn suggested initially or run continuously and set the sample rate for the onboard clock to change programatically base on the time of the test.
Thanks,
10-24-2013 01:27 PM
http://digital.ni.com/public.nsf/allkb/B4E831774F29FB038625754C0081C050
The above page indicates that neither the cDAQ 9172 nor 9162 support hardware timing. I've tried both and I got the error: 200077
Mo
10-25-2013 10:34 AM
Hello,
You are correct in saying that your devices do not support Hardware Timed Sigle Point Acquisition, but they do still support continuous acquisition, wich is by definition hardware timed as the onboard clock is still used as a sample clock. The reason why your devices do not support Hardware Single Point Timing is because they communicate via USB, which is not fast and/or deterministic enough for acquisition that does not use a software buffer (Hardware Single Point Acquisition is bufferless).
I think you can still accomplish what you are trying to do with Hardware Timed Continuous or Finite Acquisition.
http://zone.ni.com/reference/en-XX/help/370466W-01/mxcncpts/hwtspsamplemode/
http://digital.ni.com/public.nsf/allkb/B86AA2D2FDE9A16086256FFC00604202
Thanks,