Thermocouple measurements insists in using "Fixed Reference Junction" - AG34980A

[FBro]

I'm trying to read some thermocouples from an AG34980A with 34921T terminal block using Labview 2018. I'm using the "AG34980A Configure Thermocouple.vi" to configure the channels to read Type-T thermocouples with the "internal" reference junction. But when I read them using the "AG34980A Measure Thermocouple.vi" it changes the reference junction back to "Fixed" and gives me wrong results.

I opened the "AG34980A Measure Thermocouple.vi" and it is sending this command: MEAS:TEMP? TC,T,DEF,(@1001:1040,2001:2020). In the past I used exactly this VIs to measure thermocouples using AG34980A and it always worked (LV2014).

I posted this same question at Keysight community: https://community.keysight.com/message/95539. If I have solution there I'll post it here also.

PS: this VI's came from the Labview Drivers supplied from Keysight for this instrument and are not supported by National Instruments.

[FBro]

In order to verify if there was any difference between the messages sent by the old application and the new one I traced it using the NI I/O Trace and it seems that it is writing the same message, but reading different results.

LV2012 Application:

1. viWrite (GPIB0::9::INSTR (0x037DBD70), "MEAS:TEMP? TC,T,DEF,(@1001:1040,2001:2014)", 42 (0x2A), 42 (0x2A))
Process ID: 0x000027F4 Thread ID: 0x0000277C
Start Time: 14:25:59,0539 Call Duration 00:00:00.0019
Status: 0 (VI_SUCCESS)

2. viSetAttribute (GPIB0::9::INSTR (0x037DBD70), 0x3FFF001A (VI_ATTR_TMO_VALUE), 10000 (0x2710))
Process ID: 0x000027F4 Thread ID: 0x0000277C
Start Time: 14:25:59,0559 Call Duration 00:00:00.0009
Status: 0 (VI_SUCCESS)

3. viRead (GPIB0::9::INSTR (0x037DBD70), "+2.42220000E+01,+2.42700000E+01,...-3.42570000E+01,+9.90000000E+37.", 1024 (0x400), 864 (0x360))
Process ID: 0x000027F4 Thread ID: 0x0000277C
Start Time: 14:25:59,0569 Call Duration 00:00:02.3962

Current Application:

1. viWrite (USB0::0x0957::0x0507::MY44005022::INSTR (0x00000002), "MEAS:TEMP? TC,T,DEF,(@1001:1040,2001:2020)", 42 (0x2A), 42 (0x2A))
Process ID: 0x00001F50 Thread ID: 0x00001FF8
Start Time: 14:29:33,1212 Call Duration 00:00:00.0007
Status: 0 (VI_SUCCESS)

3. viSetAttribute (USB0::0x0957::0x0507::MY44005022::INSTR (0x00000002), 0x3FFF001A (VI_ATTR_TMO_VALUE), 10000 (0x0000000000002710))
Process ID: 0x00001F50 Thread ID: 0x00001FF8
Start Time: 14:29:33,1220 Call Duration 00:00:00.0000
Status: 0 (VI_SUCCESS)

4. viRead (USB0::0x0957::0x0507::MY44005022::INSTR (0x00000002), "-2.06500000E+00,-2.02900000E+00,...+9.90000000E+37,-1.66800000E+01.", 1024 (0x400), 960 (0x3C0))
Process ID: 0x00001F50 Thread ID: 0x00001FF8
Start Time: 14:29:33,1220 Call Duration 00:00:02.6601
Status: 0 (VI_SUCCESS)

[FBro · Accepted solution]

Problem solved. I don't know exactly in which step I did fix it so I wrote down all the steps I made.

1. I uninstalled the NI-VISA 20.0 from the application PC, because the the NI-VISA from the developer PC was the 18.5;
2. The uninstallation wasn't successfully done. When I tried to install the NI-VISA 18.5 it kept saying that I had a higher version already installed. So I had to manually remove the NI-VISA 20.0 from the Windows Register.
3. I've installed the NI-VISA 18.5, but a message saying that the VISA .NET 5.5 wasn't found appeared during the installation so after installing it I did a "repair" using the Package Manager in order to complete the installation.
4. After all that I've compiled a new version of the application, which still was getting me the wrong thermocouple values. Then I started to recompile the application to prior Labview values, because I realized that an older application with different features was actually reading it right. The recompilations also didn't work.
5. I downloaded the Agilent AG34980A 2005 drivers and recompile the version using it.
6. Revised the whole data acquisition code and realized that during one of the above steps I inserted a "reset" before reading the thermocouples. I recoded it and finally it worked, although I don't know exactly in which step it started to work... One thing I'm sure is that the first code was correct, because I returned to that version.

I'm completing the circle here because maybe someone can benefit from this information in the future.