Re: Working with secondary addresses
John <[email protected]> Thu, 26 Mar 2026 21:34:16 +0000
| Newsgroups | gmane.linux.hardware.gpib.general |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------tCyLfk6z06APAMBEE5JR8X20 Content-Type: multipart/alternative; boundary="------------V7Xaq0z0LKm0vR3gocKtQZG6" --------------V7Xaq0z0LKm0vR3gocKtQZG6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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. > > --------------V7Xaq0z0LKm0vR3gocKtQZG6 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"> </head> <body> <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 class="moz-cite-prefix">On 26/03/2026 18:07, dave penkler wrote:<br> </div> <blockquote type="cite" cite="mid:CAL=kjP1TyFKHVQpPGCTdtrwUcigsQ47oXkpZOH+=+i-HbLz-4g@mail.gmail.com"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <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 gmail_quote_container"> <div dir="ltr" class="gmail_attr">On Thu, 26 Mar 2026 at 14:32, 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>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> </body> </html> --------------V7Xaq0z0LKm0vR3gocKtQZG6-- --------------tCyLfk6z06APAMBEE5JR8X20 Content-Type: text/x-python; charset=UTF-8; name="test_storage.py" Content-Disposition: attachment; filename="test_storage.py" Content-Transfer-Encoding: base64 IyEvdXNyL2Jpbi9weXRob24zCgppbXBvcnQgZ3BpYgppbXBvcnQgdGltZQoKIyBHUElCIGlu dGVyZmFjZSAwLCBhZGRyZXNzIDUKY29uID0gTm9uZQpwYWRkciA9IDUKZW90ID0gMQoKCiMg R1BJQiBpbnRlcmZhY2UgMCwgYWRkcmVzcyA1CiN0cnk6CiMgICAgY29uID0gZ3BpYi5kZXYo MCw1KQojZXhjZXB0IGdwaWIuR3BpYkVycm9yIGFzIGU6CiMgICAgcHJpbnQoZSkKIyAgICBl eGl0KCkKCgpjbWRfZmluZCA9ICBncGliLmRldiggMCwgcGFkZHIsIDB4N0IsIGdwaWIuVDEw cywgZW90LCAweDBEICkKY21kX2lucHV0ID0gIGdwaWIuZGV2KCAwLCBwYWRkciwgMHg2RCwg Z3BpYi5UMTBzLCBlb3QsIDB4MEQgKQpjbWRfdHlwZSA9ICBncGliLmRldiggMCwgcGFkZHIs IDB4NjYsIGdwaWIuVDEwcywgZW90LCAweDBEICkKdGltZS5zbGVlcCgxKQoKCiMgRklORCBm aWxlCmdwaWIud3JpdGUoY21kX2ZpbmQsIGInXHgzMVx4MEQnKQp0aW1lLnNsZWVwKDEpCgoK I0lOUFVUIGZpcnN0IGxpbmUKbGluZSA9IGdwaWIucmVhZChjbWRfaW5wdXQsIDEwMCkuZGVj b2RlKCkKdGltZS5zbGVlcCgxKQoKcHJpbnQobGluZSkKCgojIENsb3NlIGRvd24KZ3BpYi5j bG9zZShjbWRfZmluZCkKZ3BpYi5jbG9zZShjbWRfaW5wdXQpCmdwaWIuY2xvc2UoY21kX3R5 cGUpCgoK --------------tCyLfk6z06APAMBEE5JR8X20 Content-Type: application/x-perl; name="test-storage.pl" Content-Disposition: attachment; filename="test-storage.pl" Content-Transfer-Encoding: 7bit #!/usr/bin/perl # Before `make install' is performed this script should be runnable with # `make test'. After `make install' it should work as `perl test.pl' ######################### # change 'tests => 1' to 'tests => last_test_to_print'; use Test; use Time::HiRes qw(usleep time gettimeofday); use LinuxGpib; BEGIN { plan tests => 1 }; use LinuxGpib; ok(1); # If we made it this far, we're ok. ######################### # Insert your test code below, the Test module is use()ed here so read # its man page ( perldoc Test ) for help writing this test script. $device = "Tektronix 4924"; $cmd = ""; $idn = ""; $result = ""; $fnum = "13"; my $dev_find = LinuxGpib::ibdev(0, 5, 0x7B, 12, 1, 0); my $dev_input = LinuxGpib::ibdev(0, 5, 0x6D, 12, 1, 0x0D); my $dev_type = LinuxGpib::ibdev(0, 5, 0x66, 12, 1, 0x0D); print "FIND file ".$fnum." .....\n"; LinuxGpib::ibwrt($dev_find, $fnum."\r", 2); time.sleep(1); print "Get file TYPE information...\n"; my $ftype = 0; my $fsize = 0; LinuxGpib::ibrd($dev_type, $ftype, 2); LinuxGpib::ibrd($dev_type, $fsize, 2); print "Type: "; print $ftype; print "\tSize: "; print $fsize; print "\n"; time.sleep(1); print "INPUT first line from file .....\n"; LinuxGpib::ibrd($dev_input, $result, 100); time.sleep(1); print $result; print "\n"; print "Done.\n"; # clear LinuxGpib::ibclr($dev); exit 0; --------------tCyLfk6z06APAMBEE5JR8X20 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --------------tCyLfk6z06APAMBEE5JR8X20 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 --------------tCyLfk6z06APAMBEE5JR8X20--