HP3458A OCOMP, DELAY-related problems

[Echo88]

To log the data of my HP3458A im using Python on Windows via a GPIB-USB-HS-adapter, which works wonderfully. However: i have trouble configuring OCOMP and DELAY.
Here are the detailed problems:
When i try to activate OCOMP or try to set the DELAY to lets say 2s while i have NPLC=100 configured, then i get a timeout error: VisaIOError: VI_ERROR_TMO (-1073807339): Timeout expired before operation completed.
When im extending the permissible Timeout in Python to 5s the DELAY-function works with 100NPLC.
With NPLC=100, Timeout = 5s, DELAY = 2s and OCOMP activated im getting a Timeout-error again.
With NPLC=10, Timeout = 5s, DELAY = 2s and OCOMP it works.
With NPLC=100, Timeout = 25s (thought the 3458A might need that much time during OCOMP-config), DELAY = 2s and OCOMP activated im getting a Timeout-error again.

Is that a known error or is there something wrong with my initialization-routine? Maybe ive overlooked something in the manual? The code im using to test this procedure:

import sys
import time
import visa

rm = visa.ResourceManager()
rm.list_resources()
HP3458A = rm.open_resource("GPIB::22")

HP3458A.timeout = 5000
HP3458A.write("*rst; status:preset; *cls")
HP3458A.write("PRESET NORM")
HP3458A.write("OFORMAT ASCII")
HP3458A.write("TARM HOLD")
HP3458A.write("TRIG AUTO")
HP3458A.write("NRDGS 1,AUTO")
HP3458A.write("OHMF 1000")
HP3458A.write("OCOMP ON")
HP3458A.write("DELAY 1")
HP3458A.write("NPLC 10")
HP3458A.write("MEM OFF")
HP3458A.write("END ALWAYS")
HP3458A.write("NDIG 9")
HP3458A.write("DISP MSG,\"                 \"")
HP3458A.write("DISP ON")

min = 0
while min <= 10000000:
    min+=1
    HP3458A.write("TARM SGL,1")
    data = HP3458A.read()
    print (time.strftime("%d/%m/%Y-%H:%M:%S;") + ("[%8d]: %16.16f" % (min, float(data) ) ))

[TiN]

OCOMP with DELAY takes real long time, so your GPIB controller need to have timeout set to 60 seconds or more.

[dacman]

Auto Zero will cause the read rate to be half what the NPLC setting implies.  OHMF, DELAY, and OCOMP all add to the time required.

[dl1640]

Set a longer time out or I would serial poll to get data available status rather than wait for a defined time period.

[Dr. Frank]

The explanation is a bit different.

At first, 4W plus OCOMP ON needs 4 measurement phases per NPLC 10. NPLC 10 integration time equals 200ms in Germany, so one NPLC 10 measurement w/o DELAY takes about 0.8sec.

The DELAY will occur twice per NPLC 10 for OCOMP ON, because one measurement is done with current on and one with current off. So total time will be 0.8 sec + 2x DELAY time. That is 4.8 sec for your example.

2nd, NPLC 100 is not simply a 4 Phase measurement with two DELAYs, as above.
Instead, 10 measurements with NPLC 10 are done, so you also get 10 times 0.8sec plus 20 x DELAY, which busts your TIMEOUT, being 48 sec for your example.

I recommend two things in your case:

1st, a longer DELAY is needed mainly for 10kOhm (1-2 sec) and 100k (5sec).
For 1kOhm and less,  you can set DELAY to the default of 30msec, as usually there will be no big settling effect due to OCOMP current switching.
For 1MOhm range and above, OCOMP is not used at all, so any DELAY is useless, use the standard delay of 30msec also.

2nd, instead of using NPLC100, use APER 1, which makes one long measurement only, i.e. 4 phases of 1sec plus 2x DELAY. The equivalent NPLC 50 would need 8 X DELAY longer.

Frank

PS: If using 4W and OCOMP ON, you can turn AZERO off, which might increase the measurement speed. (Didn't check the timing early this morning)

Either 4W or OCOMP ON mode (don't remember right now) already performs the needed subtraction, which is equivalent to AZERO, so you won't see a different reading, nor a drift.

The 3458A FW is a bit stupid in this case, but on the 34465A / 34470A, the AZERO key directly vanishes, when you use either 4W or OCOMP ON. On latter instruments, NPLC100 also does not chop the measurement into 10 times NPLC 10, so the delays occur only 2 times instead of 20 times.


PPS: All these special timing considerations are nowhere mentioned in the manuals or application notes.
You have to test that manually, by yourself.

[dl1640]

I agree.
Use SPOLL to read the status byte at specified interval say 1s, then it is easy to check how long time a reading is available by refering the value of status byte, also it is helpful to determine the time ACAL needs, without interrupting internal processing.
Then one can proceed to other commands.


edit,
in this case, no need to set timeout to a large value.

[Echo88]

Thanks for the answers and special thanks to Dr. Frank for taking the time to explain the various timings. Im sure this will also help others to better understand the 3458A. 
I will increase the permissible timeout to more than 60s and check the various possible settings how long each will take for a sample (especially autozero on/off during OHMF-mode).

Is it correct that Aperture = 1s doesnt improve the measurement compared to NPLC=50 apart from reducing the measurement time? Since the noise diagram in the specifications refer to NPLC, i guess not.

[Dr. Frank]

You're welcome.. I'm also greatly interested in complete understanding of the 3458As timing, and possible measurement time optimization.
Especially AZ in Ohm mode is not transparent, and difficult to identify. I did not use AZERO OFF for my Ohm measurements, I have to admit.

As an additional hint, the OCOMP mechanism is easily accessible by monitoring the voltage over the DUT. That way I found the difference in NPLC 100 timing between the 3458A and the 34465A.

I also doubt, that APER 1 gives measurable better noise performance than NPLC 50, because the averaging directly inside the A/D is equivalent to the mathematical averaging for NPLC 50. One slight difference might arise from lesser switching spikes at APER 1 compared to NPLC 50. 

APER parameter is limited to 1 sec at most, in contrast to NPLC, which may become 20sec sampling time.
That may explain, why APER 1 is not specified by HP.

During the big DMM noise experiment of TiN, I don't remember, whether APER was also examined by some 3458A owners.. but the difference would probably vanish in the StD variations.

Frank

[TiN]

I have comparison running now on meter over resistors set 1R-100MR (5700) with NPLC100 and APER1 setting. Will post data once done .

[Kleinstein]

The resistance provided by the calibrator might include more parasitic capacitance than one usually gets from normal resistors connected with not so long cables. So it may take some extra waiting time with the 5700 than normal.

[TiN]

Here's some thinking material

[IanJ]

Hi all,

This thread has given me some thinking material to use for my own Windows based 3458A GPIB. I was finding that if the 3458A was busy (large NPLC etc) then my Excel macro's would lock up and sometimes (worst case) crash. No status bytes or anything on the 3458A are available to read when it is busy.

I am using a PCI GPIB card (not USB), and my drivers are:-

Code: [Select]

    Dim ioMgr As VisaComLib.ResourceManager
    Dim instrument As VisaComLib.FormattedIO488
    Set ioMgr = New VisaComLib.ResourceManager
    Set instrument = New VisaComLib.FormattedIO488
    Set instrument.IO = ioMgr.Open(inst_address)
Ian.

[dl1640]

Mostly I use NI GPIB-USB-HS+
My program is created by VBA and NI routines are called to control the instrument. On 3458A it's not recommended to read status byte by *STB? command during the instrument is busy, because it will return a message only after DMM is not busy or a timeout comes, try to use GPIB command to serial poll a single device, it will just reflect the real-time status and DMM can still be busy doing its job
, the routine called is ReadStatusByte, in VBIB32 I think..

[dl1640]

AZERO OFF will speed up the readings per second, but need to consider additional tempco, apparently the resistance spec is given under a dedicated conditions with remote control.