Setting thermocouple type by Property Node isn't working

[samtbacon]

In my development environment, I am using several cRIO-9063 to take a measurement using a NI 9212 module.  I have been having problems with setting the thermocouple type to k-type.

  To make sure that I am using the correct thermocouple type, I have been using the property node to set the thermocouple type at the start of my vi, and then I am displaying the type during operation on my front panel.  For each cRIO, I have been running the vi from a laptop, verify it runs and shows k-type, and then setting the vi to run on start up.  Because I was setting the thermocouple type to k-type from the property type, and was seeing k show up in my local test, I stopped modifying the NI-9212 module settings to k-type for each cRIO.  However, when checked against a different temperature measurement device, I could clearly see the cRIO's where I had not changed the module from the default setting in the project(NI 9212 defaults to j Type), were measuring using j-type temperature conversion.

  This is really frustrating.  Am I making a mistake when setting the thermocouple property node? and if so, why does it display the proper type when I test it before setting it to run as start up?  I have attached a simplified version of my project that exhibits the same problem.

[JICR]

Did you probe the error out cluster from the property node to see if it says no error?

Also, read the help LabVIEW gives you when you mouse over the TCType property, click Detailed help to understand why it's not working.

[samtbacon]

Yes, I probed out the error out from the property node.  It reports no error.  I also read the detailed help on thermocouple.  I appear to be doing the process correctly.  I also checked the 9212 example project.  In the example they are getting the temperature from the FPGA Target, which is not relevant to my application.  Additionally, the example does not set the module to different types of thermocouples on the module, instead it uses different conversion equations based on the thermocouple type selected.

[RavensFan]

Where is your Module Configuration dialog screenshot in message #1 taken from?  And if I understand your original message correctly, that screenshot was taken after you ran the code in the first image of message #1.  Am I correct?

[samtbacon]

The module configuration dialog was taken from the project explorer.  Yes, that was taken after the code was run.  I was more trying to show that the default is J.

I would not be surprised if the system reverted to J type, but my problem is that even while my VI is running it is appears to be using J type instead of the input I send into the property node.

[RavensFan]

It seems like you were expecting the property node to have changed your project explorer settings.  It does not.

If the project explorer says J, then I expect that is what it would set up the module up as initially.  When you set it to K with a property node, the module will change to K once the code executes that node, but it certainly is not going to edit the project file to tell it is now K.

You say it "appears to be using J type".  What makes you think the property node didn't change the module to K during execution?  J and K type thermocouple outputs  don't tend to be that much different around normal human-comfortable temperatures if I recall correctly.

Why wouldn't you just edit your project file dialog to K and not mess with the property node at all?

[samtbacon]

I appreciate your question.  Perhaps I am approaching this wrong.  So I am trying to use the same VI for several cRIO's. I can edit the project file, but when I set up a new cRIO the module it returns to default thermocouple configuration(J type).  What I am trying to do, as a safety check, have the VI at run type switch the thermocouple to K no matter what.  

Based on your explanation, it should start as J type, but change to K when it executes the property node.  Would you then expect all of the readings after executing the property node to read the temperature assuming it is a k type?  That would be what I want, but it does not seem to be working that way.

Your are correct J and K are close at room temperature.  In operation, I am measuring temperatures around 700 C.  J will read 200 degree's cooler then the actual temperature.  Because of the high temperature it is pretty easy to tell optically see the temperature is wrong because there is stainless steel pieces that start to glow close to 500 C, which reads 370 C if configured as a J thermocouple.

[RavensFan]

---

@samtbacon wrote:

I appreciate your question.  Perhaps I am approaching this wrong.  So I am trying to use the same VI for several cRIO's. I can edit the project file, but when I set up a new cRIO the module it returns to default thermocouple configuration(J type).  What I am trying to do, as a safety check, have the VI at run type switch the thermocouple to K no matter what.  

Based on your explanation, it should start as J type, but change to K when it executes the property node.  Would you then expect all of the readings after executing the property node to read the temperature assuming it is a k type?  That would be what I want, but it does not seem to be working that way.

Your are correct J and K are close at room temperature.  In operation, I am measuring temperatures around 700 C.  J will read 200 degree's cooler then the actual temperature.  Because of the high temperature it is pretty easy to tell optically see the temperature is wrong because there is stainless steel pieces that start to glow close to 500 C, which reads 370 C if configured as a J thermocouple.

---

Yes I am expecting it to change to K on the module once you execute the property node.

But I also expect it to start as K and stay that way if you changed the type to K in the project dialog.  Forget the "safety check" for the moment.  If you do set it for K in the project dialog, does it work correctly then?

So it sounds like you are sure it is reading wrong because you are at high enough temperatures that the reading is obviously incorrect based on your actual environmental conditions.

Is the property node in message one running withing the Real-Time processor of the cRIO?  What do you see if you put an error indicator on that property node.

I'm not familiar with the 9212.  I would hope someone from NI can join in on this conversation as it may be getting beyond my understand of the RIO and module where my first thoughts were that there was a misunderstanding on how the dialog box would be appearing.

[samtbacon]

Yes, if I configure the thermocouple as K in the project dialog and the run the project it works correctly.

Yes, the property is running on the real time processor.  I am not using the FPGA at all for this program.

When I probe the property node, I get no error.  However, in my final configuration, I am setting the cRIO's to boot up to the VI and I obviously cant probe the error node there.  I could try sending the error to a file.

[RavensFan]

That sounds like a good trouble shooting step.

As for probing the error and not being able to; is there any code running on a host PC to communicate with the RIO and to have it display and errors from an error indicator or error wire?

And going back to your safety mechanism, consider trying to set the type to K in the project, and read the type in the code with the property node (assuming that a property node read is working fine.).  If it is J (meaning the operator messed up something in the project, then don't execute the code and do something to warn of an error.  If it is K, then proceed.   I like to use the LED on the cRIO as a blinker to indicate something wrong in the VI when you don't otherwise have visibility through a screen.  I also use the LED to give a regular blink just as an indicator the code is actually running on the device.  So a single blink means running, a double blink means error.  (Triple or more blinks are possible for more messages, which is exactly what NI does with the Status LED.)

My thought with why it might not work is some sort of race condition, that perhaps the project setting gets deployed to the cRIO AFTER the code has starting running (seems like it shouldn't, but who knows).  If that is the case, perhaps a delay at the beginning of our cRIO code would help.  I know Ben has said on some of his projects he found the need to start programs with delays in order to give some processes time to properly initialize.

Just some thoughts I have.