There is an Executable imbedded on the cRIO. it uses the Calibration.ini file to configure and run. this is running 24/7. We have not had any issues with Thermocouples not reading correctly, ever. NI equipment has been very stable. once the zero offset and slope are set, it (the calibrated reading) doesn't vary more than 3/10th of a degree F.
the host PC has another executable running on it (main program). The Technician can configure the test from a test editor VI. this sub routine tells the host PC program which channels from the cRIO server to plot etc.
Then when the operator goes to tell which channels to plot can you implement a programatic ignore of that error only on the unsused channels?
I understand this would be another thing to implement overall in your applicaiton but I believe that the determination of open thermocouple was intended as a feature for those stess systems where a connection could come loose or if it isn't seated correctly it would notify your code.
If you do not see value in the feature then I'll take that as feedback and add it for the next software iteration but we also want to compare what all of our customers are saying as well. If they all feel this was the wrong way to implment this feature and would rather have it as a property node then we'll discuss that later. We don't currently have any plans to change this feature but we certainly appreciate the feedback and will keep this in mind for future implementations.
In order for MII to upgrade to 2014 LabVIEW, the open thermocouple detection error that is generated by the NI-RIO driver has to be mitigated.
If you can follow this thread on NI.com, NI Engineeers are not doing anything about it.
Programatically changing the imbedded program to ignore this error will not “fix it”. This error causes the cRIO to “error” to 0 every channel after the first open one.
This is not acceptable when you have over 200 channels to read, not all of which is connected to a source, given each specific test.
I did not originally understand that every channel was throwing the error when any channel didn't have a thermocouple in the module. We are expecting to release a fix for this is 2014 sp1. Sorry for the confusion. You will now be able to disable the open themocouple detection for the module programmatically.
When will this service pack 1 be available? I have SSP and I did not see anything yet. I have been working in Mexico off and on and it may have arrived, I just didn't see it yet....
It has not been released yet. You should be looking for CAR #441205 which looks to add the ability to disable open thermocouples for the 9213 module.
In the meantime I made a subVI that reads all inputs for a 9213 module and returns an arbitrary number for the open slots (I think I set it to -9999). The VI is attached, to run it you just need to input a 9213 constant and you will receive an array of thermocouple readings as the output.
What is the Open Thermocouple Detection current on the NI 9213?
On page 17 of the manual (372499B-01, July 09), it mentions a small offset voltage error or 0.5 uV per ohm if the source impedance is 50W+ (Watts? - is this a typo?). The offset error of 0.5 uV per Ohm means the current is 50 nA, yes? The NI white paper on Open Thermocouple Detection mentions using the current to compensate for the offset if you know the impedance of your source sensor, and mentions NI hardware varying from 10 nA to 1000 nA, so 50 nA would fit the range, but I don't want to assume I'm interpreting this correctly.