Triggering multiple 34401A's

[JohnPi]

I am trying to do simultaneous measurements with two 34401A's over GPIB. Each is setup identically (10V, no autozero, no qutorange, 0.02 NPLC, 4 digit resolution), and I am using GPIB (BUS) triggering (with a trigger delay of 2 ms). I am using 10 samples, but that doesn't affect the issue.

The two meters are identical except for firmware: one is HEWLETT-PACKARD,34401A,0,11-5-2, the other is HEWLETT-PACKARD,34401A,0,10-5-2.

I can't get the two to trigger simultaneously (by observing the VM complete signal on the back). They wander about +/- 100 us from each other, with the 10-5-2 one tending to be earlier than the other 90 % of the time (i.e. the variations aren't symmetrical). The 10 samples are usually, but not always equally spaced. Some other trigger delay settings (e.g. 1.333 ms) cause larger meter-meter variations.

There is no spec for this performance for the meter (there is for the newer 34461A range of meters).

Has anyone seem similar behaviour ? Any ideas ?

FYI -- I'm using pyvisa, and after setup I loop:

Code: [Select]

HP34401A_DMM1.write("INIT")
 HP34401A_DMM2.write("INIT")
 time.sleep(0.2)
 GPIB_BUS.group_execute_trigger(HP34401A_DMM1, HP34401A_DMM2) 

[pigrew]

It's a shot in the dark, but have you tried using the external trigger input (on the back of the meter)?

EDIT: Also, can you input a triangle wave to confirm the measurements are not simultaneous?

[JohnPi]

I have tried that -- I'm trying to digitize a 50 Hz sinusoid (10 samples/cycle) in order to calculate the phase shift between channels. When I trigger from the waveform generator, I often get a whole cycle slip. Given that I expect similar behaviour from adjacent cycles, that might work, but seems inelegant.

I like the idea of using a triangle -- perhaps it is the VM complete that is delayed, but the sampling is correct. I don't think that's the case because my phase results are noisy though the signals are clean.

[pigrew]

Was the jitter any less when using the external trigger?


The 34401A isn't so great at digitizing signals like that.  I think either a multi-channel ADC, oscilloscope, or frequency counter would be better tools...

[babysitter]

At work I am using a very fast measurement mode, no trigger delay, but a trig count of 512, and a external trigger pulse to both inputs (button.) Take care to switch off display. (There is a app note for that.)
Resulting in very nice measurement of 2 synchronous channels. Yeah, get the app note.

(Can post the scpi scripts on monday I think.)

[HighVoltage]

Have you looked at this Keysight Video, using four 34401A instruments:

Automate synchronized DMM measurements using BenchVue Test Flow and Command Expert

[free_electron]

The 'complete' signal is NOT a measure for that.

Depending on the time needed for the rundown cycle of the measurement this will drift ! if the meter is set to 10 volt full scale and you give it 1 volt to digitize the rundown will happen in x amount of time.
if you give it 9 volt to digitize the rundown takes longer because it has to move more charge.

This signal is irellevant it is the sampling point that matters , and that is under either software control, GPIB control or hardware control.

- Software control is unreliable as commands are sequential.

- Bus triggering is better but there is still a chance for phase misalignment. ( if the master clocks of the digitizers and cpu's are off and they differ ever so slightly in frequency there is going to be skew. that is why timing equipment has a 10MHz input. You feed all your equipment a master clock and the problem goes away.

- the TRIG input is your friend. This is a hardware signal that starts the conversion cycle. You hard lock the meter on a range ( do NOT let it autorange ! you don't want that part of the cycle as it is not deterministic ! ). Set it to external trigger through a GPIB command( or frontpanel )
When the trigger comes the hardware sampler will latch the input charge. The runup and rundown occur and you are presented a value. This value is taken at the rising edge of the trigger signal.

if you are doing really critical measurements : use BNC cables with same length and drive the trigger from a common point( do not daisy chain as you are injecting skew )

for 4 multimeters : 4 BNC cables of same length , 3 BNC T pieces , and a 5th bnc cable.


make an H- connected bnc splitter with the 3 BNC T pieces. feed in the center of the H , take the extents with same length cables to the trig inputs.

you will have rock solid measurements

[JohnPi]

Thanks. I am coming to the conclusion that the VM complete is not a reliable indicator of the triggering (sampling) event. Even so, the two meters seem to operate differently.

I applied a 250 Hz 2Vp-p triangle in 1-shot mode (33120A) . Each meter gets the sync from the signal generator, and each waveform in parallel. The typical reading is around -700 mV (related to the phase of the synch with the generated waveform). On each shot, I get a meter-meter variation of up to ~ +/- 50 mV (centered close to 0). This corresponds to +/- 50 us sampling variation. I can see some of that (but not particularly well correlated with) looking at the VM complete signals. (I did this test manually; I had the display on, 4 digits fast, manual range).

I'm going to try other pairs of meters (with identical firmware) next week to see.

[JohnPi]

I made some more measurements with the 2 meters I have and took some statistics. My conclusion is that the two meters have a GET (trigger) to conversion start variability of about 100 us difference between them (I don't care about the absolute delay, just the relative delay between the meters).

I'd try to use a 53132A to measure the delay between GPIB GET and the meter's VM Complete -- does anyone have an example sequence of commands that could get me started ?

[e61_phil]

At work I am using a very fast measurement mode, no trigger delay, but a trig count of 512, and a external trigger pulse to both inputs (button.) Take care to switch off display. (There is a app note for that.)
Resulting in very nice measurement of 2 synchronous channels. Yeah, get the app note.

(Can post the scpi scripts on monday I think.)

That would be very intersting!
And do you have a link to the app note?

[JohnPi]

I setup the 2 meters with an external trigger (func. generator), and measured the delay to VM complete. In fast 4 digit mode, its a few 100's of us, and has a sigma of about 50 us. The 2 meters (with slightly different firmware) have the same variability, but a mean delay that is about 25 us different.

I tried the same experiment with a 34410A, and it is a) much faster, and b) has a delay sigma of << 1 us.

[babysitter]

I came up with...

*RST
*CLS
CONF:VOLT:DC 1.0,0.001
VOLT:DC:NPLC MIN
ZERO:AUTO OFF
VOLT:DC:RANG:AUTO OFF
CALC:STAT OFF
TRIG:SOUR EXT
TRIG:DEL 0
SAMP:COUNT 500
DISP OFF
INIT

after that. you basically just have to fetch.

[free_electron]

I came up with...

*RST
*CLS
CONF:VOLT:DC 1.0,0.001
VOLT:DC:NPLC MIN
ZERO:AUTO OFF
VOLT:DC:RANG:AUTO OFF
CALC:STAT OFF
TRIG:SOUR EXT
TRIG:DEL 0
SAMP:COUNT 500
DISP OFF
INIT

after that. you basically just have to fetch.

yup. that's what i would do. switching the display off speeds up the machine tremendously.

[e61_phil]

Beware of the difference between

Sample:Count
and
Trigger:Count

[babysitter]

Some more words as I had just little time this morning...

This script works on two Multimeters which where bought several years from each other (2012 new faceplate and ~2005 with old faceplate.)
Predefined range over autorange is a must for every dmm in my opinion, Keysightlent strongly advises to turn the display off.

I am using a PROLOGIX GPIB USB Interface and get a sampling rate of 1428Sa/s which is higher than expected, the whitepaper talked about 1 kSa/s. Both meters are used simultaneously triggered with a common button. Made it for a co-worker for sensor step-response measurement, he qualified and never complained and uses it regularly.

[HighVoltage]

Some more words as I had just little time this morning...

This script works on two Multimeters which where bought several years from each other (2012 new faceplate and ~2005 with old faceplate.)
Predefined range over autorange is a must for every dmm in my opinion, Keysightlent strongly advises to turn the display off.

I am using a PROLOGIX GPIB USB Interface and get a sampling rate of 1428Sa/s which is higher than expected, the whitepaper talked about 1 kSa/s. Both meters are used simultaneously triggered with a common button. Made it for a co-worker for sensor step-response measurement, he qualified and never complained and uses it regularly.

Which software are you using?

[babysitter]

HTerm (not to confuse with HyperTerm cancer).

1. Transmit initiation scripts
2. press button
3. transmit fetch scripts to get results (really, not much more besides fetch? and turning display on)
4. import to qtiplot
5.
6. Profit.

[e61_phil]

... get a sampling rate of 1428Sa/s which is higher than expected, the whitepaper talked about 1 kSa/s.

Thats why I'm using Sample:Count 1 and Trigger:Count 500
The measurement triggers a burst of 500 Pulses from the signal generator. This way you have more control over the real sampling rate.

[JohnPi]

That's basically the sequence I am using. After some experiments, this is what I find:

1) When EXT triggering (e.g the Ext Trig signal), triggering is identical for both meters, and the variability is about 10 us (which I can live with).

2) Using the same sequence, but using BUS triggering (Group Execute Trigger) on the bus, triggering delay is highly variable -- 100's of us between the 2 meters (which receive identical GPIB commands), but the 10-05-02 firmware meter is on average about 100 us faster than the 11-05-02 one (but sometimes earlier, sometimes later)

I am using pyvisa -- here is the internal of the loop:

Code: [Select]

  HP34401A_DMM1.write("INIT");HP34401A_DMM2.write("INIT")
  time.sleep(0.5)
  GPIB_BUS.group_execute_trigger(HP34401A_DMM1, HP34401A_DMM2)     
  print(HP34401A_DMM1.query("FETCH?"))
  print(HP34401A_DMM2.query("FETCH?"))

I guess pyvisa could be implementing the GET incorrectly (e.g. sending separate GET messages to each meter), but then I'd have one consistently earlier than the other.

The reason I didn't want to use EXT triggering is that there is a race condition between the 2 meters (I have a 50 Hz sync signal available to trigger them) -- I can't be sure each meter acts on the same edge

[babysitter]

The reason I didn't want to use EXT triggering is that there is a race condition between the 2 meters (I have a 50 Hz sync signal available to trigger them) -- I can't be sure each meter acts on the same edge

Sounds like something you could fix with e.g. a microcontroller or a NAND gate plus Flipflop.

Best regards

Hendrik