Re: Working with secondary addresses
John <[email protected]> Mon, 30 Mar 2026 22:01:07 +0100
| Newsgroups | gmane.linux.hardware.gpib.general |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============7415344377127156189==
Content-Type: multipart/alternative;
boundary="------------UxgYYtKrNr5N1HVKHnlzcSYy"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------UxgYYtKrNr5N1HVKHnlzcSYy
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Dave,
I had tried reading various files on the drive but for consistency have
now stuck with file 13 in both scripts. This is an ASCII data file. I
was also somewhat re-assured by the fact that when I tried running TYPE
on a binary file, both of the parameters were returned correctly so at
least I know that the TYPE command works as expected (using the Perl
script at least).
You point about the device handling the 0x20 and 0x40 characters when
the Perl script is used is a good point. If that was the issue, then the
Perl script should have failed as well.
I re-ran my scripts wile monitoring the GPIB activity and found that I
consistently get the following bytes sent:
FIND:
40 3F 25 7B
TYPE:
3F 20 45 66
READ:
3F 20 45 6D
CLOSE:
40 3F 25 62
For the Python version I had been getting only as far as:
FIND:
40 3F 25 7B
I added the CLOSE command to the end of the Perl script in addition to
ibclr($dev) in case the file was being left in an open or unexpected
state. The bytes being sent are consistent between Perl and Python
scripts at least for the first command and also in comparison to to the
sequences you suggest, so that is good. However, for some reason Python
didn't get beyond the first command. I added some comments into the
Python script as I did with the Perl script so that one could see which
stage it was failing. This confirmed that the script was failing on the
first FIND command, yet the command bytes were being sent on the bus and
read by the device.
The error message (replicated here for convenience) refers to the second
command:
$ ./test_storage.py
FIND file ....
Traceback (most recent call last):
File "/home/johnc/Test/linux-gpib/./test_storage.py", line 43, in
<module>
gpib.write(cmd_find, fnumstr.encode())
~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^
gpib.GpibError: write() failed: You have attempted to write data or
command bytes, but there are no listeners currently addressed.
On rare occasions, more than one command does actually get successfully
executed by the Python script, but it fails most of the time. I tried
playing with different timeout intervals and using integer values such
as 12 and 13 instead of gpib.T10s etc, but that made little difference.
With Perl its the opposite. The Perl script seems to work consistently
although it fails very occasionally.
Since the 4 bytes of the FIND command were being sent over the bus, I
then looked a bit further at LA trace to the parameter data being sent.
Here I noticed a subtle difference between the bytes that Perl was
sending compared to those being sent by Python. For file 13, Perl sent
0x31, 0x33, but Python sent 0x31, 0x33, 0x0D. I therefore modified the
Python script to remove the 0x0D (CR) and send just the 0x31 and 0x33.
This works sort-of around 50% of the time. Sometimes the entire script
completes, sometimes it does not and fails on the CLOSE command. Other
times it still fails on the first command. I tried passing the
characters as a string ("13") as well as a binary representation
(b'\x31\x33') but the result was the same. At least this now succeeds
some of the time, so that is progress, but obviously there is still an
issue.
The weird thing was, that in my Perl script, the CR was already added to
the two digit character sequence that was being sent (e.g. $fnum."\r").
I also tried using "13\r" in case the append was not working. However,
in both cases, the Perl script sent only 0x31, 0x33 - no 0x0D. If I
passed just "13" it worked just the same. Evidently, the CR is being
removed before the characters are sent over the bus. Not sure where that
is happening or the reason for it, nor why this should make a difference
to the receiving device. On the Tektronix 4051, the CR is the standard
termination character so it ought to be processed as such in along with
the EOI signal. I might have expected a problem if the character 0x0A
(usually newline) was being sent, as it has a special meaning, but that
is NOT the case.
I am still investigating.
BTW, the linux-gpib library version that I am using is 4.3.7.
Regards.
On 27/03/2026 10:11, dave penkler wrote:
> Hi John,
> Thanks, they both look fine. There is no reason why the address setup
> sequence should be different between the python and perl scripts. In
> both cases it is done by the same C ibwrt() and ibrd()
> library routines. I noticed you are sending find file 1 in the python
> script and 13 in the perl script. Are you still getting the no
> listener error with the python script or something else ?
>
> Regarding the addressing sequences sent on the bus:
> For the initial write on the find descriptor it should be
> *40 3f 25 7b => TLK0 UNL LSN5 SAD27*
> and for the read on the input descriptor it should be
> *45 6d 3f 20 => TLK5 SAD13 UNL LSN0*
> again assuming the controller to be at gpib address 0. The controller
> can have any address between 0 and 30 which can be configured in the
> gpib.conf file. Of course each device on the bus must have a unique
> address.
>
> In theory, when reading, it is not essential that the controller send
> its listen address (0x20) on the bus provided it does send an unlisten
> (x03f). Also, when writing, if it does not send its talk address it
> would need to send an untalk (0x5f). But in general controllers always
> send talk and listen commands addressed to themselves on the bus,
> which is the case for linux-gpib. So if the perl script works then
> your device must be able to deal with the 0x20 and 0x40 commands.
>
> The linux-gpib library does not send the 0x5f (untalk) when another
> talker is being setup because, as I mentioned before, any talk address
> being sent on the bus suffices to stop any other previous talker from
> being the talker, i.e. the untalk is redundant when a device is being
> addressed to talk in the setup sequence. The unlisten (0x3f) is
> necessary, however, because multiple listeners can be addressed at the
> same time like when sending a group execute trigger command to a bunch
> of devices at once. Also, by default, our library does not send the
> unlisten untalk sequence [0x3f 0x5f] at the end of a transmission. It
> can be configured to do so with ibconfig() by setting the IbcUnAddr
> option. Not sending the un-address sequence [UNL UNT] at the end of a
> device read or write allows some optimisation when multiple reads or
> multiple writes are need to be performed in a row on the same device.
> The first operation is done on the device descriptor and subsequent
> operations are then done on the board descriptor directly to avoid
> sending the address setup sequence each time. Hope this helps.
>
> BTW, what version of the library are you using ?
>
> cheers,
> -Dave
> PS: You can find readable tutorial on all things GPIB (aka HPIB) at
> hp9845.net <https://www.hp9845.net/9845/tutorials/hpib/>.
>
>
> On Fri, 27 Mar 2026 at 00:10, John <[email protected]> wrote:
>
> Dave,
>
> I have attached the two scripts (.pl and .py).
>
> I was aware that 0x20 is added to instruct the remote device to
> listen, and 0x40 to make the device talk, but I was not aware that
> 0x20 and 0x40 actually needed to be sent and I haven't seen this
> with communications between the Tektronix 4051 and 4924. The
> device I am using is an emulator for the latter and I suspect that
> it doesn't know how to deal with the 0x20 and 0x40 bytes.
>
> One thing that springs to mind is that this assumes that the
> controller will always be at address 0 ?
>
> I digress here a bit, but I believe that Take Control (TCT) can be
> sent to a device to request it to become controller. So how would
> this work since the prospective new controller must be configured
> with an address other than zero? Ok, this is not relevant to the
> issue at hand, but I am trying to make sense of what seems to be
> an assumption that the controller will always be address zero?
>
> There is something weird going on here and 3F 20 25 7B
> theoretically shouldn't work but it does. On the other hand 40 3F
> 25 7B does not seem to be working, but from your comments it
> transpires that it probably should. GPIB comms examples I have
> seen usually start with 3F 5F and a sequence of command bytes,
> after which ATN gets unasserted and data is either sent or
> received. Then there is an ATN with a 5F 3F at the end. Not all
> comms have been like that. I have seen the Tektronix 4051 hold the
> transmission when the buffer gets full and then just send the
> single byte talk address to request the next batch or line of
> data. I am rambling a bit perhaps, but I am trying to understand a
> bit more about how GPIB comms work in some situations.
>
> Any help in understanding the matter would be appreciated.
>
>
> On 26/03/2026 18:07, dave penkler wrote:
>> Hi John,
>> There is something weird going on here.
>>
>> If I run the Perl script, I see the bytes 3F 20 25 7B being
>> received on the device while ATN is asserted.
>>
>> Here we see 3F unlisten, 20 listen controller, 25 7B listen pad 5
>> sad 7B - this makes no sense as there is no talker ?
>>
>> If I run the Python script I see: 40 3F 25 7B
>>
>> This is more sensible: 40 talk controller, 3F unlisten, 25 7B
>> listen pad 5 sad 7B
>> Sending the 40 first is OK. It is seen by all other devices as
>> Other Talk Address (OTA) which pushes them into the TIDS (talker
>> idle state) and
>> puts the controller into TACS (talker active state) assuming the
>> controller is on pad 0.
>> Please send the python and perl scripts that produced these outputs.
>> Curiouser and curiouser...
>> -Dave
>>
>> On Thu, 26 Mar 2026 at 14:32, John <[email protected]> wrote:
>>
>> Dave,
>>
>> Thank you for spotting my mistake. Yes it should be 0x7B not
>> 0x73. I tried changing the 0x73 to 0x7B but unfortunately
>> still get the same error. I also tried the decimal
>> equivalents of the HEX value. Same result.
>>
>> If I run the Perl script, I see the bytes 3F 20 25 7B being
>> received on the device while ATN is asserted.
>>
>> If I run the Python script I see: 40 3F 25 7B
>>
>> I did wonder whether the hex 20 is the controller listen
>> address 0, but then there isn't any data expected back from
>> secondary 0x7B. On the other hand why would Python send talk
>> 40 before the 3F which normally comes first?
>>
>> This short script doesn't use secondary addressing, but
>> otherwise works perfectly well on a HP34401A multimeter:
>>
>> #!/usr/bin/python3
>>
>> import gpib
>>
>> # GPIB interface 0, address 22
>> con = None
>> try:
>> con = gpib.dev <http://gpib.dev>(0,22)
>> except gpib.GpibError as e:
>> print(e)
>> exit()
>>
>> status = gpib.write(con, "*IDN?")
>> deviceID = gpib.read(con, 1000).decode()
>> print("Found device: " + deviceID)
>>
>> status = gpib.write(con, "meas?")
>> measurement = gpib.read(con, 3000).decode()
>> print("Measurement: " + measurement)
>>
>>
>> Its entirely possible that that the other device might be
>> misbehaving in some way. I am not entirely convinced that
>> either the 20 or the 40 should actually be there? I need to
>> dig further into that. I will post an update if I find anything.
>>
>>
--------------UxgYYtKrNr5N1HVKHnlzcSYy
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Re: [Linux-gpib-general] Working with secondary addresses</title>
</head>
<body>
<p>Dave,</p>
<p>I had tried reading various files on the drive but for
consistency have now stuck with file 13 in both scripts. This is
an ASCII data file. I was also somewhat re-assured by the fact
that when I tried running TYPE on a binary file, both of the
parameters were returned correctly so at least I know that the
TYPE command works as expected (using the Perl script at least).</p>
<p>You point about the device handling the 0x20 and 0x40 characters
when the Perl script is used is a good point. If that was the
issue, then the Perl script should have failed as well.</p>
<p>I re-ran my scripts wile monitoring the GPIB activity and found
that I consistently get the following bytes sent:</p>
<p>FIND:<br>
40 3F 25 7B</p>
<p>TYPE:<br>
3F 20 45 66</p>
<p>READ:<br>
3F 20 45 6D</p>
<p>CLOSE:<br>
40 3F 25 62 </p>
<p>For the Python version I had been getting only as far as:</p>
<p>FIND:<br>
40 3F 25 7B </p>
<p>I added the CLOSE command to the end of the Perl script in
addition to ibclr($dev) in case the file was being left in an open
or unexpected state. The bytes being sent are consistent between
Perl and Python scripts at least for the first command and also in
comparison to to the sequences you suggest, so that is good.
However, for some reason Python didn't get beyond the first
command. I added some comments into the Python script as I did
with the Perl script so that one could see which stage it was
failing. This confirmed that the script was failing on the first
FIND command, yet the command bytes were being sent on the bus and
read by the device.</p>
<p>The error message (replicated here for convenience) refers to the
second command:</p>
<p>$ ./test_storage.py<br>
FIND file ....<br>
Traceback (most recent call last):<br>
File "/home/johnc/Test/linux-gpib/./test_storage.py", line 43,
in <module><br>
gpib.write(cmd_find, fnumstr.encode())<br>
~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
gpib.GpibError: write() failed: You have attempted to write data
or command bytes, but there are no listeners currently addressed.<br>
</p>
<p>On rare occasions, more than one command does actually get
successfully executed by the Python script, but it fails most of
the time. I tried playing with different timeout intervals and
using integer values such as 12 and 13 instead of gpib.T10s etc,
but that made little difference. With Perl its the opposite. The
Perl script seems to work consistently although it fails very
occasionally.</p>
<p>Since the 4 bytes of the FIND command were being sent over the
bus, I then looked a bit further at LA trace to the parameter data
being sent. Here I noticed a subtle difference between the bytes
that Perl was sending compared to those being sent by Python. For
file 13, Perl sent 0x31, 0x33, but Python sent 0x31, 0x33, 0x0D. I
therefore modified the Python script to remove the 0x0D (CR) and
send just the 0x31 and 0x33. This works sort-of around 50% of the
time. Sometimes the entire script completes, sometimes it does not
and fails on the CLOSE command. Other times it still fails on the
first command. I tried passing the characters as a string ("13")
as well as a binary representation (b'\x31\x33') but the result
was the same. At least this now succeeds some of the time, so that
is progress, but obviously there is still an issue.</p>
<p>The weird thing was, that in my Perl script, the CR was already
added to the two digit character sequence that was being sent
(e.g. $fnum."\r"). I also tried using "13\r" in case the append
was not working. However, in both cases, the Perl script sent only
0x31, 0x33 - no 0x0D. If I passed just "13" it worked just the
same. Evidently, the CR is being removed before the characters are
sent over the bus. Not sure where that is happening or the reason
for it, nor why this should make a difference to the receiving
device. On the Tektronix 4051, the CR is the standard termination
character so it ought to be processed as such in along with the
EOI signal. I might have expected a problem if the character 0x0A
(usually newline) was being sent, as it has a special meaning, but
that is NOT the case.</p>
<p>I am still investigating.</p>
<p>BTW, the linux-gpib library version that I am using is 4.3.7.</p>
<p>Regards.</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 27/03/2026 10:11, dave penkler
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAL=kjP0QtscHMxmGAv=ZPeqw2hRv+ee4QQyv+MJ7MUy9wjBv8w@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">Hi John,
<div>Thanks, they both look fine. There is no reason why the
address setup sequence should be different between the
python and perl scripts. In both cases it is done by the
same C ibwrt() and ibrd() library routines. I noticed you
are sending find file 1 in the python script and 13 in the
perl script. Are you still getting the no listener error
with the python script or something else ?</div>
<div><br>
</div>
<div>Regarding the addressing sequences sent on the bus:</div>
<div>For the initial write on the find descriptor it should be</div>
<div><font face="monospace"><b>40 3f 25 7b => TLK0 UNL
LSN5 SAD27</b></font></div>
<div>and for the read on the input descriptor it should be</div>
<div><font face="monospace"><b>45 6d 3f 20 => TLK5
SAD13 UNL LSN0</b></font></div>
<div>again assuming the controller to be at gpib address 0.
The controller can have any address between 0 and 30 which
can be configured in the gpib.conf file. Of course each
device on the bus must have a unique address.</div>
<div><br>
</div>
<div>In theory, when reading, it is not essential that the
controller send its listen address (0x20) on the bus
provided it does send an unlisten (x03f). Also, when
writing, if it does not send its talk address it would need
to send an untalk (0x5f). But in general controllers always
send talk and listen commands addressed to themselves on the
bus, which is the case for linux-gpib. So if the perl script
works then your device must be able to deal with the 0x20
and 0x40 commands.</div>
<div><br>
</div>
<div>The linux-gpib library does not send the 0x5f (untalk)
when another talker is being setup because, as I mentioned
before, any talk address being sent on the bus suffices to
stop any other previous talker from being the talker, i.e.
the untalk is redundant when a device is being addressed to
talk in the setup sequence. The unlisten (0x3f) is
necessary, however, because multiple listeners can be
addressed at the same time like when sending a group execute
trigger command to a bunch of devices at once. Also, by
default, our library does not send the unlisten untalk
sequence [0x3f 0x5f] at the end of a transmission. It can be
configured to do so with ibconfig() by setting the IbcUnAddr
option. Not sending the un-address sequence [UNL UNT] at the
end of a device read or write allows some optimisation when
multiple reads or multiple writes are need to be performed
in a row on the same device. The first operation is done on
the device descriptor and subsequent operations are then
done on the board descriptor directly to avoid sending the
address setup sequence each time. Hope this helps.</div>
<div><br>
</div>
<div>BTW, what version of the library are you using ?</div>
<div><br>
</div>
<div>cheers,</div>
<div>-Dave</div>
</div>
PS: You can find readable tutorial on all things GPIB (aka
HPIB) at <a href="https://www.hp9845.net/9845/tutorials/hpib/"
moz-do-not-send="true">hp9845.net</a>.
<div><br>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Fri, 27 Mar 2026 at
00:10, John <<a href="mailto:[email protected]"
moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Dave,</p>
<p>I have attached the two scripts (.pl and .py).</p>
<p>I was aware that 0x20 is added to instruct the remote
device to listen, and 0x40 to make the device talk, but
I was not aware that 0x20 and 0x40 actually needed to be
sent and I haven't seen this with communications between
the Tektronix 4051 and 4924. The device I am using is an
emulator for the latter and I suspect that it doesn't
know how to deal with the 0x20 and 0x40 bytes.</p>
<p>One thing that springs to mind is that this assumes
that the controller will always be at address 0 ? </p>
<p>I digress here a bit, but I believe that Take Control
(TCT) can be sent to a device to request it to become
controller. So how would this work since the prospective
new controller must be configured with an address other
than zero? Ok, this is not relevant to the issue at
hand, but I am trying to make sense of what seems to be
an assumption that the controller will always be address
zero?</p>
There is something weird going on here and 3F 20 25 7B
theoretically shouldn't work but it does. On the other
hand 40 3F 25 7B does not seem to be working, but from
your comments it transpires that it probably should. GPIB
comms examples I have seen usually start with 3F 5F and a
sequence of command bytes, after which ATN gets unasserted
and data is either sent or received. Then there is an ATN
with a 5F 3F at the end. Not all comms have been like
that. I have seen the Tektronix 4051 hold the transmission
when the buffer gets full and then just send the single
byte talk address to request the next batch or line of
data. I am rambling a bit perhaps, but I am trying to
understand a bit more about how GPIB comms work in some
situations.
<p>Any help in understanding the matter would be
appreciated.</p>
<p><br>
</p>
<div>On 26/03/2026 18:07, dave penkler wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">Hi John,
<div>There is something weird going on here.</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If
I run the Perl script, I see the bytes 3F 20 25 7B
being received on the device while ATN is
asserted.</blockquote>
<div>Here we see 3F unlisten, 20 listen controller,
25 7B listen pad 5 sad 7B - this makes no sense as
there is no talker ?<br>
<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If
I run the Python script I see: 40 3F 25 7B</blockquote>
</div>
<div>This is more sensible: 40 talk controller, 3F
unlisten, 25 7B listen pad 5 sad 7B </div>
<div>Sending the 40 first is OK. It is seen by all
other devices as Other Talk Address (OTA) which
pushes them into the TIDS (talker idle state) and </div>
<div>puts the controller into TACS (talker active
state) assuming the controller is on pad 0.</div>
<div>Please send the python and perl scripts that
produced these outputs.</div>
<div>Curiouser and curiouser...</div>
<div>-Dave</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, 26 Mar
2026 at 14:32, John <<a
href="mailto:[email protected]"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">[email protected]</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Dave,</p>
<p>Thank you for spotting my mistake. Yes it
should be 0x7B not 0x73. I tried changing the
0x73 to 0x7B but unfortunately still get the
same error. I also tried the decimal
equivalents of the HEX value. Same result.</p>
<p>If I run the Perl script, I see the bytes 3F
20 25 7B being received on the device while
ATN is asserted.</p>
<p>If I run the Python script I see: 40 3F 25 7B</p>
<p>I did wonder whether the hex 20 is the
controller listen address 0, but then there
isn't any data expected back from secondary
0x7B. On the other hand why would Python send
talk 40 before the 3F which normally comes
first?</p>
<p>This short script doesn't use secondary
addressing, but otherwise works perfectly well
on a HP34401A multimeter:</p>
<p>#!/usr/bin/python3<br>
<br>
import gpib<br>
<br>
# GPIB interface 0, address 22<br>
con = None<br>
try:<br>
con = <a href="http://gpib.dev"
target="_blank" moz-do-not-send="true">gpib.dev</a>(0,22)<br>
except gpib.GpibError as e:<br>
print(e)<br>
exit()<br>
<br>
status = gpib.write(con, "*IDN?")<br>
deviceID = gpib.read(con, 1000).decode()<br>
print("Found device: " + deviceID)<br>
<br>
status = gpib.write(con, "meas?")<br>
measurement = gpib.read(con, 3000).decode()<br>
print("Measurement: " + measurement)<br>
</p>
<p><br>
</p>
<p>Its entirely possible that that the other
device might be misbehaving in some way. I am
not entirely convinced that either the 20 or
the 40 should actually be there? I need to dig
further into that. I will post an update if I
find anything.</p>
<p><br>
</p>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>
--------------UxgYYtKrNr5N1HVKHnlzcSYy--
--===============7415344377127156189==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--===============7415344377127156189==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Linux-gpib-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
--===============7415344377127156189==--