AnsweredAssumed Answered

34980A (with 34921A module) returns an incorrect 1st measurement with READ?

Question asked by jyarington on Mar 17, 2014
Latest reply on Mar 27, 2014 by tomc
First time posting on these forums - please let me know if there is any more information you need from me.

I'm seeing an interesting, intermittent issue with my Agilent 34980A.  Occasionally, the first reading returned from a READ? command will look like it belongs from the last set of data.  For example:

_Reading, before issue occurs:_
Command: READ?
Response: Command: READ?
Response: +6.26840000E+01,00000000.028,1022,+6.66390000E+01,00000000.029,1022,+6.92670000E+01,00000000.031,1022,+6.14390000E+01,00000000.033,1022,+6.66450000E+01,00000000.035,1022,+6.98400000E+01,00000000.036,1022,+6.04200000E+01,00000000.038,1022,+6.61540000E+01,00000000.040,1022,+6.97080000E+01,00000000.041,1022,+6.67110000E+01,00000000.043,1022,+6.38460000E+01,00000000.045,1022,+7.01980000E+01,00000000.047,1022,+6.61870000E+01,00000000.048,1022,+6.27450000E+01,00000000.050,1022,+7.09250000E+01,00000000.052,1022,+6.60440000E+01,00000000.054,1022,+6.41270000E+01,00000000.055,1022,+6.69970000E+01,00000000.057,1022,+6.99720000E+01,00000000.059,1022,+6.20280000E+01,00000000.061,1022,+6.56860000E+01,00000000.062,1022,+7.04130000E+01,00000000.064,1022,+6.07610000E+01,00000000.066,1022,+6.64240000E+01,00000000.067,1022,+6.96140000E+01,00000000.069,1022,+6.60280000E+01,00000000.071,1022,+6.26340000E+01,00000000.073,1022,+7.02640000E+01,00000000.074,1022,+6.65950000E+01,00000000.076,1022,+6.14550000E+01,00000000.078,1022,+6.94320000E+01,00000000.080,1022,+6.68600000E+01,00000000.081,1022,+6.38520000E+01,00000000.083,1022,+6.63090000E+01,00000000.085,1022,+6.92610000E+01,00000000.086,1022,+6.26670000E+01,00000000.088,1022,+6.61650000E+01,00000000.090,1022,+7.10570000E+01,00000000.092,1022,+6.44910000E+01,00000000.093,1022,+6.55590000E+01,00000000.095,1022,+6.93880000E+01,00000000.097,1022,+6.63200000E+01,00000000.099,1022,+6.27830000E+01,00000000.100,1022,+7.13000000E+01,00000000.102,1022,+6.60220000E+01,00000000.104,1022,+6.24910000E+01,00000000.106,1022,+6.90470000E+01,00000000.107,1022,+6.73940000E+01,00000000.109,1022,+6.18360000E+01,00000000.111,1022,+6.54990000E+01,00000000.112,1022,+7.07980000E+01,00000000.114,1022


_Reading, after issue occurs:_
Command: READ?
Response: *+6.35270000E+01,00000000.061,1021,*+6.73031640E+01,00000000.101,1021,+6.72392130E+01,00000000.140,1021,+6.71827970E+01,00000000.179,1021,+6.74127240E+01,00000000.218,1021,+6.73435180E+01,00000000.257,1021,+6.72775840E+01,00000000.296,1021,+6.72166070E+01,00000000.335,1021,+6.71587040E+01,00000000.374,1021,+6.71546390E+01,00000000.413,1021,+6.71966780E+01,00000000.456,1021


That first measurement, 63.5270000, looks like it belongs with the previous set of data, as it matches the level of precision (3 places past the decimal).  However, it is marked with a timestamp (0.061) and channel (1021) that fit with the second set of data.  In my test sequence, when this problem happens, the issue propagates to each following READ? command until the test fails.  (Note: This isn't a random chance that the I got extra zeros in a reading - I've seen this issue several times a day)

My first attempt to fix was to always take an extra measurement and throw out the first value.  This allowed the test to pass where before an incorrect "5" was averaged with "30"s.  However, once the problem reached a test where I read from two channels, the error caused the readings to "flip"

_Good Reading_
Command: READ?
Response: +2.02564530E-02,00000000.122,1041,+1.09441009E-02,00000000.161,1042,+2.02550910E-02,00000000.200,1041,+1.09436738E-02,00000000.239,1042,+2.02529520E-02,00000000.278,1041,+1.09431107E-02,00000000.317,1042,+2.02510070E-02,00000000.356,1041,+1.09427613E-02,00000000.395,1042,+2.02484780E-02,00000000.435,1041,+1.09421594E-02,00000000.474,1042,+2.02459490E-02,00000000.513,1041,+1.09417711E-02,00000000.556,1042

Discarded:
0.020256

1041:
0.020255
0.020253
0.020251
0.020248
0.020246

Discarded:
0.010944

1042:
0.010944
0.010943
0.010943
0.010942
0.010942

_Bad Reading_
Command: READ?
Response: +7.82641360E-03,00000000.122,1041,+2.02869920E-02,00000000.161,1042,+1.09598273E-02,00000000.200,1041,+2.02856300E-02,00000000.239,1042,+1.09593419E-02,00000000.278,1041,+2.02836850E-02,00000000.317,1042,+1.09590118E-02,00000000.356,1041,+2.02813510E-02,00000000.395,1042,+1.09584294E-02,00000000.435,1041,+2.02788220E-02,00000000.474,1042,+1.09580799E-02,00000000.513,1041,+2.02764880E-02,00000000.556,1042

Discarded:
0.007826

1041:
0.010960
0.010959
0.010959
0.010958
0.010958

Discarded:
0.020287

1042:
0.020286
0.020284
0.020281
0.020279
0.020276


So this has lead me to believe that there is a stray "value" stuck somewhere inside the Agilent.  Whenever a new scan is started, that "value" gets taken first, offsetting everything that follows, causing multiple channel scans to flip-flop, and leaving a new value to disrupt the next test.

So far I have tried: (none of which worked)
Using INIT and FETC? instead of READ?
Commanding SYST:OPON 1 to reset the scanning channel
Sending *IDN?, hoping that would clear out some buffer

I have not ruled out the issue lying within my testing process.  When the issue occurs, it starts at the same point of my test sequence every time.  It also only occurs when testing a particular variant (high voltage unit).  I have not been able to find anything in my code that is unique to the high voltage variant that would cause issues with measurements (the only differences happen with commands to open/close relays, also controlled by the 34980A)

I'm sure there is more information you need to help me troubleshoot - let me know and I will be happy to provide more information.  I appreciate any help you can provide.

Thank you,
James  

Outcomes