NI 9213 Thermocouple card reads differently on expansion chassis

[pallen]

I have a project with one NI 9213 module on a cRIO-9067 and two modules on an NI 9149 IO Expansion chassis.

Open TC detection is disabled on all three TC cards. 

When a TC is removed from the module on the cRIO, the value immediately shows Max value.  When a TC is removed from either of the modules on the expansion, the value does go to Max consistently.  Sometimes it does not change at all. 

Both racks are using Scan Mode with the same timing and card configuration. 

Is there a reason why the cards would be responding differently? 

Short of moving all the TC cards to the main chassis, (which is a major change at this point) is there something I can try that might mitigate this issue?

[anson.kunjappy]

According to the data sheet:

"The NI 9213 common-mode range is the maximum voltage between any channel and COM. If COM is not connected, then the common-mode voltage range is the maximum voltage between any two channels. The NI 9213 measures the common-mode voltage level of each channel and returns a warning in the software if the signal is outside the common-mode voltage range."

http://www.ni.com/pdf/manuals/374916a_02.pdf

AK

[a_clucker]

Hey Patrick,

"When a TC is removed from either of the modules on the expansion, the value does go to Max consistently."

This sounds right. There might be some lag due to communicating over the network (compared to seeing the value in RT almost immediately for the cRIO).

"Sometimes it does not change at all."

Can you expand on this?

[pallen]

Hi Andrew, 

There is a critical typo in my original post.  When a TC is removed from the modules on the expansion, the values do NOT go to max consistently.  But it DOES do so on the main chassis, every time.   

The TC's on the expansion chassis will sometimes jump to a higher, but not maximum value when they are disconnected.  Other times they will just keep reporting their last measured value with no indication they have been disconnected at all.  

All the modules are wired the same, and the COMs are all connected to ground on all modules.  Grounding lugs are also connected on both chassis.  

I haven't had a chance to test yet, but the plan is to try moving the two expansion modules to the main chassis.  

[a_clucker]

Hey Patrick,

I set up something similar to test (NI 9149, cRIO-9063, NI 9213). When I pull the TC from the cRIO, the value jumps immediately to 1377.xx (max). When I pull the TC from the eRIO 9149, it immediately jumps to 1377.xx (max) as well. Every once in a while I'd see a mid-way number reported (like 5xx.xx or 10xx.xx), but it was only a single value at a Scan Rate of 10 ms. However, the value always went to max, and always did so in well under a second.

I used NI Distributed System Manager to view the values and remove all LabVIEW / code from my test. Do you see the same behavior if you view the values in Distributed System Manager?

[pallen]

Hi Andrew,

Thanks for your reply.

We are seeing the same values in the DSM as the code. 

Our cRIO is a 9067.  I don't think this would make a difference, but it might. 

The project is done in LabVIEW 2015 SP1

Is it possible that this is a driver issue?

[a_clucker · Accepted solution]

Hi Patrick,

Originally I tested on a 18.x software stack. I pulled up my VM with 15.5 on it and saw different behavior. When I remove the TC, the value normally jumps up, but rarely all the way to the saturated max value.

I then tried on a 16.0 station, and could not replicate after a few tests. Poking through the issues we fixed in 16.0, it might have been issue #565604 or #566188.

You could work around this in a number of ways - put both modules on the 9067 (as you mentioned), update to a 16.0 development stack, or possibly move to FPGA.

[pallen]

Hi Andrew,

Thanks very much for this feedback!

I think I have installed version 16.0  Above is a screenshot of what I installed.  (found in my notes)  Is there perhaps something different or missing from my stack compared to yours?

I'll try a re-flash of the unit and see if that helps. 

[a_clucker]

Only notable difference I see is LabVIEW Real-Time - 15.0.1 vs 16.0. The 987x item should not matter for this case.

My guess would be you're still using LabVIEW 2015 SP1 development environment, and installed cRIO 16.0 on top?

In my test I used 16.0 across the board. My assumption was the component fixed would be in the shared components (shared across versions of LabVIEW), but looks like that must not be the case.

"I'll try a re-flash of the unit" - good idea, I always recommend starting from a fresh reformat.

[pallen]

Hi Andrew,

Thanks again for your input.

Yes, I am using LV 2015 SP1.  This is customer mandated. 

The software re-flash was suggested as a possible solution.  But after reading your posts, I suspect this is more likely a version issue and not a corruption one.