LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Data Acquisition at Vatious Frequencies using Time Delay

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

0 Kudos
Message 1 of 10
(3,421 Views)

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

0 Kudos
Message 2 of 10
(3,411 Views)

Thank you for your fast response. I've got a thermocouple module (NI9211).

 

Thanks

Mo

0 Kudos
Message 3 of 10
(3,408 Views)

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

0 Kudos
Message 4 of 10
(3,403 Views)

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

0 Kudos
Message 5 of 10
(3,370 Views)

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

0 Kudos
Message 6 of 10
(3,354 Views)

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.

0 Kudos
Message 7 of 10
(3,337 Views)

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,

Cameron T
Applications Engineer
National Instruments
0 Kudos
Message 8 of 10
(3,321 Views)

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

0 Kudos
Message 9 of 10
(3,317 Views)

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.

 

Hardware-Timed Single Point Sample Mode:

http://zone.ni.com/reference/en-XX/help/370466W-01/mxcncpts/hwtspsamplemode/

 

 

When Should I Use Continuous or Finite Sampling Modes?:

http://digital.ni.com/public.nsf/allkb/B86AA2D2FDE9A16086256FFC00604202

 

 

Thanks,

 

 

Cameron T
Applications Engineer
National Instruments
0 Kudos
Message 10 of 10
(3,301 Views)