LabVIEW
DAQmx Read Thermocouple with Output Pulse
Hello,
I'm trying to put together a few example VI's I found in order to build a measurement system that will read thermocouple data and output a Digital pulse simultaneously. It is not important how the tasks are coupled (eg, reconfiguring the process to send out a pulse when it reads thermocouple data is also fine). However, it is important for me to have the sample rate dynamically reconfigurable.
Current Code:
@Kevin_Price wrote:
At very first glance, the code looked all tidy and neat and I figured it was probably just gonna need a small tweak or two.
But nope. It'll need at *least* quite a lot of small tweaks and possibly some significant changes in overall approach.
What DAQ device(s) are you using? What's the purpose for issuing pulses simultaneous with measuring a temperature? Exactly *how* simultaneous must these things be?
Some temp measuring devices I've used do a fair amount of built-in averaging or filtering. A little time passes from the instant when the temperature measurement was true until the measured value is available for retrieval. So you could make a pulse that indicated that you received a measurement, but it wouldn't *really* correspond in time to the instant when that temperature value was true.
All that to emphasize that defining what you *really* need when you ask for things to be "simultaneous" can matter.
-Kevin P
I'm glad the code at least looked neat 🙂 I was worried it was a little too messy after I removed the abstraction sub VI's.
In terms of devices, I have an NI 9402 as my pulse out and pulse verification device and an NI 9213 as my thermocouple reader. Both are plugged into a cDAQ-9174.
The digital pulse connects to a device that will take a measurement when it sees the pulse. As for "simultaneous," I would like there to be as little delay between the two modules as there will already be some propagation delay between the NI software and the other measurement device. Our sample rate will likely be somewhere in the High Hz, Low kHz range with a foreseeable Max of about 50kHz.
@Kevin_Price wrote:
Well, you certainly won't support the low kHz range, let alone 50 kHz -- your 9213 device specs out at a max of 75 Samples/sec for 1 channel. It also doesn't appear that it would accept an external sample clock from a counter. It's less clear, but it also may not be able to export its sample clock to a DIO module via the chassis.
In short, the 9213 module doesn't seem likely to support the requirements you describe. Now then, what kind of test are you running where you need to sample temperature at 10's of kHz?
Another approach might be to:
- generate your pulse train for the external device that wants it
- configure another chassis counter to count those pulses
- each time you get a slow-rate temperature reading, query the count value to act as a kind of timestamp.
Details would remain for starting the tasks in the right sequence, but you'd be able to read temperature as fast as your 9213 can manage and also tag every reading with a pulse count, a.k.a. timestamp. This will give you fairly decent correlation to the samples of the external device, give or take a few samples.
-Kevin P
Ok, I think that's the approach I'll take, keeping multiple sensors tied to a counter is likely a better way to synchronize anyway. Now, two questions:
1) My CO pulse rate may change over the test, doesn't the cDAQ have a constant rate internal clock I could sync to? If so, any best practice advice?
2) If I wanted to sample at a much slower rate (eg 2 Samples/sec) is there a different approach I should be taking, or would it still make sense to use an internal clock and align the sensor data in post-processing?
