Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Agilent 3458A slow


@averagejoe wrote:

 I thought getting the agilent would be quicker than our solartron multimeters but its not, or i cant figure out to make it any quicker.



Why?  The time required to take a measurement is dependant of the method used to obtain the measurement.  Most DMM's use the exact same methods and are calibrated to the exact same standards for any given accuracy.  As suggested, you can trade off accuracy for speed (to a limited extent) but the base methodology remains the same.  For True RMS ACV measurements The method employed averages the instantaneuos voltage over a period of time (aperature) longer time = greater accuracy with an erroneous answer if the aperature is less than 1 cycle of the waveform. 

 

The time to configure, trigger and return a measurement can vary between instruents and communications buses but, is usually small compared to the actual measurement time.  Although for very high throughput automated systems it can be a significant factor when a difference of 100mSec * 6000 readings per test is a minute per part!


"Should be" isn't "Is" -Jay
0 Kudos
Message 11 of 12
(1,081 Views)

ok thanks for the replys, i got it working it now does completes the vi in 400ms which is quiet good, reason was is because i had auto range on, turned that off and it was hunky dorey.Smiley Happy

 

next problem is because im using the agilent 3458a with the 34970a scanner the scanner can have 20 channels and i choose the channel take a reading and so on. i got that all working but the problem i ran into was the reading from front terminal that were connected directly to the sorce where differnt compared to rear terminal connected to the scanner to the source. i had to put a delay of 700ms in to be able to get the reading both the same. Im guessing this is because the scanner is using a board with lots of relay as these relays switch it most likely causes a small spike and my reading was at the time of the spike giving a higher reading. So putting that delay in, is now giving the correct value.

 

Now just got to figure how to make the vi 700ms quicker Smiley Sad

0 Kudos
Message 12 of 12
(1,053 Views)