Re: Working with secondary addresses

--===============5248109595712756152==
Content-Type: multipart/alternative; boundary="000000000000119b97064df14430"

--000000000000119b97064df14430
Content-Type: text/plain; charset="UTF-8"

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(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.
>
>
>

--000000000000119b97064df14430
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi=C2=A0John,<div>There is something weir=
d going on here.</div><blockquote class=3D"gmail_quote" style=3D"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 de=
vice while ATN is asserted.</blockquote><div>Here we see 3F unlisten, 20 li=
sten controller, 25 7B listen pad 5 sad 7B - this makes no sense as there i=
s no talker ?<br><br><blockquote class=3D"gmail_quote" style=3D"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 mo=
re sensible: 40 talk controller, 3F unlisten, 25 7B listen pad 5 sad 7B </d=
iv><div>Sending the 40 first is OK. It is seen by all other=C2=A0devices as=
 Other Talk Address (OTA) which pushes them into the TIDS (talker idle stat=
e) and=C2=A0</div><div>puts the controller into TACS (talker active state) =
assuming the controller is on pad 0.</div><div>Please send the python and p=
erl scripts that produced these outputs.</div><div>Curiouser and curiouser.=
..</div><div>-Dave</div></div><br><div class=3D"gmail_quote gmail_quote_con=
tainer"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, 26 Mar 2026 at 14:32,=
 John &lt;<a href=3D"mailto:[email protected]">[email protected].=
com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><u></u>

 =20
   =20
 =20
  <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&#39;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&#39;t use secondary addressing, but otherwis=
e
      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 =3D None<br>
      try:<br>
      =C2=A0 =C2=A0 con =3D <a href=3D"http://gpib.dev" target=3D"_blank">g=
pib.dev</a>(0,22)<br>
      except gpib.GpibError as e:<br>
      =C2=A0 =C2=A0 print(e)<br>
      =C2=A0 =C2=A0 exit()<br>
      <br>
      status =3D gpib.write(con, &quot;*IDN?&quot;)<br>
      deviceID =3D gpib.read(con, 1000).decode()<br>
      print(&quot;Found device: &quot; + deviceID)<br>
      <br>
      status =3D gpib.write(con, &quot;meas?&quot;)<br>
      measurement =3D gpib.read(con, 3000).decode()<br>
      print(&quot;Measurement: &quot; + 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></p>
    <p><br></p></div>
</blockquote></div></div>

--000000000000119b97064df14430--


--===============5248109595712756152==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============5248109595712756152==
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

--===============5248109595712756152==--