34401a serial interface problems?

[ftransform]

So I am trying to interface my 34401A with a PC and things are just not working. The intuilink software does not detect the meter and attempting direct serial communication via ASCII has been a fail. I have matched the parity, stop bits, and baud rate on meter and computer. I made sure the meter has maintained the same parity/baudrate/etc settings upon reboots. Whenever I try to send a ASCII command to the meter (such as SYSTem:REMote) using a terminal program the meter beeps and displays error. I am using the serial header on my mother board, and this serial port has worked before to receive communications from a MCU.

Does anyone know if the RI (ring indicator) pin on the RS232 cable is used by the meter? The Null model cable is of the same type as is shown in the manual, but pin 9 is not connected. I have performed a continuity test on my null cable in order to make sure that it matches up with the cable in the datasheet.

I am not sure how to trouble shoot this. I would appreciate any help.

I have tried every flow control setting available in device manager and the intuilink software does not detect the meter.

[benemorius]

I don't know if it's the cause of your problems, but I had a hell of a time getting one to work until I got my \r and \n characters straightened out. I forget what exactly I was sending it and what it expects, but it will beep and error unless you give it exactly the newline sequence it wants, which is completely and utterly stupid and anyone who writes firmware that way needs to be shot.

Eh... sorry... I'm still pissed about it.

Maybe it's not what's wrong in your case if your software isn't working either, but I wouldn't be surprised if it's the reason you can't get direct ascii commands to go through.

[grenert]

I have a very similar problem with different equipment (HP and Fluke).  I was never able to sort it out, and in the end I concluded that the most efficient solution was to purchase USB-serial adapter cables.  They worked immediately.  Make sure you buy ones made by FTDI, or that use FTDI chips.  Others may be flakey, based on what I've heard.

Regarding the serial header on the motherboard, my suspicion is that a serial port is such low importance today that mobo makers don't bother to implement them properly.

[ftransform]

its ok benemorius whoever implemented this needs to be hung drawn and quartered.   


do you remember the proper sequence of new line commands? I will try a PCI to serial card..

[mikes]

Docs say <new line> or <carriage return><new line>. I assume they mean <line feed> where they write <new line>, since there is no ASCII new line character.

I'd first try sending those manually, instead of expecting your terminal program to send them when you press enter. Carriage return is control-m, line feed is control-j :

SYST:REM<ctrl-j>
*IDN?<ctrl-j>

If that doesn't work, try <ctrl-m><ctrl-j> after the commands.

[ftransform]

Docs say <new line> or <carriage return><new line>. I assume they mean <line feed> where they write <new line>, since there is no ASCII new line character.

I'd first try sending those manually, instead of expecting your terminal program to send them when you press enter. Carriage return is control-m, line feed is control-j :

SYST:REM<ctrl-j>
*IDN?<ctrl-j>

If that doesn't work, try <ctrl-m><ctrl-j> after the commands.

It replied with HEWLETT-PACKARD, 34401A, 0, and some numbers
you are a genius it did something other then beep at me tauntingly.

As for intuilink... who knows. at least I know the meters not broken now....

And I can write a program to categorize a DAC I think..

[ftransform]

ITS READING VOLTAGES
-7.44484340E+00

So, this claims to be a 6.5 digit meter, why is it spitting out like 10 digits?

where is the cutoff drawn? On the display it shows up to -07.44484

Is the extra 34 at the end valid?

[grenert]

ftransform, are you now using the PCI serial card or the built-in serial header on your motherboard?  Thanks.

[free_electron]

Depending on the firmware in the meter you will have that problem. Older firmware is very picky on termination characters. The reason is that gpib has a fixed termination sequence. They use the same command interpreter. And yes, hp got the sequence right. It is carriage return line feed , not the other way around ! Not the way loonix does it !
You first move the carriage ( the printer head ) all the way to the left , and then you scroll the paper to the next line.

In subsequent revisions they relaxed the stream coming from serial.

As for the number of digits returned. There are commands to set the number of digits and format the output. By default the machine returns all numbers yielded by its internal floating point calculation.

[ftransform]

ftransform, are you now using the PCI serial card or the built-in serial header on your motherboard?  Thanks.

I am using the PCI card external, but the meter beeped using both forms of communications, I have only verified that it accepts commands VIA the PCI card, but this is only because I know the proper input commands. I assume that this meter will also work with the on-board serial card. I might check later but I don't feel like climbing back into the pit right now to rearrange cables....

[ftransform]

Depending on the firmware in the meter you will have that problem. Older firmware is very picky on termination characters. The reason is that gpib has a fixed termination sequence. They use the same command interpreter. And yes, hp got the sequence right. It is carriage return line feed , not the other way around ! Not the way loonix does it !
You first move the carriage ( the printer head ) all the way to the left , and then you scroll the paper to the next line.

In subsequent revisions they relaxed the stream coming from serial.

As for the number of digits returned. There are commands to set the number of digits and format the output. By default the machine returns all numbers yielded by its internal floating point calculation.

Are any of the extra digits useful? Like how that 6.5 digit meter that dave has is a 7.5 digit meter through GPIB. I have read that the 34401A has this property too, but its unspecified:
http://www.febo.com/pipermail/volt-nuts/2009-August/000009.html

I have in mind, that the 3457A may also be used in 7 1/2 digit mode, but
could not find this in the manual.
The 34401A can deliver more digits than 6 1/2 via GPIB
Linearity is 2ppm, but the 3457A is not specified at all in this regard.

Any input on this free_electron? are any of those digits useful?

[quantumvolt]

The last four places are scientific exponent notation (as in 1.23E-04 Volt is 0.123 mV). About the value of the reading - I am not sure. I use them as 7-digit readings without the flickering of the last digit on the display. Have also read about another meter that gives one more digit to ports compared to display.

From the manual:

Output Data Format
< 80 ASCII character string
SD.DDDDDDDDESDD<nl>
SD.DDDDDDDDESDD,...,...,<nl>
SD.DDDDDDDDESDD<cr><nl>
SD.DDDDDDDDESDD,...,...,<cr><nl>
S Negative sign or positive sign
D Numeric digits
E Exponent
<nl> newline character
<cr> carriage return character

[free_electron]

The extra digits are not useful as they are below. The integration noise. The extra digits are simply there because of the floating point calc the machine does.

[quantumvolt]

The extra digits are not useful as they are below. The integration noise. The extra digits are simply there because of the floating point calc the machine does.

:


When measuring 10 Volt the meter shifts from classic (+1. 999 999) 6 1/2 digit mode to +09. 999 99 which is 6 digits. The last digit resolves 10 microV. If the real measured value is 10. 123 456 + external signal noise, the meter's display will probably flicker between 10. 123 45 and 10. 123 46. The integration noise should be the same or less than in the 2 V case. Hence an extra digit is needed and justified.

Any way you see it - if this situation occurs, the meter has a stable reading of 100 microVolt or 10 ppm. But in the first two cases in the beginning of the paragraph over, we readily accept 6 1/2 digit DMMs to convey information up to 0.5 ppm for 2 volt and 1 ppm for 10 Volt (let's say measuring the same source 2 times in a 5 seconds interval without touching the setup). Why do they make 6 1/2 digit meters if the last digit is lottery (no answer needed)?

Neither the electronics nor the measurement situation have changed. Using the first extra digit from the port readout improves the reading. It is at the very least justified by removing one unneeded  numerical rounding (due to display size) and maybe also founded in measurement accuracy hidden by the display (the 10 V 24h accuracy is minimum 15+4 ppm).

In my opinion, that is ....

[robrenz]

Take my input with a grain of salt but by using the maximum integration time or number of power line cycles and using digital filtering the extra resolution can be very useful. 

This is my 8846A (6.5 digit meter) with shorted inputs 100NPLC and digital filter on and using the 100mV range.  Thats 23 minutes of data and a total min max span of 187.9nV with 100pV resolution. Sure that still boils down to almost +or- 1 lsd (100nV on this range) so you are not getting any increase in accuracy with that 3 extra digits of resolution. I am told that is real hardware resolution at 100NPLC.


But seeing what is happening when graphed at the higher resolutionis quite informative. This is a test I did from another thread comparing the thermal emf of a heated continuous loop of copper wire compared to a twisted and soldered juntion.  Think what those charts would look like with 1000 times less resolution.

[ftransform]

also can't you decimate that reading like a ADC?

i have GPIB too, 1000 samples per second would be favorable to decimation...

[quantumvolt]

The extra digits are not useful as they are below. The integration noise. The extra digits are simply there because of the floating point calc the machine does.

This claim is imo totally unwarranted. Who says so? On what basis? May we get some documentation please ...

I connected a 5 V ref (voltagestandard.com) to the 34401A in 10 V DC 6 Digits Mode.

It is quite steady at 05.000,45 - some flickering to ....,44 and ....,46. The meter reads effectively 6 digits and the last digit resolves 10 microVolt.

I made a data logger from a RS232 cable, a level shift transistor, an Arduino and a Processing sketch. The graph in the video below plots whatever value falls within the last 100 microVolt span (i.e. 1000 lines of 0.1 microVolt on the 100 microvolt peak-to-peak screen). Example: 1.2345001 Volt gives a plot of 1,   1.2345099 gives a plot of 99 and 1.2345678 gives a plot of 678. This is a simple operation that can be done with correct numerical math arithmetic or as a string operation on the original RS232 string reading.

I measured the 5 Volt reference with and without a 10 Ohm resistor in series. The video clearly shows that the DMM reading shifts a few microVolts (5? +- noise) when the resistor is connected (the "square" form is from swithing in and out the resistor). With an input impedance of 10 megaOhm for the DMM this setup shows that Agilent 34401A has a resolution at around 1 ppm in serial RS232 mode. Whether it is accurate or not is irrelevant - the video shows it is fairly stable for 10 seconds or whatever - that is all the time I need to take two measurements for comparison with another reference.

And since this is an experiment anyone with the 34401A, a 10 Ohm resistor and a Data Logger with 1 microVolt resolution can reproduce, it shows that the quote over is totally unsubstantiated.

[KK]

Latest version of Keysight's Benchvue is compatible with the 34401a. The DMM module has logging and is freeware for 1 hour of continuous use per session beyond that payware.

http://www.keysight.com/en/pc-2472896/benchvue-software?cc=US&lc=eng

[3roomlab]

Latest version of Keysight's Benchvue is compatible with the 34401a. The DMM module has logging and is freeware for 1 hour of continuous use per session beyond that payware.

http://www.keysight.com/en/pc-2472896/benchvue-software?cc=US&lc=eng

am i right to say its just another crippled sw? btw have a read on these threads
1) https://www.eevblog.com/forum/testgear/dmm-adc-noise-comparison-testing-project/ --EZGPIB software mentioned in xdev.com (https://xdevs.com/article/dmm_noise/)
2) https://www.eevblog.com/forum/projects/is-this-a-real-ns-lm399-%28from-polida-ebay%29/  --> post 19, RS232 python code for keithley. sub out for agilent SCPI code (my current experimental code does xls file spanning = logging for months if needed)

edit : and this https://www.eevblog.com/forum/beginners/~~-exploring-scpi-thru-rs232-%28problemsolution%29/

am i the only 1 that did python- RS232 keithley logging? it seems nobody else said anything about it? or its too low tech?