Distributed Dystem Manager: Single TC channel in 16 channel module: "Unknown Bad Quality"

[S1ack]

LV2013

cRIO-9074

NI 9213 TC Module

A single channel (TC7) reports no data....I swapped the TC Module - no change.

Scan Engine owned module.

Anyone ever see this?

[Zach J]

Hello S1ack,

I know that you mentioned that you have swapped the TC Module, but have you tried checking the channel by connecting one of the other thermocouples that is giving you a good reading on another channel?  For example, you could test the channel communication by connecting the thermocouple connected to rPLCiTempChokeV2Raw to rPLCiTempChokeV3Raw instead.  If this does not give you a reading, there may be an issue with the module.  Let me know how things turn out!

[S1ack]

No I have not tried that.

Bad thermocouples typically read very high (open circuit), or low (shorted). So I did not think that an external wiring issue could cause this - but I will try it never the less. Perhaps the the TC is grounded - unfortunately its in about 50kg of potting material.

[S1ack]

Has the TC behavior changed in LV2013 and NI RIO 13? vs. 2011 ??

The channel was open circuit - and it reads 0 as zero on the shared varaible assigned to that channel.

Which is not safe in my opinion. Wire falls off and you measure 0 deg C? I see no dialog on the module configuration that enables the fail over direction - i.e. fail high.

The NI 9213 behavied differently in 2011.

[Zach J]

Hi S1ack,

I did some looking into this issue.  It appears that at least there is a difference between what DAQmx and NI-RIO will produce as a value when there is an open thermocouple measurement.  With DAQmx, the value will approach infinity as expected, but with NI-RIO 13.0, you will encounter a reading of zero.  This reading is also accompanied by an error in LabVIEW Real-Time, -65582 or -1950678943 depending on what mode you are accessing the value by.  While this is a departure from the expected behavior of an open thermocouple reading, the generated error values should provide enough information to correctly detect when a thermocouple has failed.  While this may not be intuitive when compared to other thermocouple measurement techniques in industry, this is expected behavior for the NI-9213 through Distributed System Manager.  Hopefully that helps!  Please let me know if you have any further questions.

[MarkCG]

I use programmatic access of shared variables pretty extensively. When accessing a TC variable through the psp (ni.var.psp://)  protocol, the error "-1950678943" is thrown if the TC is open or the common mode voltage is out of range. The associated error message is "Timed out while attempting to open a connection to the variable." This is misleading-- it looks like a network connectivity problem, when it really isn't one. 

Can we just have specific error codes for an open TC  or common mode range error when accessing remotely via psp protocol? When accessing locally on a cRIO via the ni.var.io protocol you get "-65582" for open TC and "-65583" for common mode voltage error. If we had specific error codes for psp then I could filter the errors appropriately and notify the user of TC problems. 

Finally I think the TC reading value given by the node on either of those errors should be NaN-- not 0.

[JonP]

Just hit this problem and wasted an hour or so trying to work out how I could possibly be getting a timeout. This is using LabVIEW 2017 so it is not fixed yet. Also it is not right that my program gets delayed 5 seconds by a non-existent timeout.