¿ªÔÆÌåÓý

  1. HP-Agilent-Keysight-Equipment
  2. Topics

HP3456A GPIB problem

 

Working on writing a communications library to control my HP3456A DMMs. One of the meters that I have responds to instructions to read and write just fine. The other meter will read the correct value from the meter and responds to serial polls correctly, but will not accept commands like setting the mode or range. Looking at the GPIB bus with a logic analyzer, it accepts the address with sane looking handshaking, but the first byte of the command string never gets an NDAC response. The transaction then times out. The meter does not hang after this or stop updating the display and reading the keypad. The meters both pass the self test. I looked through the service manual and did not see any reference to the self test doing a checksum on the EPROMs. I am using the same code to talk to both meters. Initially, I was expecting a dead bus transceiver chip, but all of the handshaking signals operate correctly in other parts of the transactions. Now, I am thinking that it is either the GPIB controller chip (MC68488) or possibly an EPROM problem. Has anybody run into this or have any thoughts on this? Thanks, BobH
 

On 2025-04-15 8:22 PM, BobH via groups.io wrote:
Looking at the GPIB bus with a logic analyzer, it accepts the address with sane looking handshaking, but the first byte of the command string never gets an NDAC response. The transaction then times out.
Any chance that one might be set as a Talker only? I'm not familiar with that specific meter, but sometimes there's a setting, either a DIP switch or something from the front panel, that makes it talker only.

Steve Hendrix
 

Thanks, I checked that and just for grins, I flipped the DIP switch to select it, and in the Talker Only position neither meter accepts commands.
?
 

hmmm, in talker only, I think the meter takes a measurement as commanded, and puts it out on the bus.? I don't think it would accept commands in that mode.? Talker only mode is designed to have the meter drive a printer (or the like) without the benefit of a controller.

You might try cleaning the dip switches, though.

Does flipping the switch change any front panel lights and should it?

Harvey

On 4/15/2025 10:10 PM, BobH via groups.io wrote:
Thanks, I checked that and just for grins, I flipped the DIP switch to select it, and in the Talker Only position neither meter accepts commands.
 

There is a front panel LED for Talk and when I flip the switch to Talk Only, the LED comes on. In Talk Only mode, the meter does not even respond to attempts to talk to it, I get an immediate No Listener error on the controller.
In normal mode, the front panel Listen LED lights up and stays lit after the command times out.
BobH
 

Then the switch is working.? In Talk only mode, the meter *will not* respond to a controller.

The configuration of the meter in talk only mode is the meter directly wired to a printer (which is in listen only mode).? No controller.

In normal system mode, no instrument should be in either talk only or listen only mode.? The controller would select the meter as a talker, some other device as a listener, and then release control to allow the instruments to work.

Remember that the HPIB bus is an addressed system.? Talk only and listen only overrides the addressing function.

No listener error is exactly what you should see when you try to address using a controller, a device that is set to talk only.

If the command times out, perhaps it is not properly terminated?

Harvey

On 4/16/2025 10:38 AM, BobH via groups.io wrote:
There is a front panel LED for Talk and when I flip the switch to Talk Only, the LED comes on. In Talk Only mode, the meter does not even respond to attempts to talk to it, I get an immediate No Listener error on the controller.
In normal mode, the front panel Listen LED lights up and stays lit after the command times out.
BobH
 

Just a thought...
?
Perhaps the two meters are running different versions of firmware and one is being sensitive to upper/lower case?? My 3456A only accepts upper case.
?
-mark
?
 

The docs show the commands in upper case, so that is what I have been using for both meters.
?
BobH
 

The command is hanging at the first byte of the actual command. The meter never issues the NDAC pulse for it. The meter does issue the NDAC pulses for the first 3 bytes transferred, so I know the bus buffer for it is alive.
There are 3 bytes transferred at the beginning of the transaction, with the last of those 3 containing the target address. Do you know what the first 2 bytes are? The IEEE 1978 spec is not the most readable document...
Thanks,
BobH
 

Besides NDAC, is DAV and NRFD behaving properly?? What is the value of ATN at the time the other two bytes are transferred?? And what are the values of those two bytes?
?
If ATN is asserted, the bytes are interface control messages, and you can look up the meaning in the "Remote Message Coding" table.? I don't have a copy of the 1978 spec, but in the 2003 spec it is Table 44.
?
Besides the hang, do you see any differences on the bus between the two meters leading up to the hang?
?
You might find this document a little more digestible. although you still need the spec for the finer details:
?
?
?
When debugging weird GPIB issues, it's usually worthwhile to monitor all the bus signals.
?
-mark
?
?
On Wed, Apr 16, 2025 at 01:50 PM, BobH wrote:

The command is hanging at the first byte of the actual command. The meter never issues the NDAC pulse for it. The meter does issue the NDAC pulses for the first 3 bytes transferred, so I know the bus buffer for it is alive.
There are 3 bytes transferred at the beginning of the transaction, with the last of those 3 containing the target address. Do you know what the first 2 bytes are? The IEEE 1978 spec is not the most readable document...
Thanks,
BobH
?
 

On the failing meter, DAV and NRFD are behaving in a similar manner to the working meter.
ATN is asserted (close to 0V) while those three bytes are transferring. It is de-asserted in the problem area.
The three bytes are 0xBF 0xC0 0xCB? and the gpib address is 20 (base 10).
Data, DAV, and NRFD look about the same as the working meter, but the data is changing with no visible NDAC.
I think I need to speed the sampling up and take another look.
?
Thanks,
BobH
 

The three bytes listed 0xBF 0xC0 and 0xCB need to be inverted before decoding
?
 

On 2025-04-16 1:50 PM, BobH via groups.io wrote:
There are 3 bytes transferred at the beginning of the transaction, with the last of those 3 containing the target address. Do you know what the first 2 bytes are? The IEEE 1978 spec is not the most readable document...
As a typical IEEE-488 Controller, my KISS-488 would start with UNL (Unlisten), UNT (Untalk), then a LAG (Listen Address Group, with the listerner's address in the 5 LSBs), and a TAG (Talk Address Group, similarly, with the talker's address in the 5 LSBs). If your instrument is set as a Talker only, it would not acknowledge the Listener address.

Steve Hendrix
 

Hi BobH, for my sins, I have worked with HPIB since it started circa 1975 when I was based in HP Loveland,Colorado. In those days we did not have the High Level
User Interface to HPIB, so we had to do it all at "Level 1".
This was a good learning?experience.
To answer one of your questions "What are the first three bytes" these will be the address info with ATN set (Command Mode).
The first two characters are "Unlisten" and? "Untalk" other wise?shown as "?U". The third byte will be the device being addressed (Listen or Talk address).
If there are more than one Listeners then there would be more than 3 bytes in the Command Mode. After the end of the Command mode sequence, ATN would go false
and Bus would be in "Data" mode.

I have attached a Document "A Tutorial description of HPIB" which, I believe, describes the Operation?of the Bus very well, including timing.
I hope you will find this useful..

I am not privy to earlier Emails in this chain, so I don't know your configuration.
However, simplistically, the problem is with one of the following elements:
1 HPIB Controller, including?programming
'2 Bad HPIB Cabling
3 The HP3456A Multimeter.

While writing this I have just observed in other Email that you have a? "Working" meter..
That kinda takes us to end of story . You got a Bad HP 3456A. since it controls NDAC.

I was going to suggest changing your HPIB Cable. There are lots of flaky HPIB Cables out there including ones with Crosstalk problems.
I don't know the exact card config for a HP3456A' buf if that is what you got working. then I would want?to swap the HPIB Card from good one in to bad one
and see if problem solved.. You can, of course, troublesohoot?at?component Level with which I cannot be of much help.

Hope this is helpful
Good Luck
Bill Lauchlan


On Wed, Apr 16, 2025 at 4:10?PM Mark Litwack via <mlitwack=[email protected]> wrote:
Besides NDAC, is DAV and NRFD behaving properly?? What is the value of ATN at the time the other two bytes are transferred?? And what are the values of those two bytes?
?
If ATN is asserted, the bytes are interface control messages, and you can look up the meaning in the "Remote Message Coding" table.? I don't have a copy of the 1978 spec, but in the 2003 spec it is Table 44.
?
Besides the hang, do you see any differences on the bus between the two meters leading up to the hang?
?
You might find this document a little more digestible. although you still need the spec for the finer details:
?
?
?
When debugging weird GPIB issues, it's usually worthwhile to monitor all the bus signals.
?
-mark
?
?
On Wed, Apr 16, 2025 at 01:50 PM, BobH wrote:
The command is hanging at the first byte of the actual command. The meter never issues the NDAC pulse for it. The meter does issue the NDAC pulses for the first 3 bytes transferred, so I know the bus buffer for it is alive.
There are 3 bytes transferred at the beginning of the transaction, with the last of those 3 containing the target address. Do you know what the first 2 bytes are? The IEEE 1978 spec is not the most readable document...
Thanks,
BobH
?
 


Ignore previous - No attachment - sorry


Hi BobH, for my sins, I have worked with HPIB since it started circa 1975 when I was based in HP Loveland,Colorado. In those days we did not have the High Level
User Interface to HPIB, so we had to do it all at "Level 1".
This was a good learning?experience.
To answer one of your questions "What are the first three bytes" these will be the address info with ATN set (Command Mode).
The first two characters are "Unlisten" and? "Untalk" other wise?shown as "?U". The third byte will be the device being addressed (Listen or Talk address).
If there are more than one Listeners then there would be more than 3 bytes in the Command Mode. After the end of the Command mode sequence, ATN would go false
and Bus would be in "Data" mode.

I have attached a Document "A Tutorial description of HPIB" which, I believe, describes the Operation?of the Bus very well, including timing.
I hope you will find this useful..

I am not privy to earlier Emails in this chain, so I don't know your configuration.
However, simplistically, the problem is with one of the following elements:
1 HPIB Controller, including?programming
'2 Bad HPIB Cabling
3 The HP3456A Multimeter.

While writing this I have just observed in other Email that you have a? "Working" meter..
That kinda takes us to end of story . You got a Bad HP 3456A. since it controls NDAC.

I was going to suggest changing your HPIB Cable. There are lots of flaky HPIB Cables out there including ones with Crosstalk problems.
I don't know the exact card config for a HP3456A' buf if that is what you got working. then I would want?to swap the HPIB Card from good one in to bad one
and see if problem solved.. You can, of course, troublesohoot?at?component Level with which I cannot be of much help.

Hope this is helpful
Good Luck
Bill Lauchlan


On Wed, Apr 16, 2025 at 8:33?PM BobH via <wanderingmetalhead=[email protected]> wrote:
On the failing meter, DAV and NRFD are behaving in a similar manner to the working meter.
ATN is asserted (close to 0V) while those three bytes are transferring. It is de-asserted in the problem area.
The three bytes are 0xBF 0xC0 0xCB? and the gpib address is 20 (base 10).
Data, DAV, and NRFD look about the same as the working meter, but the data is changing with no visible NDAC.
I think I need to speed the sampling up and take another look.
?
Thanks,
BobH

HP Tutorial description of the Hewlett-Packard interface bus.pdf
HP Tutorial description of the Hewlett-Packard interface bus.pdf

 

On Tue, Apr 15, 2025 at 05:22 PM, BobH wrote:
Working on writing a communications library to control my HP3456A DMMs. One of the meters that I have responds to instructions to read and write just fine. The other meter will read the correct value from the meter and responds to serial polls correctly, but will not accept commands like setting the mode or range. Looking at the GPIB bus with a logic analyzer, it accepts the address with sane looking handshaking, but the first byte of the command string never gets an NDAC response. The transaction then times out. The meter does not hang after this or stop updating the display and reading the keypad. The meters both pass the self test. I looked through the service manual and did not see any reference to the self test doing a checksum on the EPROMs. I am using the same code to talk to both meters. Initially, I was expecting a dead bus transceiver chip, but all of the handshaking signals operate correctly in other parts of the transactions. Now, I am thinking that it is either the GPIB controller chip (MC68488) or possibly an EPROM problem. Has anybody run into this or have any thoughts on this? Thanks, BobH
=====
Hi Bob,
If I understand it correctly faulty device returns values but does not allow you to program ranges etc, so its GPIB/HPIB is not completely dead. I see that you already tried the "talk only" DIP switch but perhaps it is dirty and not registering properly. If you measure with a DVM, does the DIP switch contact go high/low with switch position?
?
Other interesting line is the REN line (remote enable). I don't know if it would cause the issue you are seeing but tracing its connectivity would eliminate one possibility.
Ozan
?
?
 

Thanks for the help sorting out the address information and the HP document. I am driving the GPIB with an NI USB dongle. I have tried it directly connected to the meter and with a cable. Both configurations behave the same, so I believe that the connection is good. Also, the good meter works fine with the cable.
?
The bus driver chips and the bus controller chip are out of production, so swapping them is going to be problematic. Swapping the board from the good meter to the bad one would at least narrow the problem down. I REALLY don't want to wind up with 2 non-functional meters though...
?
Per Ozan's comment, the REN signal has not changed state in any of the traces I have observed on either the good or the bad meter. it is sitting at 0V. I looked at the bus side and the logic side of the driver and the two are consistent.
?
Thanks again everybody!
BobH
 

Be sure to check the HPIB/GPIB mounted connector on the back of the troublesome HP3456, use a magnifier to look closely.? I have seen HPIB/GPIB connectors that don't allow all the control/data lines to connect due to either contamination on the contacts or physical damage preventing electrical connection (i.e. bent, broken or mangled contacts) or foreign conductive material shorting contacts together (i.e. steel wool or wire strands).?

 

This morning, I swapped the 03 board from the good meter into the bad meter. The bad meter GPIB worked correctly, receiving commands and sending measured values out. I replaced the good board into the original meter and it still works. I put the bad board back into the bad meter, and low and behold, the GPIB works on the bad meter now.
?
One of the first things that I did when I found a problem with that meter was to wiggle all the connectors on that board. The process of swapping the boards requires a lot more flexing and force than I like to put on boards. The problem may be a cracked trace or some such mechanical problem, or it is possible that the problem was just oxidized pins with very low currents. While I had the PCB out, I looked it over carefully and did not see any dubious looking solder joints or scratches on the board. I will be curious to see if the meter continues working now,
?
If nothing else, I learned a lot more about what is going on in the GPIB cable, and I have 2 working meters for the efforts.
?
Thanks everybody who pitched in with suggestions,
?
BobH
 

Hi BobH,
?
I realize your repair is complete on the 3456A in this thread, or at least resolved for the time being. ?I wanted to respond to the meaning of the three bytes that were sent from the controller to the 3456A while ATN was asserted. ?You replied they were 0xBF, 0xC0, 0xCB.
?
The meaning of these bytes are:
?
? 0xBF - MTA 0 (My Talk Address)
? 0xC0 - UNL (Unlisten)
? 0xCB - MLA 20 (My Listen Address)
?
The controller identifies itself as the talker at address 0, then tells all devices not to listen, and then sets only the 3456A at address 20 to listen for further data bytes. ?So this is correctly setting up the transfer, and the problem with the 3456A GPIB interface was at least not visible in this phase of the exchange.
?
FYI if useful for future troubleshooting (and sorry for the delayed response),
?
-mark
?

1 - 20 of 20