cRIO Variable Connections and Open Thermocouples!

[ckc8302]

I have a couple of cRIO-9073 chassis and I am having a problem with open TC detection and the "Open and Verify Variable Connection" function. Upon startup, my PC-hosted LV datalogging VI reads a "large" number of variable data from a SQL database. Then, data is parsed and formed into PSP shared variable reference strings (ex: ni.var.psp://192.168.85.80/Mod1/RTD00 Ent Dry Bulb) which, when fed to the "Open and Verify Variable Connection" function in a For loop, ends up providing me with an array of PSP refnums for connections to individual cRIO channels.

Now, a couple of the cards in my cRIO are TC cards (NI 9214). If I enable the "Open TC Detection" option, my "Open and Verify Variable Connection" function will return an error at every open TC (and not a specific error that I can attribute to an Open TC, but a general read error). This is not desirable, as I need to be able to acquire variable connections to all channels regardless of whether there is currently a TC connected or not. Technicians must be able to disconnect and reconnect TCs anytime without fear of communication loss to the cRIO variable. 

On the other hand, if I turn OFF the "Open TC Detection" option, everything works beautifully but I am completely unable to determine when there is an open TC. We are using type T thermocouples, so open TCs often read something like 80-90F, which is a very reasonable reading.

So my question is this: How can I maintain all of my variable connections while still being able to detect an open TC? 

Am I simply using an incorrect method for connecting to the cRIO variables, or does someone have another common solution?

Thanks in advance for reading about my headaches.

Chris

[HollyBerry]

Hi Chris,

I haven't been able to find a reason why the NI-9214 with OTD enabled would not work with Shared Variables. Can you possibly upload a screenshot of the error you were receiving and a screenshot of how your shared variabel reads are setup?

[ckc8302]

HollyBerry,

Sure. Here is a screenshot which includes this simple section of code structure and also shows a probe watch window with an example of the error that occurs when OTD is enabled. It seems that the error I'm getting is a general timeout error. This is strange because I have the timeout set to 3000mS; plus I have a Specific Error Handler in the error cluster coming out of the function (which is setup to reattempt up to 5 times on error).

It appears as though this error occurs on every open TC (with OTD enabled).

Thank you for looking into this for me! Please let me know if you have any suggestions for me.

[HollyBerry]

Have you verified the program is actually running on the cRIO when you are trying to access these variables from the host side? You could try adding a heartbeat pulse to one of the user LEDs to easily see when the program is running or not. You could also create a debuggable executable on the RT target to use the diagnostic techiniques available in the development environment after the program has deployed. 

Once you verify the program is running on your cRIO, see if you can connect/read the variables from Distributed System Manager. Can you see them here or are you getting a timeout?

[ckc8302]

HB,

As you can see in the screenshot, there is a For loop that is iterating through the input array "IOV Refnums", and attempting to "Open and Verify Variable Connection" for each reference. This works perfectly fine for every reference (including all other TCs on all cRIO card slots); except when the reference is referring to a TC that is currently open on a card which is set with OTD "On". If the TC is not open, no error. If OTD is set to "Off", no error. So, I do not believe that there is a lack of communication; if i change the OTD to off and deploy the card, the error no longer occurs. As far as using the DSM, I do use that often for troubleshooting as well. The DSM shows a value for all TCs (even open TCs) regardless whether the OTD is on/off; the difference is that the reading for an open TC is either 237.52 (OTD On), or some unpredictable number (OTD Off). When the OTD is off, the value often displays as something reasonable (like 80.6 F) even though the TC is truly open.

Does this answer what you were trying to explain to me, or did I misinterpret what you were looking for?

[HollyBerry]

Hi Chris,

I agree with you that you probably do not have connectivity issues. However, I was wondering if there was something that was preventing the cRIO from publishing these values when you have the OTD set. For example, with this setting, perhaps the shared variables are erroring out for some reason and are never being shared with the network. If these shared variables are receiving an error with the OTD setting turned on, depending on your error handling, it may be stopping the program running on your cRIO. I just wanted to rule out these possiblities.

It sounds like you are able to read from the variables from DSM which shows that the cRIO is publishing that data. That leads me to believe my above assumption is probably false and the shared variables are probably not erroring out. However, the values do seem extreme. Is that 237.52 value in deg F? You said when OTD is off, the readings are unpredictable but are in the right ranges. What TC are you using?

I'll ask around to see what other information I can find. 

[ckc8302]

Yes, we have the TC card preferences set to degrees F. We are using type T thermocouples.

[Shane-C]

Hey, 

Sounds like the readings are rather uppredictable.  I know you posted a section of your code, but have you tried the example code which demonstrates doing this?  Perhaps the error is occuring elsewhere.  The following link shows how to use the OTD, as well as shows where the examples I am referencing are stored locally on your machine.  Try one of them and let me know if it makes a difference.

http://www.ni.com/white-paper/12334/en/

[ckc8302]

Shane-C,

I finally got a chance to attempt the locally-stored NI examples for TC OTD and they do seem to detect open TCs accurately using FPGA code structure. This seems to prove that I can rework my RT code to adopt the FPGA paradigm and accurately detect open TCs, however, it does not solve the fact that I am not currently able to use OTD with the "Open and Verify Variable Connection" function. I was really hoping that someone would be able to lead me to a solution to my current problem for the short term. I would like to adopt FPGA in the long term. But I have not coded any direct FPGA structures before, so I'll have to look at some of the self-paced training on that.

Thanks,

Chris Campbell

[Shane-C]

Chris,

I was digging through some of our records today and found that someone had this behavior occur every time they tried to detect open thermocouples in an array vs reading a single thermocouple open circuit.  Can you wiring up only a single thermocouple with an open circuit, then try to read it and see what the result is?