Re: Working with secondary addresses
dave penkler <[email protected]> Fri, 27 Mar 2026 11:11:04 +0100
| Newsgroups | gmane.linux.hardware.gpib.general |
|---|---|
| Message-ID | <CAL=kjP0QtscHMxmGAv=ZPeqw2hRv+ee4QQyv+MJ7MUy9wjBv8w@mail.gmail.com> |
--===============0794320188652180684== Content-Type: multipart/alternative; boundary="000000000000ad65ad064dfeb8a9" --000000000000ad65ad064dfeb8a9 Content-Type: text/plain; charset="UTF-8" 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(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. >> >> >> --000000000000ad65ad064dfeb8a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr">Hi=C2=A0John,<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=C2=A0=C2=A0routines. 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 ?</d= iv><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><d= iv><font face=3D"monospace"><b>40 3f 25 7b=C2=A0 =C2=A0 =C2=A0=3D> TLK0 = UNL LSN5 SAD27</b></font></div><div>and for the read on the input descripto= r it should be</div><div><font face=3D"monospace"><b>45 6d 3f 20=C2=A0 =C2= =A0 =C2=A0=3D> TLK5 SAD13 UNL LSN0</b></font></div><div>again assuming t= he 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 e= ach=C2=A0 device on the bus must have a unique address.</div><div><br></div= ><div>In theory,=C2=A0 when reading, it is not essential that the controlle= r send its listen address (0x20) on the bus provided it does send an unlist= en (x03f). Also, when writing,=C2=A0 if it does not send its talk address i= t would need to send an untalk (0x5f). But in general controllers always se= nd talk and listen commands addressed to themselves on the bus, which is th= e 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 multipl= e listeners can be addressed at the same time like when sending a group exe= cute trigger command to a bunch of devices at once.=C2=A0 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 set= ting 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 r= eads or multiple writes are need to be performed in a row on the same devic= e. The first operation is done on the device descriptor and subsequent oper= ations 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=C2=A0tutorial = on all things=C2=A0 GPIB (aka HPIB) at=C2=A0<a href=3D"https://www.hp9845.n= et/9845/tutorials/hpib/">hp9845.net</a>.<div><br></div>=C2=A0<br><div class= =3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr= ">On Fri, 27 Mar 2026 at 00:10, John <<a href=3D"mailto:subs@qcontinuum.= plus.com">[email protected]</a>> wrote:<br></div><blockquote clas= s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r= gb(204,204,204);padding-left:1ex"><u></u> =20 =20 =20 <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 ?=C2=A0</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=3D"cite"> =20 <div dir=3D"ltr"> <div dir=3D"ltr">Hi=C2=A0John, <div>There is something weird going on here.</div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8= ex;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=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 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=C2=A0devices as Other Talk Address (OTA) which pushes the= m into the TIDS (talker idle state) 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 perl scripts that produced these outputs.</div> <div>Curiouser and curiouser...</div> <div>-Dave</div> </div> <br> <div class=3D"gmail_quote"> <div dir=3D"ltr" class=3D"gmail_attr">On Thu, 26 Mar 2026 at 14:32, John <<a href=3D"mailto:[email protected]" tar= get=3D"_blank">[email protected]</a>> wrote:<br> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8= ex;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 expecte= d 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, bu= t 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 =3D None<br> try:<br> =C2=A0 =C2=A0 con =3D <a href=3D"http://gpib.dev" target=3D= "_blank">gpib.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, "*IDN?")<br> deviceID =3D gpib.read(con, 1000).decode()<br> print("Found device: " + deviceID)<br> <br> status =3D gpib.write(con, "meas?")<br> measurement =3D 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> --000000000000ad65ad064dfeb8a9-- --===============0794320188652180684== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0794320188652180684== 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 --===============0794320188652180684==--