开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育
  1. HP-Agilent-Keysight-Equipment
  2. Topics

Readings from 436A power meter using 82357B USB-GPIB?

 

I also have a HP436A and try to make the GPIB work. After search on several websites, I could not find any example, therefore, I spent two days and figured out this problem. Here is the right GPIB command sequence :

?

Interactive Control

Copyright 2022 National Instruments Corporation

All rights reserved.

?

Type 'help' for help or 'q' to quit.

?

GPIB0: ibdev

??? enter board index: 0

??? enter primary address: 13

??? enter secondary address: 0

??? enter timeout: 10

??? enter 'EOI on last byte' flag: 1

??? enter end-of-string mode/byte: 10

?

ud0: ibclr? <----------- use this to turn on remote LED, required.

[0100]?? ( cmpl )

?

ud0: ibwrt "9A+I"? <---- this means: set RF power unit to be W

[0100]?? ( cmpl )

count:? 4

?

ud0: ibrd 14????? <-----read 14 byte data as ASCII

[0100]?? ( cmpl )

count:? 14

50? 4c? 41? 20? 30? 39? 39? 30????????? P L A?? 0 9 9 0

45? 2d? 30? 39? 0d? 0a????????????????? E - 0 9 . .

?

Details about the "PLA" can be found on page 3-19, HP436A operating and service manual.

?

?

I use a NI GPIB-USB-HS adaptor, run on windows 10, with NI VISA (2022) installed.

With NI MAX scanning, I found the address=13 for HP436A.

With NI MAX interactive control, I tried above sequence.

When you implement above sequence with C or python, the timing is important. Between ibclr to ibwrt, it needs about 0.3s, between ibwrt and ibrd, it needs at least 1.2s? (1.2s is the worst case according to the manual).
Lin
 

Hello,

Addressing another device using interactive IO doesn't seem to release the 436. What I did find out though was that viRead - wich is what interactive IO actually does - gets 14 characters back, but it expected 1024... I guess I IO doesn't get an end of line from the 436 and decides it never returned enough characters... Reading the 436 manual, it's clearly stated that it returns exactly 14 characters for each read. So, a response is given, but asking in the wrong way gives an error, not due to the instrument, but due to the setup of I IO...
I found a couple of nice functions in the VISA? library - there is a way to deassert the REN line for example. I know now that it isn't needed.
Nevertheless, this exercise was good for learning a bit more about Keysight (Agilent/HP) Connection Expert, Interactive IO and, most importantly, how to get the communication working the the VISA library!

Regards,
? Staffan
 

开云体育

Try addressing another device?? (Even one that doesn’t exist...)

Dave B (G0WBX)

Re: Readings from 436A power meter using 82357B USB-GPIB?
From: Staffan
Date: Tue, 20 Nov 2018 10:26:07 PST

Hello,

Absolutely - just how to do this on the 82357B? Hopefully very simple, but seems not to be available on the interactive IO. Any hints would be very much appreciated!

Regards,
? Staffan 


-- 
Created on and sent from a Unix like PC running and using free and open source software.
::

 

Hello,

Indeed a point. Not having a second 436 around, I will try this one and see where it gets me for now, but if anyone would send me a 436 - I’d be happy to test :-)

Regards,
?Staffan


On Wednesday, November 21, 2018, Kuba Ober <kuba@...> wrote:
It’s not impossible that you have a stuck gate somewhere, and the operation you observe is not normal for the instrument. It’d be worth checking that against another 436A.

Cheers, Kuba

20 nov. 2018 kl. 12:05 skrev Staffan <testjarfalla63@...>:

Hello,

I can't argue against, but my only experience is that I _can_ set the instrument in the state I want (REN active) and can read the output data when I deactivate REN, but not otherwise. I have tried to follow section 3.
What I would really like is a description of how to communicate with this instrument using the 82357.

Regards,
? Staffan

 

开云体育

It’s not impossible that you have a stuck gate somewhere, and the operation you observe is not normal for the instrument. It’d be worth checking that against another 436A.

Cheers, Kuba

20 nov. 2018 kl. 12:05 skrev Staffan <testjarfalla63@...>:

Hello,

I can't argue against, but my only experience is that I _can_ set the instrument in the state I want (REN active) and can read the output data when I deactivate REN, but not otherwise. I have tried to follow section 3.
What I would really like is a description of how to communicate with this instrument using the 82357.

Regards,
? Staffan
_._,_._,_
 

Hello,

Final (?) findings.

Interactive IO in the Agilent Connection Expert seems not sufficient...
Running the code, accessing the VISA library immediately and _not_ using viScanf, but viRead seems to have done the trick. I can now talk to and _read_ (not scan?) from the 436A - Yippie!

Many thanks to all you people involved for suggestions, comments and taking the time to comment!

Regards,
? Staffan
 

Hello,

Absolutely - just how to do this on the 82357B? Hopefully very simple, but seems not to be available on the interactive IO. Any hints would be very much appreciated!

Regards,
? Staffan
 

Just get the controller to "un-talk/un-listen" the 436, or use the GPIB
low level "Go To Local" function.? It'll then un-freeze it's display.

Regards.

Dave B (G0WBX)

--
Created on and sent from a Unix like PC running and using free and open source software.
::
 

Hello,

I can't argue against, but my only experience is that I _can_ set the instrument in the state I want (REN active) and can read the output data when I deactivate REN, but not otherwise. I have tried to follow section 3.
What I would really like is a description of how to communicate with this instrument using the 82357.

Regards,
? Staffan
 

开云体育

REN should not be deactivated to take a reading. 436 must stay in Remote. I have sent you a 436A Operating and Service Manual. Read Section 3.

?

Bill Lauchlan

?

From: [email protected] [mailto:[email protected]] On Behalf Of Staffan
Sent: Tuesday, November 20, 2018 8:13 AM
To: [email protected]
Subject: Re: [HP-Agilent-Keysight-equipment] Readings from 436A power meter using 82357B USB-GPIB?

?

Hello,

?

Many thanks. I have been successful in all the steps you mention using the Arduino converter, but I need to activate REN for sending a command and then deactivate REN before reading.?

This is not possible (controlling REN) using 82357 - or is there a way? I’m fairly sure this is the issue with the 436 (REN).

?

Regards,

?Staffan

On Tuesday, November 20, 2018, Dave_G0WBX via Groups.Io <g8kbvdave=[email protected]> wrote:

A simple task...

But it is NOT IEE488.2 compliant, so will not respond to such things as
*IDN? etc.? (In fact, traffic like that can totally mess it up at times,
as can other automated tricks to attempt to catalogue "live" devices on
the bus..)

Modern GPIB systems will handle all the global un-listen, selected
device addressing and so on for you, making life much easier.? If you
create your own GPIB controller, you have to do all that yourself.

Make sure you know it's device address on the bus.? Ours is defaulted to
a primary address of '13' (decimal.)??? AFIK (oddly, I cant find the
detail in our manual!)? The address setting is a bank of switches
internally.??? If you need to "scan the bus" to find it, you may need to
manually reset the thing after you know it's address, as it's a simple
state machine in hard logic internally, and can get "upset" by command
data it cant understand.

Anyway, when you know it's bus address...?? And it's Talk Mode is set to
"Normal".

Send it the command '9A+I' (not the quotes!) with no trailing terminator
byte, with or without EOI asserted, it doesn’t care about that.? That
command instructs it to send back a reading scaled in Watts.? (Or '9D+I'
in which case It will scale in dB/dBm.)

Use Watt's initially, as a no input signal condition, will still result
in a valid reading!

Give it a little time to figure things out...

When you then ask the system to read back the resulting "measurement".

The 436A will send a 14 byte fixed format ASCII string to the
controller, ending in a CR/LF pair, so your GPIB system needs to be
configured to stop reading when it sees a LF byte (ASCII code 10, or
0x0A)? The 436A does not use the EOI line, so you MUST configure your
bus controller to recognise that LF byte to signify the end of it's
reply, or to stop reading after 14 bytes have been received.

The first byte (byte 0) is the status. ('P' = valid reading.? Anything
else is under/over range.)

Bytes 3 to 11 represent the measured value, in scientific format (Mantissa).

Byte 3 is a sign (ASCII space = +) or and ASCII -

Bytes 4..7 are the measured value, an implied decimal point is
immediately after byte 7.

Byte 8 is always an 'E'.

Byte 9 is always a - sign.

Bytes 10 .. 11 is the Exponent.

Bytes 12..13 are CR/LF

It's all ASCII characters, so no "funny" stuff.

The above comes from table 3-4 on page 3-25 of the operating and service
manual.

It's up to you to process that string to test for validity, and extract
the value.

It is highly recommended to get a copy of at operator/service manual.?
(I only have a dead tree version.)

Hope this helps.

Dave B (G0WBX)


--
Created on and sent from a Unix like PC running and using free and open source software.
::
 

Hello,

Many thanks. I have been successful in all the steps you mention using the Arduino converter, but I need to activate REN for sending a command and then deactivate REN before reading.?
This is not possible (controlling REN) using 82357 - or is there a way? I’m fairly sure this is the issue with the 436 (REN).

Regards,
?Staffan


On Tuesday, November 20, 2018, Dave_G0WBX via Groups.Io <g8kbvdave=[email protected]> wrote:
A simple task...

But it is NOT IEE488.2 compliant, so will not respond to such things as
*IDN? etc.? (In fact, traffic like that can totally mess it up at times,
as can other automated tricks to attempt to catalogue "live" devices on
the bus..)

Modern GPIB systems will handle all the global un-listen, selected
device addressing and so on for you, making life much easier.? If you
create your own GPIB controller, you have to do all that yourself.

Make sure you know it's device address on the bus.? Ours is defaulted to
a primary address of '13' (decimal.)??? AFIK (oddly, I cant find the
detail in our manual!)? The address setting is a bank of switches
internally.??? If you need to "scan the bus" to find it, you may need to
manually reset the thing after you know it's address, as it's a simple
state machine in hard logic internally, and can get "upset" by command
data it cant understand.

Anyway, when you know it's bus address...?? And it's Talk Mode is set to
"Normal".

Send it the command '9A+I' (not the quotes!) with no trailing terminator
byte, with or without EOI asserted, it doesn’t care about that.? That
command instructs it to send back a reading scaled in Watts.? (Or '9D+I'
in which case It will scale in dB/dBm.)

Use Watt's initially, as a no input signal condition, will still result
in a valid reading!

Give it a little time to figure things out...

When you then ask the system to read back the resulting "measurement".

The 436A will send a 14 byte fixed format ASCII string to the
controller, ending in a CR/LF pair, so your GPIB system needs to be
configured to stop reading when it sees a LF byte (ASCII code 10, or
0x0A)? The 436A does not use the EOI line, so you MUST configure your
bus controller to recognise that LF byte to signify the end of it's
reply, or to stop reading after 14 bytes have been received.

The first byte (byte 0) is the status. ('P' = valid reading.? Anything
else is under/over range.)

Bytes 3 to 11 represent the measured value, in scientific format (Mantissa).

Byte 3 is a sign (ASCII space = +) or and ASCII -

Bytes 4..7 are the measured value, an implied decimal point is
immediately after byte 7.

Byte 8 is always an 'E'.

Byte 9 is always a - sign.

Bytes 10 .. 11 is the Exponent.

Bytes 12..13 are CR/LF

It's all ASCII characters, so no "funny" stuff.

The above comes from table 3-4 on page 3-25 of the operating and service
manual.

It's up to you to process that string to test for validity, and extract
the value.

It is highly recommended to get a copy of at operator/service manual.?
(I only have a dead tree version.)

Hope this helps.

Dave B (G0WBX)


--
Created on and sent from a Unix like PC running and using free and open source software.
::
 

A simple task...

But it is NOT IEE488.2 compliant, so will not respond to such things as
*IDN? etc.? (In fact, traffic like that can totally mess it up at times,
as can other automated tricks to attempt to catalogue "live" devices on
the bus..)

Modern GPIB systems will handle all the global un-listen, selected
device addressing and so on for you, making life much easier.? If you
create your own GPIB controller, you have to do all that yourself.

Make sure you know it's device address on the bus.? Ours is defaulted to
a primary address of '13' (decimal.)??? AFIK (oddly, I cant find the
detail in our manual!)? The address setting is a bank of switches
internally.??? If you need to "scan the bus" to find it, you may need to
manually reset the thing after you know it's address, as it's a simple
state machine in hard logic internally, and can get "upset" by command
data it cant understand.

Anyway, when you know it's bus address...?? And it's Talk Mode is set to
"Normal".

Send it the command '9A+I' (not the quotes!) with no trailing terminator
byte, with or without EOI asserted, it doesn’t care about that.? That
command instructs it to send back a reading scaled in Watts.? (Or '9D+I'
in which case It will scale in dB/dBm.)

Use Watt's initially, as a no input signal condition, will still result
in a valid reading!

Give it a little time to figure things out...

When you then ask the system to read back the resulting "measurement".

The 436A will send a 14 byte fixed format ASCII string to the
controller, ending in a CR/LF pair, so your GPIB system needs to be
configured to stop reading when it sees a LF byte (ASCII code 10, or
0x0A)? The 436A does not use the EOI line, so you MUST configure your
bus controller to recognise that LF byte to signify the end of it's
reply, or to stop reading after 14 bytes have been received.

The first byte (byte 0) is the status. ('P' = valid reading.? Anything
else is under/over range.)

Bytes 3 to 11 represent the measured value, in scientific format (Mantissa).

Byte 3 is a sign (ASCII space = +) or and ASCII -

Bytes 4..7 are the measured value, an implied decimal point is
immediately after byte 7.

Byte 8 is always an 'E'.

Byte 9 is always a - sign.

Bytes 10 .. 11 is the Exponent.

Bytes 12..13 are CR/LF

It's all ASCII characters, so no "funny" stuff.

The above comes from table 3-4 on page 3-25 of the operating and service
manual.

It's up to you to process that string to test for validity, and extract
the value.

It is highly recommended to get a copy of at operator/service manual.?
(I only have a dead tree version.)

Hope this helps.

Dave B (G0WBX)


--
Created on and sent from a Unix like PC running and using free and open source software.
::
 

开云体育

Hi,

Red Herring alert!

FWIW I use Prologix interfaces (with the 'auto-read-after-write' feature disabled) and program using mostly AutoIT or EZGpib/Pascal s but I don't have to treat the 436 or 438 any different from any other HP or Tek instrument as far as reading data is concerned.

Adrian

On 11/20/2018 7:15 AM, Staffan wrote:

Hello,

Is this working with the 82357, it would be a great starting point. Although I just don’t understand why interactive IO doesn’t work.?

Has anyone experienced differences between interactive IO and using the libraries - I guess interactive IO just is an interface to the libs?

My best bet right now is that REN should be controlled (pulled inactive) for reading data from the 436. I just don’t know how to test this with the 82357/VISA libraries.?

Regards,
?Staffan




On Monday, November 19, 2018, Daun Yeagley <daun@...> wrote:
Hi Staffan

The physical layer for IEE-488 itself is essentially unchanged from the original.? 488.2 deals more with the messaging protocol.
This is where all the "universal" commands originated (all the * commands like *IDN?, etc.).
If you saw my PM to you a bit ago, you saw an example of a "non-488.2" communication using the Agilent IO libraries.? In other words, those nifty commands are not available to the old "R2D2" command structure instruments.? I guess I'll include that listing here, for others to see as well.? This code sets up and gets readings from an HP3478A voltmeter, which is pre-488.2 (R2D2 "language")

Daun
Daun E. Yeagley II, N8ASB
On 11/19/2018 4:01 PM, Staffan wrote:
Hello,

Many thanks. Notice that I replied to your direct mail. I don't think the problem lies in the 436, but rather in how the USB dongle 82357 performs communication. Don't know if the GPIB standard was updated - 488.2 seems to be from 1992, whereas the instrument predates 1980. It would be great to have a configuration within VISA to support different standards for different instruments - or is this perhaps not needed? Sounds strange that there shouldn't be sufficient backwards compatibility for a data bus!

Regards,
? Staffan

 

Hello,

Is this working with the 82357, it would be a great starting point. Although I just don’t understand why interactive IO doesn’t work.?

Has anyone experienced differences between interactive IO and using the libraries - I guess interactive IO just is an interface to the libs?

My best bet right now is that REN should be controlled (pulled inactive) for reading data from the 436. I just don’t know how to test this with the 82357/VISA libraries.?

Regards,
?Staffan




On Monday, November 19, 2018, Daun Yeagley <daun@...> wrote:
Hi Staffan

The physical layer for IEE-488 itself is essentially unchanged from the original.? 488.2 deals more with the messaging protocol.
This is where all the "universal" commands originated (all the * commands like *IDN?, etc.).
If you saw my PM to you a bit ago, you saw an example of a "non-488.2" communication using the Agilent IO libraries.? In other words, those nifty commands are not available to the old "R2D2" command structure instruments.? I guess I'll include that listing here, for others to see as well.? This code sets up and gets readings from an HP3478A voltmeter, which is pre-488.2 (R2D2 "language")

Daun
Daun E. Yeagley II, N8ASB
On 11/19/2018 4:01 PM, Staffan wrote:
Hello,

Many thanks. Notice that I replied to your direct mail. I don't think the problem lies in the 436, but rather in how the USB dongle 82357 performs communication. Don't know if the GPIB standard was updated - 488.2 seems to be from 1992, whereas the instrument predates 1980. It would be great to have a configuration within VISA to support different standards for different instruments - or is this perhaps not needed? Sounds strange that there shouldn't be sufficient backwards compatibility for a data bus!

Regards,
? Staffan

 

开云体育

Hi Staffan

The physical layer for IEE-488 itself is essentially unchanged from the original.? 488.2 deals more with the messaging protocol.
This is where all the "universal" commands originated (all the * commands like *IDN?, etc.).
If you saw my PM to you a bit ago, you saw an example of a "non-488.2" communication using the Agilent IO libraries.? In other words, those nifty commands are not available to the old "R2D2" command structure instruments.? I guess I'll include that listing here, for others to see as well.? This code sets up and gets readings from an HP3478A voltmeter, which is pre-488.2 (R2D2 "language")

Daun
Daun E. Yeagley II, N8ASB
On 11/19/2018 4:01 PM, Staffan wrote:

Hello,

Many thanks. Notice that I replied to your direct mail. I don't think the problem lies in the 436, but rather in how the USB dongle 82357 performs communication. Don't know if the GPIB standard was updated - 488.2 seems to be from 1992, whereas the instrument predates 1980. It would be great to have a configuration within VISA to support different standards for different instruments - or is this perhaps not needed? Sounds strange that there shouldn't be sufficient backwards compatibility for a data bus!

Regards,
? Staffan

Form1.pdf
Form1.pdf

 

Hello,

Many thanks. Notice that I replied to your direct mail. I don't think the problem lies in the 436, but rather in how the USB dongle 82357 performs communication. Don't know if the GPIB standard was updated - 488.2 seems to be from 1992, whereas the instrument predates 1980. It would be great to have a configuration within VISA to support different standards for different instruments - or is this perhaps not needed? Sounds strange that there shouldn't be sufficient backwards compatibility for a data bus!

Regards,
? Staffan
 

Hi Saffan,
I sent you in PM some military manual for 436A. Go from page 3-18 onward, there is about HPIB communication.
Milan

On Mon, 19 Nov 2018, 20:05 Staffan <testjarfalla63@... wrote:
Hello,

Some more findings... It seems like my Arduino can talk to the instrument after all. Pulling REN low (active) makes it listen to commands sent to its listen address.?
However, with the REN (remote enable) active, it _won't_ return any readings! Releasing REN, I get readouts again...

Can it be that the 82357B keeps the REN line low the whole time it has the instrument addressed? If so, anyone can hint me how to pull it high when I want to read from the instrument?

Thanks to the code in the Arduino project (again, thanks to Emanuele Girlando!) I'm fairly sure what sequence to send (control lines). Anyone know how this can be bit-banged (for example) on the 82357B? The Interactive IO does not give many options unfortunately.

Regards,
? Staffan
? Staffan

On Mon, Nov 19, 2018 at 2:07 PM Tom Holmes <tholmes@...> wrote:
Steffan...

Maybe I missed you saying so, but with the Keysight IOLibraries installed the 82357A/B should be essentially transparent to you. Connection Expert will let you assign it a name such as GPIB0 and then you just send commands to the 436's address.
I don't recall the exact details but there is a box to check to use 488.2 vintage protocol but that's about it. Unless there is something amiss with it, I doubt that the adapter is the problem. Since it appears to be at least sending commands, that doesn't seem likely.

From Tom Holmes, N8ZM
 

Hello,

Some more findings... It seems like my Arduino can talk to the instrument after all. Pulling REN low (active) makes it listen to commands sent to its listen address.?
However, with the REN (remote enable) active, it _won't_ return any readings! Releasing REN, I get readouts again...

Can it be that the 82357B keeps the REN line low the whole time it has the instrument addressed? If so, anyone can hint me how to pull it high when I want to read from the instrument?

Thanks to the code in the Arduino project (again, thanks to Emanuele Girlando!) I'm fairly sure what sequence to send (control lines). Anyone know how this can be bit-banged (for example) on the 82357B? The Interactive IO does not give many options unfortunately.

Regards,
? Staffan
? Staffan

On Mon, Nov 19, 2018 at 2:07 PM Tom Holmes <tholmes@...> wrote:
Steffan...

Maybe I missed you saying so, but with the Keysight IOLibraries installed the 82357A/B should be essentially transparent to you. Connection Expert will let you assign it a name such as GPIB0 and then you just send commands to the 436's address.
I don't recall the exact details but there is a box to check to use 488.2 vintage protocol but that's about it. Unless there is something amiss with it, I doubt that the adapter is the problem. Since it appears to be at least sending commands, that doesn't seem likely.

From Tom Holmes, N8ZM
 

Steffan...

Maybe I missed you saying so, but with the Keysight IOLibraries installed the 82357A/B should be essentially transparent to you. Connection Expert will let you assign it a name such as GPIB0 and then you just send commands to the 436's address.
I don't recall the exact details but there is a box to check to use 488.2 vintage protocol but that's about it. Unless there is something amiss with it, I doubt that the adapter is the problem. Since it appears to be at least sending commands, that doesn't seem likely.

From Tom Holmes, N8ZM
 

Hello,

Short update. Just recalling I had an Arduino setup for GPIB-USB (many thanks to Emanuele Girlando!). It works using that one to do a ++read and get a response, but then I don't seem to be able to write to the instrument...

Any hints on doing everything on 82357 would be much appreciated...

Regards,
? Staffan

1 - 20 of 29