New Agilent 34461A 6.5 Digit Bench Multimeter

[plesa]

The fastest readings which I achieved
34411A  4476 readings/sec with NPLC 0,001
34461A  991 readings/sec with NPLC 0,02

The most fancy will be faster but continuous reading.

[neslekkim]

DISP:STAT OFF ?
if you only use lan or usb, would it have any point to disable the other also?

and for reading, is it typically DATA:REM 10 or SAM:COUN 10 ? / READ ?

And is it only the document named "Agilent Truevolt Series DMM Operating and Service Guide" that contains anything of interrest?

[Sparky]

The fastest readings which I achieved
34411A  4476 readings/sec with NPLC 0,001
34461A  991 readings/sec with NPLC 0,02

For the 34461A, this seems very reasonable --- the data sheet lists 1000 readings/sec.

The result for 34411A seems very far off reported maximums in the data sheet/users guide.  On p126 of the 34411A Users Guide it says that with 0.001 NPLC, 50k readings/sec is possible (for DCV, DCI and 2-Wire resistance measures).

Refer to the footnotes on p135 (pic attached) for the conditions for maximum measurement rate:
[1] ½ scale input signal, immediate trigger, trigger delay 0, autozero off, autorange off, no math, 60 Hz line, null off, sample count 50000, trigger count INF

Many of the suggestions from mojo-chan can be found in the footnotes in the Specifications of the Users Guide.

[Sparky]

The result for 34411A seems very far off reported maximums in the data sheet/users guide.  On p126 of the 34411A Users Guide it says that with 0.001 NPLC, 50k readings/sec is possible (for DCV, DCI and 2-Wire resistance measures).

That is the theoretical maximum if the readings are going directly to the DMM's RAM. It has 1M samples of memory so 20 seconds at 50k samples/sec, but the datasheet kind of implies that 50,000 samples is the maximum count, i.e. only 1 second.

If you try to stream at the same time as recording I bet it won't get anywhere near that speed.

The table I posted says "Direct I/O Measurements, any remote interface, Sustained maximum reading rate..."  For DCV and 2-Wire ohms, it states 50k readings per second, which I interpret as continuous streaming of measurements.  Even if it is a theoretical maximum, it is a lot higher than "34411A  4476 readings/sec with NPLC 0,001" reported by plesa.  That's all that I was getting at when I said "The result for 34411A seems very far off..."  There are a lot of settings (as listed under the table), for how to achieve the maximum rate; perhaps plesa can compare his setup to those settings.


I didn't notice, but where/how does the data sheet imply that 50,000 samples is the maximum count, i.e. only 1 second and not 20 seconds of continuous measurements?  Thanks!

[plesa]

Short update.
34411A   6966 readings/s
34461A   1088 rediangs/sec
Disabling display makes only small difference and disabling interface seems to have some dependency.

[KedasProbe]

I didn't notice, but where/how does the data sheet imply that 50,000 samples is the maximum count, i.e. only 1 second and not 20 seconds of continuous measurements?  Thanks!

I read it somewhere in the command spec, but I can't remember where. Actually the number is for single shot recordings, if you stream you can obviously keep going forever.

If it's the same as the DM3068 then you need to multiply this 50000 with the number of triggers.

[Sparky]

I didn't notice, but where/how does the data sheet imply that 50,000 samples is the maximum count, i.e. only 1 second and not 20 seconds of continuous measurements?  Thanks!

I read it somewhere in the command spec, but I can't remember where. Actually the number is for single shot recordings, if you stream you can obviously keep going forever.

I need to do some continuous temperature measurements on my 34461A, so I've followed up on the trigger and sample count aspect.  The following is all relevant to single trigger recordings, but it's a clarification nonetheless:

For the 34461A, the User's Guide (p 114) says:
"You can use the specified sample count (SAMPle:COUNt) in conjunction with a trigger count (TRIGger:COUNt), which sets the number of triggers to be accepted before returning to the "idle" trigger state. The total number of measurements returned will be the product of the sample count and trigger count."

And it gives an example: return ten sets of five DC voltage measurements, using a positive-going external trigger to start each measurement set:

Code: [Select]

CONF:VOLT:DC
SAMP:COUN 5
TRIG:COUN 10
TRIG:SOUR EXT;SLOP POS
READ?
Typical Response: +1.00520000E+01, … (50 measurements)
It seems you could collect 10k samples with just one trigger using: SAMPle:COUNt 10000, TRIGger:COUNt 1
At the maximum 1000 samples/Sec, that would be a 10sec acquisition time.


For the 34410A and 34411A the relevant User's Guide (p 71) says:
"By default, when the multimeter is in the wait–for–trigger state, it takes one reading (or sample) each time you trigger the multimeter. You can, however, instruct the multimeter to take up to  50,000 readings (up to 1 million for the 34411A/L4411A) each time a trigger is initiated, whether from the front panel or remote interface."

In the spec's (p 137) it confirms:
Triggering and Memory
Samples per Trigger: 1 to 50,000 (34410A)
                                  1 to 1,000,000 (34411A/L4411A)

So according to the spec's it should be possible to acquire 50k Samples/sec on the 34411A, continuously for 20sec, and fill up the 1M sample memory.

The table I posted says "Direct I/O Measurements, any remote interface, Sustained maximum reading rate..."

That would be nice, but I'd be surprised if you could do it over GPIB for example. Maybe the DMM can do it but most PC GPIB interfaces can't.

Anyway, post working code that demonstrates it... Until then it is theoretical. Agilent certainly can't produce any code that proves it, which is kind of hilarious considering they advertise it as a feature.

On the sample blog mentioned by neslekkim, it has a page on Using a DMM as a Low Frequency Analyzer, and with reference to the 34411A it says "The sample rate is adjustable and ranges from around 1 S/s at greater than 20 bits of resolution to 50 KS/s at 14 bits of resolution. At 50 KS/s we can analyze signal frequency components below 25 KHz."  A MATLAB and VEE program are provided to test!  plesa I wonder if you checked those programs with your 34411A?  Would be great to hear if you can increase the sample rate from your latest result.

[neslekkim]

aha, I was wondering why i got that Error sign..
I was messing around with Benchvue and iotrace(?), and I had to reboot the meter afterwards, it thought it still was controlled remotely, and the error sign did not go away

[alex.forencich]

You can set the trigger count to "INF" (infinite) for unlimited sampling. If you don't keep clearing the buffer and it overflows you will get an error on the DMM's display.

How do you get a regular trigger in this mode?  As far as I can tell, the only trigger options are 'bus', 'immediate', and 'external'.  Bus and immedate both require a command to be sent to he meter to take a measruement, so the trigger jitter will depend on the jitter of the commands from the control software (which will likely be pretty bad).  External requires an external trigger source, so this is not really all that useful.  Is there any to get the meter to take an arbitrary number of samples separated by the trigger delay, without any time-dependent intervention by the control software?

[Sparky]

Is there any to get the meter to take an arbitrary number of samples separated by the trigger delay, without any time-dependent intervention by the control software?

Yes, there is.  From the 34461A users guide (p 255):

TRIGger:DELay  Sets the delay between the trigger signal and the first measurement. This may be useful in applications where you want to allow the input to settle before taking a measurement or for pacing a burst of measurements.

Also see: SAMPle:COUNt  and  TRIGger:COUNt

[alex.forencich]

Is there any to get the meter to take an arbitrary number of samples separated by the trigger delay, without any time-dependent intervention by the control software?

Yes, there is.  From the 34461A users guide (p 255):

TRIGger:DELay  Sets the delay between the trigger signal and the first measurement. This may be useful in applications where you want to allow the input to settle before taking a measurement or for pacing a burst of measurements.

Also see: SAMPle:COUNt  and  TRIGger:COUNt

Yes, but this is limited to the maximum SAMPLE:COUNT setting.  If I want to take an arbitrary number (say 100,000,000) measurements, how do I do that?  On my 34401A, I can do up to 50,000 before I have to send the meter another trigger, and this will interrupt the measurement flow.  My question is how do you work around this?  You can set trigger:count to inifinity, but it is not clear to me how to utilize this. 

[Sparky]

Is there any to get the meter to take an arbitrary number of samples separated by the trigger delay, without any time-dependent intervention by the control software?

Yes, there is.  From the 34461A users guide (p 255):

TRIGger:DELay  Sets the delay between the trigger signal and the first measurement. This may be useful in applications where you want to allow the input to settle before taking a measurement or for pacing a burst of measurements.

Also see: SAMPle:COUNt  and  TRIGger:COUNt

Yes, but this is limited to the maximum SAMPLE:COUNT setting.  If I want to take an arbitrary number (say 100,000,000) measurements, how do I do that?  On my 34401A, I can do up to 50,000 before I have to send the meter another trigger, and this will interrupt the measurement flow.  My question is how do you work around this?  You can set trigger:count to inifinity, but it is not clear to me how to utilize this.

Ah, so you need the DMM to continuously acquire readings, and in the background transfer data to your PC.  In a blog post mentioned earlier Continuous Measurements with a 34461A Digital Multimeter the author writes:

"DATA:REM? X, WAIT - This command tells the DMM to take an X number of readings from its reading buffer and send them to the PC. If the number of readings is not available then the WAIT parameter tells the DMM to wait until they are available before sending it over. This command and R? are the the most efficient reading commands for the DMM to process.

These commands are also supported on the 34410A and 34411A...."

So, DATA:REM? X, WAIT may do what you want, but I don't know if it's supported on 34401A.

[alex.forencich]

Is there any to get the meter to take an arbitrary number of samples separated by the trigger delay, without any time-dependent intervention by the control software?

Yes, there is.  From the 34461A users guide (p 255):

TRIGger:DELay  Sets the delay between the trigger signal and the first measurement. This may be useful in applications where you want to allow the input to settle before taking a measurement or for pacing a burst of measurements.

Also see: SAMPle:COUNt  and  TRIGger:COUNt

Yes, but this is limited to the maximum SAMPLE:COUNT setting.  If I want to take an arbitrary number (say 100,000,000) measurements, how do I do that?  On my 34401A, I can do up to 50,000 before I have to send the meter another trigger, and this will interrupt the measurement flow.  My question is how do you work around this?  You can set trigger:count to inifinity, but it is not clear to me how to utilize this.

Ah, so you need the DMM to continuously acquire readings, and in the background transfer data to your PC.  In a blog post mentioned earlier Continuous Measurements with a 34461A Digital Multimeter the author writes:

"DATA:REM? X, WAIT - This command tells the DMM to take an X number of readings from its reading buffer and send them to the PC. If the number of readings is not available then the WAIT parameter tells the DMM to wait until they are available before sending it over. This command and R? are the the most efficient reading commands for the DMM to process.

These commands are also supported on the 34410A and 34411A...."

So, DATA:REM? X, WAIT may do what you want, but I don't know if it's supported on 34401A.

The issue is not transferring the measurements, it is taking them in the first place. 

If I want to take 1 measurement every second for a week (1.2 million samples), all I need to do is write a script to trigger every measurement and then read it out.  With some careful coding and a computer that reports times to a sufficient resolution, this works well. 

If I want to take 100 measurements per second for 10 seconds (1000 samples), I can configure the meter to do that with the samples:count seting and the trigger:delay setting, trigger it once, and stream out all of the samples so the memory does not overflow.  Not too bad. 

However, if I want to take 100 measurements per second for two weeks  (120 million samples), I cannot configure the meter to do this as it requires more samples than I can set samples:count to.  Nor can I trigger each sample reliably because the triggers from the control computer would have too much jitter.  It would be possible to do with a function generator set to 100 Hz connected to the trigger input, but this should not be necessary as the meter is perfectly capable of timing its own samples with trigger:delay.  Also, if I set the unit to take samples in blocks of some size, say 10,000 samples, then every 10,000 samples there will be a 'jump' in the timebase when the unit needs to be re-triggered for the next block, again due to the jitter from the control computer.  See what I am getting at here? 

The ideal solution would be to set samples:count to infinity.  But none of the meters allow this.  So, what is the workaround?  How do you capture very long records with a reasonable sample rate (>> 1 Sa/s) with a jitter-free timebase?

[Sparky]

However, if I want to take 1000 measurements per second for two weeks, I cannot configure the meter to do this as it requires more samples than I can set samples:count to.  Nor can I trigger each sample reliably.  It would be possible to do with a function generator set to 100 Hz connected to the trigger input, but this should not be necessary.  Also, if I set the unit to take samples in blocks of some size, say 10,000 samples, then every 10,000 samples there will be a 'jump' in the timebase when the unit needs to be re-triggered for the next block.  My question is: how do you do this without an external trigger source?

Sorry for side-tracking your question; you stated the issue clearly enough in the beginning but I hadn't got the subtlety of the matter. 

Your question is a good one, but to what extend could Agilent (or any manufacturer) reasonably provide a mechanism to do this?  To illustrate with an even more extreme example, what if you wanted to acquire 1k readings per second for the next 20 years, without an external trigger.

How would you design for it?  Can you describe what kinds of settings or parameters would be needed?  Whatever your requirements, it may not satisfy the next guy.

I can't think of a solution to what you want to achieve.

Edit: After reading your edits, my comments above are also a bit side tracked.... sorry!  In the end it is quite simple question, and your suggestion "samples:count to infinity" would seem a perfect solution (good thinking!).  The only need is a command to terminate the sampling when you wish to do so.  I wonder why no manufacturer has done that?

[alex.forencich]

However, if I want to take 1000 measurements per second for two weeks, I cannot configure the meter to do this as it requires more samples than I can set samples:count to.  Nor can I trigger each sample reliably.  It would be possible to do with a function generator set to 100 Hz connected to the trigger input, but this should not be necessary.  Also, if I set the unit to take samples in blocks of some size, say 10,000 samples, then every 10,000 samples there will be a 'jump' in the timebase when the unit needs to be re-triggered for the next block.  My question is: how do you do this without an external trigger source?

Sorry for side-tracking your question; you stated the issue clearly enough in the beginning but I hadn't got the subtlety of the matter. 

Your question is a good one, but to what extend could Agilent (or any manufacturer) reasonably provide a mechanism to do this?  To illustrate with an even more extreme example, what if you wanted to acquire 1k readings per second for the next 20 years, without an external trigger.

How would you design for it?  Can you describe what kinds of settings or parameters would be needed?  Whatever your requirements, it may not satisfy the next guy.

I can't think of a solution to what you want to achieve.

Edit: Your suggestion "samples:count to infinity" would seem practical (good thinking!), and then just some way to terminate it.  I wonder why no manufacturer has done that?

What really puzzles me is that you can set trigger:count to infinite, but not sample:count.  A remote interface clear will get the instrument out of the 'wait for trigger' state.  There is no technical reason that I know of that sample:count is restricted. 

The only reason I ask is because I am putting together a Python script for logging off of my 34401A as an example of how you can use Python IVI, and I want to make it as generic as possible, perhaps even just 'log at rate x until cancelled'.  Having a limit of 50,000 samples or whatever seems rather arbitrary, so I thought I would ask and see if there were any known solutions. 

[macboy]

...
However, if I want to take 100 measurements per second for two weeks  (120 million samples), I cannot configure the meter to do this as it requires more samples than I can set samples:count to.  Nor can I trigger each sample reliably because the triggers from the control computer would have too much jitter.  It would be possible to do with a function generator set to 100 Hz connected to the trigger input, but this should not be necessary as the meter is perfectly capable of timing its own samples with trigger:delay.  Also, if I set the unit to take samples in blocks of some size, say 10,000 samples, then every 10,000 samples there will be a 'jump' in the timebase when the unit needs to be re-triggered for the next block, again due to the jitter from the control computer.  See what I am getting at here? 

The ideal solution would be to set samples:count to infinity.  But none of the meters allow this.  So, what is the workaround?  How do you capture very long records with a reasonable sample rate (>> 1 Sa/s) with a jitter-free timebase?

Why assume that the  trigger needs to come from the PC? Can't you just set the measurement trigger to "immediate" (TRIGger:SOURce IMMediate)? As soon as one 10000-sample measurement is complete, it should start taking another.... am I dreaming? If I am, then accept my appoligies. I don't have a Agilent meter, I am a Keithley user.

[neslekkim]

I tried to use the IO trace thingy that comes with the NI software, but it seems like it is not logging everything, if I run commands like IDN etc, it's logged, and it logs something when benchvue is trying to connect to my meter (which mostly always fail with an exception)
Isn't agilent's software using these drivers maybe?, going right to socket? (I got two meters listed when I added my meter in the VISA setup)

[KedasProbe]

Doesn't this code explain for you how to use it.... (earlier in this thread)
https://www.eevblog.com/forum/testgear/new-agilent-34461a-6-5-digit-bench-multimeter/msg265426/#msg265426

[TVman]

That is AWESOME!!! 

[alex.forencich]

...
However, if I want to take 100 measurements per second for two weeks  (120 million samples), I cannot configure the meter to do this as it requires more samples than I can set samples:count to.  Nor can I trigger each sample reliably because the triggers from the control computer would have too much jitter.  It would be possible to do with a function generator set to 100 Hz connected to the trigger input, but this should not be necessary as the meter is perfectly capable of timing its own samples with trigger:delay.  Also, if I set the unit to take samples in blocks of some size, say 10,000 samples, then every 10,000 samples there will be a 'jump' in the timebase when the unit needs to be re-triggered for the next block, again due to the jitter from the control computer.  See what I am getting at here? 

The ideal solution would be to set samples:count to infinity.  But none of the meters allow this.  So, what is the workaround?  How do you capture very long records with a reasonable sample rate (>> 1 Sa/s) with a jitter-free timebase?

Why assume that the  trigger needs to come from the PC? Can't you just set the measurement trigger to "immediate" (TRIGger:SOURce IMMediate)? As soon as one 10000-sample measurement is complete, it should start taking another.... am I dreaming? If I am, then accept my appoligies. I don't have a Agilent meter, I am a Keithley user.

Good point.  This looks like it should work.  Not sure how I missed that before.  However: after some poking around on my 34401A meter, it seems that it is not possible to use this mode for arbitrary length captures.  It seems that the 34401A firmware does not allow reading out measurements while in the wait-for-trigger state.  The 'fetch' call can only return the entire memory content of up to 512 samples after the acquisition is complete, and all of the samples to collect must fit into this memory.  Also, the meter will not enter the wait-for-trigger state if the settings can capture more than 512 data points, failing with an 'insufficient memory' error. 

Why would this meter allow a selection of 50,000 samples or 50,000 or infinite triggers even though it will fail with an insufficient memory error if the product of these is greater than 512 with any trigger source?  Is it even possible to use the infinite trigger count mode on the 34401A?

[KedasProbe]

It is documented in the user guide.
My DM3068 only has the fastest one 0.006 on a higher speed but that's logical since you want to give the same max speed of 10000hz  for 50hz and 60hz users.

[KedasProbe]

Maybe it's easier if you just set the integration time instead of PLC ratio.

[KedasProbe]

Are you sure?: (from manual)

Aperture mode. Aperture is the period, measured in seconds, during which
the multimeter’s analog–to–digital (A/D) converter samples the input signal
for a measurement. A longer aperture yields better resolution; a shorter
aperture provides for faster measurements. This mode allows the user to set a
specific integration time, not based on power–line frequency. Values range
from 100 µs to 1 second for the 34410A, and from 20 µs to 1 second for the
34411A/L4411A.

[dp]

Hi,

There is something I don't understand about this DMM: why is it rated 6.5 digit? With ranges of 0.1 - 1 - 10 - 100  there is no way it can provide that "half" digit, it can display only 6 digits, no matter what value it displays. To be 6.5 digit the ranges should be 0.2 - 2 - 20 - 200, so that you get 7 digits when reading values between 1 and 2 (on the 2 range) and 6 digits for lower values (as in the case of, say, Rigol DM3068).

What am I missing?

[HKJ]

why is it rated 6.5 digit? With ranges of 0.1 - 1 - 10 - 100  there is no way it can provide that "half" digit, it can display only 6 digits

That is fairly common for high end DMM, the 6½ digit only means that it can show slightly above 6 digit, i.e. 1200000 is enough.
Anyway, the actual precision is not high enough that it really matters.