NI 9213 thermocouple noise w/ crio-9068

[Borsche]

I've been having an issue with thermocouple noise using the NI 9213 for some time now. The issue is not the value of the signal (the actual temperature reading +/-, but the signal going in/out (see below).

The noise is from 120V 60hz resistance heater wires. These thermocouples are used for high-temperature heat tracing, so they are in close proximity to NiCr heating wire. The TC is electrically isolated from the NiCr, but there is inherently some induced noise. TCs will read correctly when no power is applied, but as temperature and power increase the TCs start to go in and out. Even at high temperatures, turning off the heater power immediately restores the TC value. With a heater on full-blast, the temperature is sometimes completely unreadable.

The issue is somewhat improved when using sheathed and ungrounded thermocouples, but we prefer the flexibility of welding thermocouples directly to piping.

We use all shielded and grounded (on read-side) cables and minimize power cable/TC wire contact. The TCs lay perpendicular to NiCr heating wire. NI-9213 is in high-resolution mode. 

The only success story to this problem existing in the forums is to use an alternative device to read TCs. Any suggestions or other success stories?

[Borsche]

I was able to look at the raw voltage signal from the NI 9213. The voltage signal simply drops to zero when the TC does not read. There doesn't seem to be any overlapping noise.

In the attached picture, the top value of the TC voltage is ~8 mV.

[CFER_STS]

The NI 9213 provides both common mode voltage out-of-range and open thermocouple detection functionality.  You need to use these features in order to determine whether any instantaneous thermocouple reading is valid.  I am using NI 9214s, but the idea is similar.  Having the OTD turned on will produce a slight voltage offset as a result of the detection current, so before starting a test and with the specimen temperature at steady-state, I characterize the OTD error by first turning this function off, capturing data across all channels for 30s and averaging for each channel, and then turning the function on and repeating the process.  The difference between the average measured temperature for each channel is the error introduced by the OTD, so I maintain this array of corrections to apply to all subsequent measurements.  I am using resistive heaters at 80VAC running on a slow timebase PID, so when the heater near a particular thermocouple clicks on, I get induced noise on the TC.  The noise tends to be large amplitude and bi-directional with respect to the base measurement, as opposed to being an offset, so I simply disregard the measurement any time the common-mode voltage or OTD errors are present, and with the rest, I filter the signals over a longer period than either the measurement sampling period or the control PID period.  Temperature processes typically have long time constants, so this is perfectly acceptable in my application.  I can see the noise when it occurs on a chart, but the actual process variable I am using is stabilized / filtered and disregards the error periods.  This works with welded thermocouples in the presence of noise from resistive heaters.  At times, I also use high frequency induction heaters on my test specimens, and there was nothing whatsoever that I could do to get the welded thermocouples to behave when the induction heater was running.  The solution I found was to replace the welded thermocouples with contact thermocouples (glued on to the specimen with adhesive) which are much better behaved, though like you I prefer welded when the application permits.

[Borsche]

Thanks so much for the advice! 

How do you turn on/off the OTD (open thermocouple detection)?

-Boris

[CFER_STS]

It looks like I misunderstood the module features.  Looking at the datasheet for the NI 9213, I noticed that it offered OTD functionality, and assumed that this could be toggled.  On the NI 9214, this is done with a FPGA I/O Property Node.  With the NI 9213 however, according to the NI 9213 FPGA Interface help it appears that the presence of errors can be detected using an FPGA I/O Method Node, but there is no settable property to turn the feature on or off.

[Borsche]

I was able to toggle the OTD by updating to LV 2018. The OTD functionality had no effect on the TC drop-out 😕 

Certainly, your suggestions to reduce noise and filter the signal help, but the signal can drop out completely when at high T and power. TC selection and power wave can also help.

It's surprising that i'm using the same TCs on a separate unit with a $35 controller that has no issues whatsoever. 

https://www.auberins.com/index.php?main_page=product_info&cPath=1&products_id=14

Is there really no solution to getting a good signal from the NI 9213?

-Boris  

[AnalogKid2DigitalMan]

My suspicion is that you have ground loops between your T/C's that are creating voltage drops that get imposed on your T/C's. The 9213 inputs all share a common connection (COM) thus these voltages interfere with the mV level T/C signals.

The standalone PID's will offer electrical isolation between the T/C's thus they read correctly.

-AK2DM

[Borsche]

AK2DM,

Are you suggesting that the NI 9213 can only read 1 TC when in a noisy environment? 

Using only 1 TC port of the NI 9213 yields the same results. Similarly, using other PID units that can accept multiple TC inputs also have no issues. Neither unit has channel-channel isolation. The way I wire the TCs and power is identical in both systems.

https://www.watlow.com/en/products/controllers/temperature-and-process-controllers/ez-zone-rm-integr...

Also, using ungrounded TCs means there is no electrical contact between the TC and the hot workpiece. Yet the error persists.

The signal filtering for both units seems similar. This leads me to believe that its some sort of software problem.