setting thermocouple type in scan engine

[kikiduu]

I am using cRIO 9211 to acquire thermocouple data using NI Scan Engine. I don't see any option to specify the type of thermocouple other than by right clicking on the module (in project) and selecting Properties.

Is there a way to programmatically set the type of thermocouple?

If this is not possible, can I can read the cjc and offset channels, so that I can convert the raw voltage to temperature in my RT code?

Will I be able to read the cjc and offset channels if I use NI Scan Engine Advance I/O Access?

[AdnanZ]

When running in scan mode, you won't be able to set the type of thermocouples programatically. The RIO Scan Interface is a set of FPGA intellectual property (IP) developed by National Instruments that is downloaded to the CompactRIO FPGA and is responsible for I/O module detection, timing, synchronization, and communication. The RIO Scan Interface runs a hardware-timed scan loop, which updates the physical I/O values. So, you need to specify what exactly the module is reading before you run the application.

Why don't you run the application on FPGA? You can then convert the raw voltage to temperature in your real-time code, as has been done traditionally. Remember you can run both the FPGA and the RIO Scan Interface together (known as hybrid mode). When using LabVIEW FPGA Mode on one or more modules, the RIO Scan Interface is compiled with the LabVIEW FPGA VI into a single FPGA application. If no modules are configured to use scan mode, the RIO Scan Interface is not included in the compile.

No, you won't be able to do that either since you are still running in scan mode. Remember, the NI Scan Engine Advanced I/O Access API allows you to read and write entire I/O modules using a single call to the NI Scan Engine from a cRIO or EtherCAT device. I don't understand how exactly that's going to help you.

Using NI CompactRIO Scan Mode with NI LabVIEW Software
NI Scan Engine Advanced I/O Access

Message Edited by Adnan Z on 12-14-2008 05:32 PM

[Pranchal Srivastava]

Hi ,
I agree with Adnan . Please let me know if there is anything else you are looking for .
Thanks and Regards ,
Pranchal
NI

[kikiduu]

Hi Adnan,

Till date I have done my cRIO applications in FPGA mode and wanted to try out the scan engine functionality. To be frank, I am quite impressed with it. 

In my application, there is a probability that the TC type used by the client will change. So if I can read the raw voltage values along with cjc and auto zero channels, then with that I can convert each channel reading to temperature in RT. Now reading channel values as voltage is supported in scan engine, but reading cjc and auto zero channels is not. So I was just wondering whether the advanced access I/O provides access to cjc and auto zero channels. 

---

Adnan Z wrote:

No, you won't be able to do that either since you are still running in scan mode. Remember, the NI Scan Engine Advanced I/O Access API allows you to read and write entire I/O modules using a single call to the NI Scan Engine from a cRIO or EtherCAT device.

---

I guess you are right, it looks like I cannot access channels that are not available as IO channel in scan engine.

But shouldn't we have those channels (cjc and auto zero) also exposed by scan engine?

Anyway, I think I have to go back to the  LabVIEW FPGA Interface mode

Thanks for helping.

[AdnanZ]

I guess what you want to do is to replicate the behavior of the FPGA on the Scan Interface, so you can deploy your application much faster. But, that is not what the Scan Engine was designed for. It has been designed for making it easy to drag and drop I/O variables onto your LabVIEW Real-Time and host VI block diagrams and instantly read and write scaled, calibrated I/O data without any FPGA programming or compiling. But, you will be losing all the flexibility, speed and parallelism that FPGA gives you. Also, you can only update the I/O variable values at a rate of up to 1 kHz; so why get FPGA in the first place?

You cannot read raw voltages in scan mode (atleast I don't think you can). So, what use will reading cjc and auto zero be? If you think it's a good idea to expose the raw voltage, cjc and auto zero as channels, you might want to post a suggestion center at the Product Suggestion Center. If you have a good use case for that, be sure to post it over here; it would be nice to know.

[jkurtw]

Hi kikiduu,

They are correct that the advanced I/O access API will not give the CJC value. This API simply gives you better performance and allows you to read and entire module as an array.

One other approach that may work is back calculating the raw voltage from the temperature measurement you make.

For example, if you know that the module is configured as type J and you have a temp of 24 degrees, then you know that your raw voltage is 1.226 according to the table I have linked below. From that raw voltage, you could then calculate the correct temp, based on which thermocouple is actually present.

However, I have not researched this option in depth. It may not be correct if the CJC is used differently depending on the TC type. Perhaps you know 🙂

Programmatic module configuration, such at TC type is something we would like to add in a future version of LabVIEW Real-Time and NI-RIO.

LabVIEW FPGA may be your best bet for the time being, especially since you can continue to use your other I/O modules in scan mode. 

Table of all TC types and Voltage to Temp conversions: 

http://srdata.nist.gov/its90/download/all.tab 

Source of above link:

http://www.temperatures.com/tctables.html 

[kikiduu]

---

Adnan Z wrote:

I guess what you want to do is to replicate the behavior of the FPGA on the Scan Interface, so you can deploy your application much faster. But, that is not what the Scan Engine was designed for. It has been designed for making it easy to drag and drop I/O variables onto your LabVIEW Real-Time and host VI block diagrams and instantly read and write scaled, calibrated I/O data without any FPGA programming or compiling.

---

 By making it easy to drag and drop I/O variables and use it straight away... I guess I will be able to deploy my applications faster, isn't it 

 

---

Adnan Z wrote:

You cannot read raw voltages in scan mode (atleast I don't think you can).

---

I was referring to this...

Message Edited by kikiduu on 12-16-2008 02:26 AM

[kikiduu]

---

jkurtw wrote:

Hi kikiduu,

One other approach that may work is back calculating the raw voltage from the temperature measurement you make.

For example, if you know that the module is configured as type J and you have a temp of 24 degrees, then you know that your raw voltage is 1.226 according to the table I have linked below. From that raw voltage, you could then calculate the correct temp, based on which thermocouple is actually present.

However, I have not researched this option in depth. It may not be correct if the CJC is used differently depending on the TC type. Perhaps you know 🙂

---

WoW!!!Great suggestion jkurtw....I will try it and let you know

[kikiduu]

---

jkurtw wrote:

One other approach that may work is back calculating the raw voltage from the temperature measurement you make.

For example, if you know that the module is configured as type J and you have a temp of 24 degrees, then you know that your raw voltage is 1.226 according to the table I have linked below. From that raw voltage, you could then calculate the correct temp, based on which thermocouple is actually present.

However, I have not researched this option in depth. It may not be correct if the CJC is used differently depending on the TC type. Perhaps you know 🙂

---

jkurtw, I guess back calculating the temperature may not work if scan engine uses cjc as shown in the figure. In this case we will have one equation with two unknowns (thermocouple voltage and cjc voltage for j type thermocouple).

 

Message Edited by kikiduu on 12-16-2008 04:52 AM

[jkurtw]

Hey kikiduu,

Looks like you are correct. I don't see a way to get to Vtc without the CJC temp.

Oh well, it was worth a try!