Unfortunately, the NI 9213 does not support disabling the open thermocouple detection functionality. One C-Series module that does support this, however, is the NI 9214.
Thanks for the response.
Could you please check over this document. I have copied some screen shots of the code changes I am trying for the cRIO realtime.
If this is not a good idea, any other suggestions would be appreciated.
I do not have this tested as yet, the portable cRIO system is being used for another test, (we reverted to running 2010 software now). The 2014 software upgrade is causing all this ruckus.
In LabVIEW 2013, the RIO driver was programmed to throw errors that it did not before. This -65582 error is one of them. One way to work around this is to call all the channels of the module inside a for loop, just like the "Programmatic IO Access - Scan Mode.lvproj" in the Example Finder.
I would wire up the TCs to the first channels of the module, and leave the open channels at the end. Otherwise, you could wire dummy connections to all of the open channels.
thanks for the response.
In our applicatioon we have 64 thermocouples, However in another ARTL application we have over 200. This would seem to be a cumbersome solution.
I have already tried to do the dummy Tc connection on a select few channels and the error still trips out at the first open one, and every channels after, within that module.
As another work around - would it be possible to move the two 9213 modules to the EtherCAT chassis? The 9213 Modules in that 9144 seem to function "normal".
It may be in our best interest to revert back to 2010 LabVIEW and not upgrade to 2014 until the open thermocouple error issue is resolved within the cRIO driver.
i am not sure if moving to an EtherCAT chassis will help resolve this issue, since you would still be using the RIO driver to make the function calls to the module itself. As to the issue being fixed, the developers are aware of the issue. Whether this will be changed in future RIO drivers, I am not sure.
If you do not want to use a For Loop to read each channel and either ignore the channel reading or the error itself, then reverting might be the easier solution. However, using a For Loop to check each channel for an open thermocouple should not add very much time to your program.
It looks like you are programmatically reading the channels for your IO Nodes. Is there any reason you can't filter out the channels that are disconnected before reading them? Or can you input a initialization file that tells which channels are invalid?
Having an open thermocouple error I feel would be beneficial should vibration cause a connection to slip and your code can respond or notify a technician to check in on it.
The cRIO chassis acquire via realtime, it is "on" basically 24/7.
The 9 systems running today use this acquired array of numbers for preprocessing, the themocouples are converted to a voltage reading in this acquiring loop, then the main LabVIEW program does most of the other number conversions.
The "*.ini file" is basically the calibration (zero offset and slope) for each channel, the cRIO runs after the *.ini file is loaded. In the main program, we designate which of these channels are required, and assign a color, weight and scale to plot it on and the filename to write the data to. To utilize your solution the technicians would have to change the calibration ini file each test setup.
Since this program is used in Mexico and the US in two different facilities, with 16 different Technicians, some with multiple tests running on a single cRIO,This would be very cumbersome and would not be acceptable.
Is there a verificatoin step for your technicians to ensure all the thermocouples are reading correctly? If the technicians are constantly changing the setup how are they verifying that all the channels are working correctly before they run a test?
Are they running the code from a host PC or is it a startup executable running on the cRIO?
If there is an HMI interface, can you provide the technicians a options dialog to configure which channels to ignore?