Author Topic: GPIB readout time of 3458A DVM  (Read 2587 times)

0 Members and 1 Guest are viewing this topic.

Offline imisaacTopic starter

  • Regular Contributor
  • *
  • Posts: 51
  • Country: de
GPIB readout time of 3458A DVM
« on: October 23, 2018, 12:25:19 pm »
I was reading the 3458A voltage via a GPIB-to-USB interface in a Labview program. The data format was set to SREAL and the auto zero function was ON. In each loop, I took only 1 reading from the DVM. It turned out that the loop time needed to take a single reading from the DVM depended on the NPLC cycle that was used to average the reading. The dependence plot is attached.

The plot shows that the minimum loop time was 20 ms regardless how few of the NPLC cycle used. This implied that the maximum sampling rate was 50 Hz.

Anyone knows how to improve the sampling rate further?
 

Offline bson

  • Supporter
  • ****
  • Posts: 2497
  • Country: us
Re: GPIB readout time of 3458A DVM
« Reply #1 on: October 23, 2018, 03:22:01 pm »
I'm not directly familiar with the 3458A, but manual triggering may be limited to an integral PLC.  Things like SCPI ...:READ? will manually trigger, then wait for a sample, so if you're using it in a loop your trigger rate will be PLC.  In this case the NPLC setting may only affect the sample aperture.  Look into automated time based triggers and then wait for a value without triggering (I forget the command sequence off hand).  More modern instruments like the 3446x series can also make time based samples of a given aperture into a buffer, and you can drain the buffer in whatever way is convenient - in a loop that regularly fetches whatever is available, or just fetch it all at the end if it has enough memory.  Not sure what the 3458A era instruments offer in this regard, but I think the 3458A is modern enough to likely have similar functionality.
 

Offline macboy

  • Super Contributor
  • ***
  • Posts: 2309
  • Country: ca
Re: GPIB readout time of 3458A DVM
« Reply #2 on: October 23, 2018, 04:12:42 pm »
I believe I've read that the 3458A can deliver 100000 (one hundred thousand) samples per second at 4.5 digits over GPIB. I don't know what settings or commands are used for that, but you can definitely do better than 50 Hz.

If you can only get 50 Hz, you probably have line sync turned on. This arms the trigger exactly once per line cycle (probably at a zero crossing) in order to help remove the effect of AC line interference. Since the trigger must be armed before it can be fired, the maximum sample rate is then limited to the line frequency of 50 Hz. Unlike simple DMMs, a complex system multimeter like this doesn't take readings continuously at the maximum rate unless you specifically configure it to do that.

To get the maximum rate from the instrument, you definitely want to avoid having to repeatedly tell it to take a reading, or to ask it for the most recent reading. Instead, you want to configure it to read continuously at the rate you want (with the trigger settings you want), use binary format (not ASCII), then set up the GPIB host to read continuously from the instrument. When configured correctly, the instrument should sent data samples over the bus as they become ready, for as long as it is addressed to talk. Certainly, it should be a dedicated GPIB bus with no other devices which might trigger an interrupt (GPIB SRQ).  You might need to get into lower level GPIB programming for this, as higher level APIs will usually hide things like sending "talk" and "untalk" commands to the devices.
 

Offline Tony_G

  • Frequent Contributor
  • **
  • Posts: 967
  • Country: us
  • Checkout my old test gear channel (link in sig)
    • TGSoapbox
Re: GPIB readout time of 3458A DVM
« Reply #3 on: October 23, 2018, 06:12:54 pm »
There are a number of examples for this in the User Manual - pg 156 onwards.

In fact pg 163 talks specifically about doing this across GPIB.

Worth giving it a read (the code samples are in HPBasic but you can use the functions in any VISA app).

TonyG

Offline imisaacTopic starter

  • Regular Contributor
  • *
  • Posts: 51
  • Country: de
Re: GPIB readout time of 3458A DVM
« Reply #4 on: October 25, 2018, 01:16:05 pm »
Thanks for the suggestions!

It may be true that the sampling rate can be increased further if the DVM digitises the signal quickly (e.g. 100 kHz) and save a bunch of data points in the buffer waiting to be retrieved. However, this only works if the buffer size is large enough to accommodate the measurement data. If the measurement data exceeds the capacity of the internal buffer size, then one has to:

(a) send another retrieving command to the DVM to retrieve another bunch of data and/or
(b) use a smaller sampling rate such that the whole measurement can be fitted into a single buffer size.

Neither scenario is ideal for me. If I use point (a) solution, then the time interval between the subsequent bunch of data is undefined. If I use point (b) solution, then I  can not carry out a long measurement at high sampling rate. Therefore, I am stuck with the situation I am in now. I rely on the PC to define the sampling interval for me, instead of the DVM.

The 50 Hz sampling rate limitation may have originated from:
(a) the DVM/PC communication protocol (GPIB-USB in my case),
(b) the programming language (Labview in my case),
(c) the DVM internal triggering rate (as macboy already mentioned).

It is still unclear which is the definite bottleneck at the moment. I attach a screenshot of my simple Labview program to facilitate discussion. My ultimate goal is to continuously sample a DC voltage with a well defined sampling interval for a long time (e.g. weeks)……
 

Offline Tony_G

  • Frequent Contributor
  • **
  • Posts: 967
  • Country: us
  • Checkout my old test gear channel (link in sig)
    • TGSoapbox
Re: GPIB readout time of 3458A DVM
« Reply #5 on: October 25, 2018, 03:45:03 pm »
Sorry I don't use LabVIEW so I can't comment on that but you might be running into this (from pg 108)

Quote
If the bus/controller cannot transfer readings at >200k bytes
per second, the reading rate will be slower.This is because, in the
high-speed mode, the multimeter waits until each reading is removed from
its output buffer before placing the next reading in the output buffer.

Try writing a simple C# VISA or PyVisa app that issues the command from that sample program and see what the reading rate is.

TonyG

Offline imisaacTopic starter

  • Regular Contributor
  • *
  • Posts: 51
  • Country: de
Re: GPIB readout time of 3458A DVM
« Reply #6 on: April 14, 2019, 10:27:18 am »
Here is a follow up on this old thread. I got a temporary solution to work so far and produced some intrinsic noise spectra of 3458. The following is what I did. I switched to the Matlab platform to interface with the 3458 to use a traditional text based programming. In principle, any other programming language should work just as well.

Assuming that the communication is established in the "dmm" object, then the integration time of each sample can be set by the "fprintf(dmm,sprintf('aper %g',tint))", where "tint" is the user defined integration time.

The sampling interval "dt", which should be slightly longer than the integration time, was set by "fprintf(dmm,sprintf('sweep %g %d',dt,num))", where "num" is the number of samples to be measured. I have tried "num"=4855 without a problem.

The data in the 3458 buffer can be retrieved by "[data] = fread(dmm,num,'long')".

In the post analysis, it is the integration time "tint" that should be assigned to the time between each samples regardless of what "dt" is used.

Attached is the intrinsic voltage noises of 3458 at 100 mV, 1 V, and 10 V ranges. With the 17 nV/√Hz best noise figure, it appears that 3458 is a decent DAQ device as well.

Thanks all for the input.


 

Offline pwlps

  • Frequent Contributor
  • **
  • Posts: 372
  • Country: fr
Re: GPIB readout time of 3458A DVM
« Reply #7 on: April 14, 2019, 11:27:23 am »
Here is a follow up on this old thread. I got a temporary solution to work so far and produced some intrinsic noise spectra of 3458. The following is what I did. I switched to the Matlab platform to interface with the 3458 to use a traditional text based programming. In principle, any other programming language should work just as well.
[...]

Interesting, does it mean that it was Labview that created the bottleneck?

I  have programmed a lot with GPIB in other languages and I'm not very familiar with Labview but know many people using Labview telling that it is slow.

BTW. You can also have a look on the Ian's software for 3458A:
https://www.eevblog.com/forum/metrology/3458a-logging-via-windows-app-revisited/

By default it uses polling and therefore is limited in speed but  in my last post I show how to activate SRQ to get full speed (if you only have one device on the bus then polling can be disabled too without introducing any latency).
 

Offline imisaacTopic starter

  • Regular Contributor
  • *
  • Posts: 51
  • Country: de
Re: GPIB readout time of 3458A DVM
« Reply #8 on: April 14, 2019, 12:47:33 pm »
Quote
Interesting, does it mean that it was Labview that created the bottleneck?

I  have programmed a lot with GPIB in other languages and I'm not very familiar with Labview but know many people using Labview telling that it is slow.

BTW. You can also have a look on the Ian's software for 3458A:
https://www.eevblog.com/forum/metrology/3458a-logging-via-windows-app-revisited/

By default it uses polling and therefore is limited in speed but  in my last post I show how to activate SRQ to get full speed (if you only have one device on the bus then polling can be disabled too without introducing any latency).

In my old Labview code, I did not utilize the buffer on the 3458. It was intended to control the sampling interval via the Labview software loop time. It turned out that ~20 ms is the minimum loop time needed in this software based approach. It may very well be limited by the bus speed as suspected.

Now I started using the buffer on 3458 for a faster sampling rate with a comparable integration time for each sample. The implementation was switched to Matlab for the convenience of post-processing. I am sure Labview can acquire the data from 3458 just as well.

Thanks for the Win program post. I typically use MacOS, and to get IanJ's program working on a mac may require some re-compilation from its source code.
 
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf