linux-gpib-general — linux-gpib package mailing list

[Linux-gpib-general] GPIB now native in Debian

[Matthias G. <m_g...@wi...>]

Hi,

I just wanted to let you know that GPIB now works natively in Debian 
(though only for the bitbang IO shield).
You need to:

1) Install the 6.19 kernel from backports (see the debian wiki how to 
enable and use it)
2) Install gpib-user-tools for the userspace parts (also from backports)
3) Create a gpib group (using groupadd) and verify then via groups that 
it succeeded
4) enjoy :)

Let me know if you run into any issues, and if you need any more kernel 
modules enabled.

-- 
Freundliche Grüsse / Best regards

Matthias Geiger
__________________________________________________________________
Matthias Geiger
Werkstudent
Forschung & Entwicklung/Research & Development

Phone : +49-6441-609-3004
Email : m_g...@wi...
URL   : www.wiwa.de

WIWA Wilhelm Wagner GmbH & Co. KG
Gewerbestrasse 1-3, 35633 Lahnau, Germany
Besucheranschrift/visitor address:
Georg-Ohm-Strasse 12, 35633 Lahnau, Germany

AG WETZLAR HRA 3223, Komplementär : Wagner GmbH (AG Wetzlar HRB 363)
UST-ID Nr: / VAT-No: DE113745802
Geschäftsführer: Dipl.-Ing. (FH) Peter Turczak, Dipl.-Wirt.-Ing. Malte Weber

Re: [Linux-gpib-general] Detecting whether ATN is asserted or un-asserted

[dave p. <dpe...@gm...>]

Hi John,
See in-line:

On Tue, 7 Apr 2026 at 18:19, John <su...@qc...> wrote:

> Dave,
>
> Thank you and sorry - I missed your inline program and was trying to roll
> my own.
>
> Having gone back through the messages I found it and tried it. It
> initially failed on this line:
>
> gpib.eot(0, eot)  # assert eoi on last byte written
>
> $ ./low_test.py
> Traceback (most recent call last):
>   File "/home/johnc/Test/linux-gpib/./low_test.py", line 29, in <module>
>     gpib.eot(0, eot)  # assert eoi on last byte written
>     ^^^^^^^^
> AttributeError: module 'gpib' has no attribute 'eot'
>
> So I commented that line out. I am not sure what it is supposed to be?
>
My bad, there is no gpib.eot() method.
Please use:
gpib.config(0, gpib.IbcEOT, 1)
 instead.

It then failed on:
>
> gpib_command(board,unl_unt)  # send unlisten untalk
>
> $ ./low_test.py
> FIND file ....
> Traceback (most recent call last):
>   File "/home/johnc/Test/linux-gpib/./low_test.py", line 39, in <module>
>     gpib_command(board,unl_unt)  # send unlisten untalk
>     ^^^^^^^^^^^^
> NameError: name 'gpib_command' is not defined
>
> I noticed you had used 'gpib.command' and 'gpib_command' alternately so I
> changed all occurrences of gpib_command with gpib.command. It then ran
> without language syntax errors but failed alternately between:
>
> $ ./low_test.py
> FIND file ....
> Traceback (most recent call last):
>   File "/home/johnc/Test/linux-gpib/./low_test.py", line 34, in <module>
>     gpib.command(board,add_find) # do addressing
>     ~~~~~~~~~~~~^^^^^^^^^^^^^^^^
> gpib.GpibError: cmd() failed: You have attempted to write data or command
> bytes, but there are no listeners currently addressed.
>
> and;
>
> $ ./low_test.py
> FIND file ....
> Traceback (most recent call last):
>   File "/home/johnc/Test/linux-gpib/./low_test.py", line 39, in <module>
>     gpib.command(board,unl_unt)  # send unlisten untalk
>     ~~~~~~~~~~~~^^^^^^^^^^^^^^^
> gpib.GpibError: cmd() failed: You have attempted to write data or command
> bytes, but there are no listeners currently addressed.
>
> Noted that ibcmd automatically asserts  ATN and that it remains asserted
> at the end.
>
> Also noted that ibwrt and ibrd automatically de-assert ATN.
>
> With regards to iblines, I was passing the wrong device variable to the
> sub-routine, but anyway, for now I am focused on your Python low level
> program. I will do an LA trace.
>
I checked out the LA traces you posted and the last one labeled
"Py-FIND-NOCR-fail.png" was presumably the Perl run which looks great.
The other two "Perl-FIND.png" and "Py-FIND.png" look the same and I can't
see any anomalies.

Can we get the py trace for a full 1600us starting from the initial falling
edge of ATN when it fails at line 34 ( gpib.command(board,add_find) # do
addressing).
I guess you can also comment out the sending of unl_unt as it works fine
without.
cheers,
-Dave

Re: [Linux-gpib-general] Detecting whether ATN is asserted or un-asserted

[John <su...@qc...>]

Dave,

Thank you and sorry - I missed your inline program and was trying to 
roll my own.

Having gone back through the messages I found it and tried it. It 
initially failed on this line:

gpib.eot(0, eot)  # assert eoi on last byte written

$ ./low_test.py
Traceback (most recent call last):
   File "/home/johnc/Test/linux-gpib/./low_test.py", line 29, in <module>
     gpib.eot(0, eot)  # assert eoi on last byte written
     ^^^^^^^^
AttributeError: module 'gpib' has no attribute 'eot'

So I commented that line out. I am not sure what it is supposed to be?

It then failed on:

gpib_command(board,unl_unt)  # send unlisten untalk

$ ./low_test.py
FIND file ....
Traceback (most recent call last):
   File "/home/johnc/Test/linux-gpib/./low_test.py", line 39, in <module>
     gpib_command(board,unl_unt)  # send unlisten untalk
     ^^^^^^^^^^^^
NameError: name 'gpib_command' is not defined

I noticed you had used 'gpib.command' and 'gpib_command' alternately so 
I changed all occurrences of gpib_command with gpib.command. It then ran 
without language syntax errors but failed alternately between:

$ ./low_test.py
FIND file ....
Traceback (most recent call last):
   File "/home/johnc/Test/linux-gpib/./low_test.py", line 34, in <module>
     gpib.command(board,add_find) # do addressing
     ~~~~~~~~~~~~^^^^^^^^^^^^^^^^
gpib.GpibError: cmd() failed: You have attempted to write data or 
command bytes, but there are no listeners currently addressed.

and;

$ ./low_test.py
FIND file ....
Traceback (most recent call last):
   File "/home/johnc/Test/linux-gpib/./low_test.py", line 39, in <module>
     gpib.command(board,unl_unt)  # send unlisten untalk
     ~~~~~~~~~~~~^^^^^^^^^^^^^^^
gpib.GpibError: cmd() failed: You have attempted to write data or 
command bytes, but there are no listeners currently addressed.

Noted that ibcmd automatically asserts  ATN and that it remains asserted 
at the end.

Also noted that ibwrt and ibrd automatically de-assert ATN.

With regards to iblines, I was passing the wrong device variable to the 
sub-routine, but anyway, for now I am focused on your Python low level 
program. I will do an LA trace.

Regards.



On 07/04/2026 13:53, dave penkler wrote:
> Hi,
> ibcmd will automatically assert ATN. ATN remains asserted at the end. 
> When you do an ibrd or ibwrt on the board ATN will automatically be 
> de-asserted. You might try the low-level programme I sent in-line 
> earlier. iblines is the best way to establish the state of the lines. 
> It must be issued against a board descriptor. Note that 
> iblines(&line_status) returns the mask for the valid lines in the 
> lower byte and the actual line state in the upper byte. Same for 
> python print (hex(int(gpib.lines(0)/256)))
> See iblines 
> <https://linux-gpib.sourceforge.io/doc_html/reference-function-iblines.html>
> cheers,
> -Dave
>
> On Mon, 6 Apr 2026 at 10:10, John <su...@qc...> wrote:
>
>     I have been working on a low level approach to driving a GPIB
>     device and
>     found the ibcac() and ibgts() functions, however, I cannot find a
>     way to
>     test whether the signal is asserted or un-asserted. For example,
>     there
>     is ibsta, but this is a on-shot value returned when calling a
>     function
>     but doesn't then tell me what has happened to the state of ATN after
>     calling the function. For example, after un-asserting ATN, I need to
>     make sure that the signal is high before sending data.
>
>     I also discovered iblines(), but this returns a constant value of
>     32768.
>
>     There is also ibcmd() which writes "command bytes", but I am unsure
>     whether this actually asserts ATN or not while doing so or whether
>     asserting ATN has to be done separately? How does this differ to
>     ibwrt()?
>
>     My interface is a National Instruments PCI card dated 1997 and marked
>     PCI-GPIB+. It uses the tnt4882 driver. I am working on Linux,
>
>     I would appreciate a little guidance on how to manage ATN manually.
>
>     Thank you.
>
>
>
>
>     _______________________________________________
>     Linux-gpib-general mailing list
>     Lin...@li...
>     https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

Re: [Linux-gpib-general] Working with secondary addresses

[John <su...@qc...>]

Hi,

I posted a message earlier with some trace images, but it was blocked. 
The traces show the FIND command being sent by Perl and also Python. I 
also added a third trace showing the complete transmission in Perl of 
the FIND command followed by the file number data. I can't show the 
Python version since it doesn't get that far. Since the images were too 
big, I have pasted them on imgbb (since imgur does not serve content to 
the UK). Here are the links:

Trace of Perl sending FIND:
https://ibb.co/jvWB3CJj

Trace of Pythin sending FIND:
https://ibb.co/F4dSZhDd

Trace of Perl sending FIND followed by file number 13:
https://ibb.co/9mYM7n7p

They seem to look fairly normal to me but  I would be interested to know 
what others think?

[Linux-gpib-general] Detecting whether ATN is asserted or un-asserted

[John <su...@qc...>]

I have been working on a low level approach to driving a GPIB device and 
found the ibcac() and ibgts() functions, however, I cannot find a way to 
test whether the signal is asserted or un-asserted. For example, there 
is ibsta, but this is a on-shot value returned when calling a function 
but doesn't then tell me what has happened to the state of ATN after 
calling the function. For example, after un-asserting ATN, I need to 
make sure that the signal is high before sending data.

I also discovered iblines(), but this returns a constant value of 32768.

There is also ibcmd() which writes "command bytes", but I am unsure 
whether this actually asserts ATN or not while doing so or whether 
asserting ATN has to be done separately? How does this differ to ibwrt()?

My interface is a National Instruments PCI card dated 1997 and marked 
PCI-GPIB+. It uses the tnt4882 driver. I am working on Linux,

I would appreciate a little guidance on how to manage ATN manually.

Thank you.

Re: [Linux-gpib-general] Working with secondary addresses

[John <su...@qc...>]

Dave,

You are quoting Pythin, but I was referring to Perl.

However, it is indeed a red herring because of my own stupidity! I asked 
Perl to send 2 bytes and that is exactly what it did. It sent just 0x31 
0x33, whereas Python, which does not seems to need a byte count 
parameter,  sent 0x31 0x33 0x0D.  I changed that numeric literal to 
length($funumstr) and, as expected, it then sent the 0x0D as well....  
So now I have a direct comparison with Python. It made no difference. 
Perl still works fine and the device does not care whether there is a 
terminating CR or not. Python still fails.

I am working on the low level approach.


On 01/04/2026 10:14, dave penkler wrote:
> Hi Guys,
> First I think we can give the 0x0D thing a miss. The ibdev was not 
> really setting it because the*reos* bit was not being set.
> cmd_input =gpib.dev <http://gpib.dev>( 0, paddr, 0x6D, gpib.T10s, eot, 0x0D )
> To set read termination on 0x0D , it should be 0x400 + 0x0D:
> cmd_input =gpib.dev <http://gpib.dev>( 0, paddr, 0x6D, gpib.T10s, eot, 0x40D )
> But because it was working without eos it would indicate that the 
> tk4924 emulator sends EOI.

-- 
John.

[Linux-gpib-general] [PATCH] Format Gpib.py and gpibtest.py

[Matthias G. <m_g...@wi...>]

Hi,

attached are two patches modernizing and formatting Gpib.py and 
gpibtest.py. Except for one print() statement there are no functional 
changes.

-- 
Freundliche Grüsse / Best regards

Matthias Geiger
__________________________________________________________________
Matthias Geiger
Werkstudent
Forschung & Entwicklung/Research & Development

Phone : +49-6441-609-3004
Email : m_g...@wi...
URL   : www.wiwa.de

WIWA Wilhelm Wagner GmbH & Co. KG
Gewerbestrasse 1-3, 35633 Lahnau, Germany
Besucheranschrift/visitor address:
Georg-Ohm-Strasse 12, 35633 Lahnau, Germany

AG WETZLAR HRA 3223, Komplementär : Wagner GmbH (AG Wetzlar HRB 363)
UST-ID Nr: / VAT-No: DE113745802
Geschäftsführer: Dipl.-Ing. (FH) Peter Turczak, Dipl.-Wirt.-Ing. Malte Weber

Re: [Linux-gpib-general] Working with secondary addresses

[John <su...@qc...>]

> You use a 10s timeout in your python code! Maybe you simple didn't not
> wait long enough. Kidding. :) Better use the provided constants, e.g.
> gpib.T1s

I take your point with that. 10s is an eternity in GPIB transmit terms 
and even 1s should be more than enough.

> But I guess this is a bad end anyway. Since your Perl code is working
> there must be a difference somewhere. Which is very strange, cause these
> are all only wrappers around the C code.

Yes, I think Dave Penler mentioned the same thing. The language is just 
a wrapper around the low level C code, so yes, very strange.

> So probably that is not a problem. Now handle yourself from function to
> function. You have the source code. Instrument it with print statements
> till you see where the difference is. I would do that on the C level.

I added a few more print statements, but its consistently breaking at 
this point:

$ ./test_storage.py
Check for the presence of the device ....
Device present.
Configure FIND ....
Configure INPUT ....
Configure TYPE ....
Configure CLOSE ....
Sleep 1 sec ....
FIND file ....
Traceback (most recent call last):
   File "/home/johnc/Test/linux-gpib/./test_storage.py", line 45, in 
<module>
     gpib.write(cmd_find, fnum)
     ~~~~~~~~~~^^^^^^^^^^^^^^^^
gpib.GpibError: write() failed: You have attempted to write data or 
command bytes, but there are no listeners currently addressed.

which means at this line:

gpib.write(cmd_find, fnum)

which may mean something needs to be changed in here:

cmd_find =  gpib.dev( 0, paddr, 0x7B, gpib.T10s, eot, 0 )

I tried changing the timeout to gpib.T1s or gpib.T30s (not that it 
needed to be any longer) but the exits with the error much too fast for 
the timeout to complete anyway.

Is there any way I can play with manually asserting ATN, sending bytes 
and then de-asserting ATN, then sending some bytes of data, terminating 
with an EOI or reading the returned data? Finally ending with UNT or UNL?



On 31/03/2026 20:13, Christian Grosz wrote:
> John,
>
>> Your example also seems to suggest that 'yes' can be used instead of 1?
> Don't mix up Perl, Python and the /etc/gpib.conf configuration file.
>
> You use a 10s timeout in your python code! Maybe you simple didn't not
> wait long enough. Kidding. :) Better use the provided constants, e.g.
> gpib.T1s
>
> But I guess this is a bad end anyway. Since your Perl code is working
> there must be a difference somewhere. Which is very strange, cause these
> are all only wrappers around the C code.
>
> For python
>
> linux-gpib-4.3.7/linux-gpib-user-4.3.7-orig/language/python/gpibinter.c
> ----
> static PyObject* gpib_dev(PyObject *self, PyObject *args)
> {
> 	int ud = -1;
> 	int board = 0;
> 	int pad = 0;
> 	int sad = NO_SAD;
> 	int tmo = T30s;
> 	int eot = 1;
> 	int eos_mode = 0;
> ...
> ----
>
> there is another set of defaults. For Perl it looks to me like a simple
> wrapper.
>
> So probably that is not a problem. Now handle yourself from function to
> function. You have the source code. Instrument it with print statements
> till you see where the difference is. I would do that on the C level.
>
> Christian
>
>

Re: [Linux-gpib-general] Working with secondary addresses

[John <su...@qc...>]

Christian,

Thank you for the reference.

This highlights another point of confusion for me.

 From the description of the ibdev command, the last argument is eos,  
which I took to mean the end-of-string character. From the description 
of ibeos, it seems this parameter refers to more than just an 8-bit 
character, but actually to eosmode which seems to be a 16-bit value 
where the upper byte is used to set bits that enable or disable specific 
modes. Calling it eos and then eosmode when you delve a bit deeper seems 
confusing.

I have never heard of the acronyms REOS and XEOS before, but I think I 
now understand that they refer to the specific bits of the most 
significant byte that turn mode functions on and off, so I appreciate 
the clarification.

So, if you set EOT to 1, then wouldn't EOI be automatically asserted on 
the EOS if that character if is used for termination anyway? It is, 
after all, the last character? Furthermore, wouldn't EOT + REOS do the 
same as XEOS?
I don't think in my example that EOS is required, just EOI, so setting 
EOT to 1 and EOS to 0 seems to be appropriate. However, if the value is 
omitted, does it just default to zero, i.e. that EOS is disabled and 
ignored?

Your example also seems to suggest that 'yes' can be used instead of 1?

BTW, the second NI linf ref EOT was of interest. Now I understand where 
this came from. Thanks.



On 31/03/2026 16:17, Christian Grosz wrote:
> Hi John,
>
>> It is unclear to me as to whether it needs a zero in there
>> or not?
>  From the docs
>
> ----
> https://linux-gpib.sourceforge.io/doc_html/reference-function-ibeos.html
> The least significant 8 bits of eosmode specify the eos character. You may
> also bitwise-or one or more of the following bits to set the eos mode:
> REOS = 0x400 # Enable termination of reads when eos character is received.
> XEOS = 0x800 # Assert the EOI line whenever the eos character is sent
> during writes.
> BIN = 0x1000 # Match eos character using all 8 bits (instead of only
> looking at the 7 least significant bits).
> ----
>
> You can set default values for the device in the config file.
>
> /etc/gpib.conf
> ----
> device
> {
>      minor = 0
>      name = "HP 9121D"
>      pad = 2 /* factory default */
>      sad = 126
>      set-eot = yes
>      set-xeos = yes
>      set-reos = yes
> }
> ----
>
> That worked for me beside for the 1F SAD.
>
> ----
> # Open a separate connection for each secondary address. This is much
> easier than setting the SAD for one connection over and over.
> self.con_00 = gpib.dev( board, pad, 0x60 + 0x00, gpib.T1s,   0) # Receive
> Data
> ...
> self.con_1F = gpib.dev( board, pad, 0x60 + 0x1F, gpib.T1s, self.EOT,    0)
> # Write/Read Loopback # 10011
> ----
>
> I can remember that I had to try a lot back and forth before I got the 1F
> connection working. But to be honest, I do not know exactly why EOS has to
> be disabled there.
>
>> I also found it a little confusing that linux-gpib referrs to EOI as EOT
>> and initially wondered what this EOT parameter was, ...
> Not only linux-gpib :)
>
> GPIB Read and Write Termination Methods (END and EOS)
> https://www.ni.com/docs/de-DE/bundle/ni-gpib-serial-converter/page/nigpibserialconverter/gpibreadandwriteterminationmethodsendandeossmode.html
>
> NI GPIB-Serial Converter Help
> https://www.ni.com/docs/de-DE/bundle/ni-gpib-serial-converter/page/nigpibserialconverter/eot.html
>
> Christian
>
>

Re: [Linux-gpib-general] Working with secondary addresses

[John <su...@qc...>]

Thank you  for the feedback and sorry, yes, I forgot to attach the 
latest versions of the code, which I have now done.

The FIND statements were originally different as I just copied examples 
without a full understanding of the parameters. In the current versions 
of the scripts they are now equivalent:

cmd_find = gpib.dev( 0, paddr, 0x7B, gpib.T10s, eot, 0 )

my $dev_find = LinuxGpib::ibdev(0, 5, 0x7B, 12, 1, 0);

I originally just removed the 0x0D as it was just omitted in some 
examples, but have now added a '0' for consistency. It makes no 
difference. It is unclear to me as to whether it needs a zero in there 
or not?

I also found it a little confusing that linux-gpib referrs to EOI as EOT 
and initially wondered what this EOT parameter was, but having sorted 
that out, the variable 'eot' is set to 1 at the beginning of the Python 
script. The Tektronix 405x usually signals EOI at the end of 
transmission so an EOI signal would be expected.


On 30/03/2026 22:43, Christian Grosz wrote:
> Hi John,
>
> I do not know if I see the latest version of your code. But I noticed a
> differenent EOS between perl and python.
>
> my $dev_find = LinuxGpib::ibdev(0, 5, 0x7B, 12, 1, 0);
>
> cmd_find =  gpib.dev( 0, paddr, 0x7B, gpib.T10s, eot, 0x0D )
>
>
> Christian
>

Re: [Linux-gpib-general] Working with secondary addresses

[John <su...@qc...>]

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 <su...@qc...> 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 <su...@qc...> 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.
>>
>>

[Linux-gpib-general] [PATCH] Modernize language/python/srq*

[Matthias G. <m_g...@wi...>]

Hi,

attached is a patch that modernizes the examples under language/python. 
Nothing was changed code-wise except to add a function
definition for the last few lines. Apart from that I mostly intended the 
code and formatted it, and fixed the print( statements for python3.

-- 
Freundliche Grüsse / Best regards

Matthias Geiger
__________________________________________________________________
Matthias Geiger
Werkstudent
Forschung & Entwicklung/Research & Development

Phone : +49-6441-609-3004
Email : m_g...@wi...
URL   : www.wiwa.de

WIWA Wilhelm Wagner GmbH & Co. KG
Gewerbestrasse 1-3, 35633 Lahnau, Germany
Besucheranschrift/visitor address:
Georg-Ohm-Strasse 12, 35633 Lahnau, Germany

AG WETZLAR HRA 3223, Komplementär : Wagner GmbH (AG Wetzlar HRB 363)
UST-ID Nr: / VAT-No: DE113745802
Geschäftsführer: Dipl.-Ing. (FH) Peter Turczak, Dipl.-Wirt.-Ing. Malte Weber

Re: [Linux-gpib-general] [PATCH] Fix stylesheet paths and use osx instead of osgml2xml

[Matthias G. <m_g...@wi...>]

Am 13.03.26 um 22:27 schrieb Michael Katzmann:
> Hi Dave & Matthias,
>    The deleted lines will cause a problem with EPEL-10, which uses 
> these paths.
> Rather than deleting, I suggest making the necessary files for Debian 
> another option.
>
> cheers,
>   Michael
>
> --- a/configure.ac <http://configure.ac> 2026-03-13 16:33:01.931313665 
> -0400
> +++ b/configure.ac <http://configure.ac> 2026-03-13 17:23:07.968936586 
> -0400
> @@ -82,13 +82,12 @@
>   BUILD_HTML="no"
>  fi
>  # look for manpage xsl file in various locations
> -AC_CHECK_FILE(/usr/share/sgml/docbook/xsl-ns-stylesheets/manpages/docbook.xsl, 
> AC_SUBST([DOCBOOK_XSL],
> -  ["/usr/share/sgml/docbook/xsl-ns-stylesheets/manpages/docbook.xsl"]))
> -AC_CHECK_FILE(/usr/share/sgml/docbook/xsl-stylesheets/manpages/docbook.xsl, 
> AC_SUBST([DOCBOOK_XSL],
> -  ["/usr/share/sgml/docbook/xsl-stylesheets/manpages/docbook.xsl"]))
> -AC_CHECK_FILE(/usr/share/xml/docbook/xsl-stylesheets-1.79.2/manpages/docbook.xsl, 
> AC_SUBST([DOCBOOK_XSL],
> - 
>  ["/usr/share/xml/docbook/xsl-stylesheets-1.79.2/manpages/docbook.xsl"]))
> -AC_PATH_PROGS([SGML2XML_PATH], [sgml2xml osgml2xml], [no])
> +for DOCBOOKPATH in sgml/docbook/xsl-ns-stylesheets 
> xml/docbook/xsl-stylesheets-1.79.2 
> xml/docbook/stylesheet/docbook-xsl-ns; do
> +  AC_CHECK_FILE(/usr/share/${DOCBOOKPATH}/manpages/docbook.xsl, 
> AC_SUBST([DOCBOOK_XSL],
> +  ["/usr/share/${DOCBOOKPATH}/manpages/docbook.xsl"]))
> +done
> +AC_PATH_PROGS([SGML2XML_PATH], [sgml2xml osgml2xml osx], [no])
> +
>  AC_PATH_PROG([XSLTPROC_PATH], [xsltproc], [no])
>  if test "$SGML2XML_PATH" = "no" || test "$XSLTPROC_PATH" = "no" || 
> test -z $DOCBOOK_XSL ; then
>   AC_MSG_NOTICE([sgml-man tools  not found, disabling building man pages])
>
>
>
Hi Dave and Micheal,

this change looks sensible to me. This will also work for Debian, no 
objections from my end.

-- 
Freundliche Grüsse / Best regards

Matthias Geiger
__________________________________________________________________
Matthias Geiger
Werkstudent
Forschung & Entwicklung/Research & Development

Phone : +49-6441-609-3004
Email : m_g...@wi...
URL   : www.wiwa.de

WIWA Wilhelm Wagner GmbH & Co. KG
Gewerbestrasse 1-3, 35633 Lahnau, Germany
Besucheranschrift/visitor address:
Georg-Ohm-Strasse 12, 35633 Lahnau, Germany

AG WETZLAR HRA 3223, Komplementär : Wagner GmbH (AG Wetzlar HRB 363)
UST-ID Nr: / VAT-No: DE113745802
Geschäftsführer: Dipl.-Ing. (FH) Peter Turczak, Dipl.-Wirt.-Ing. Malte Weber

Re: [Linux-gpib-general] Working with secondary addresses

[dave p. <dpe...@gm...>]

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 <su...@qc...> 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 <su...@qc...> 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.
>>
>>
>>

Re: [Linux-gpib-general] Working with secondary addresses

[John <su...@qc...>]

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 <su...@qc...> 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.
>
>

Re: [Linux-gpib-general] Working with secondary addresses

[dave p. <dpe...@gm...>]

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 <su...@qc...> 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.
>
>
>

Re: [Linux-gpib-general] Working with secondary addresses

[John <su...@qc...>]

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.



On 26/03/2026 11:05, dave penkler wrote:
> Hi John,
> The python bindings are fine.
> "but there are no listeners currently addressed." means that when the 
> addressing commands are sent there is no response on the bus.
> In detail: no device has asserted one of NDAC and NRFD
> So it looks like the device at pad 5 does not recognise sad 0x73
> Looking at the perl code you are using sad 0x7B
> Could that be the issue ?
> cheers,
> -Dave
>
> On Wed, 25 Mar 2026 at 22:02, dave penkler <dpe...@gm...> wrote:
>
>     OK,
>     I'll look into it.
>
>
>     On Wed, 25 Mar 2026 at 16:35, John via Linux-gpib-general
>     <lin...@li...> wrote:
>
>
>         1) Not plugged into the bus
>
>         The device is plugged in and the Perl script works so its not
>         connectivity.
>
>         2) Not powered on
>
>         Again, the Perl script works on the same device.
>
>         3) Device is hung
>
>         There is no change after power cycling the device and computer.
>
>         I am fairly certain its a software issue, but would need to
>         dig into the library code and maybe attach a logic analyser to
>         understand what's happening behind the scenes so to speak.
>
>         What does it mean by "but there are no listeners currently
>         addressed." ?
>         The gpib.dev <http://gpib.dev>() addressing command is
>         presumably opening a listen or talk communication handle?
>
>         Could be an issue with how the device is responding I suppose,
>         but why would Perl work and Python not when its supposedly
>         doing the same thing?
>
>         I do at least have the option to run with Perl for now, but it
>         would be nice to have Python.
>
>         _______________________________________________
>         Linux-gpib-general mailing list
>         Lin...@li...
>         https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general

Re: [Linux-gpib-general] Working with secondary addresses

[dave p. <dpe...@gm...>]

Hi John,
The python bindings are fine.
"but there are no listeners currently addressed." means that when the
addressing commands are sent there is no response on the bus.
In detail: no device has asserted one of NDAC and NRFD
So it looks like the device at pad 5 does not recognise sad 0x73
Looking at the perl code you are using sad 0x7B
Could that be the issue ?
cheers,
-Dave

On Wed, 25 Mar 2026 at 22:02, dave penkler <dpe...@gm...> wrote:

> OK,
> I'll look into it.
>
>
> On Wed, 25 Mar 2026 at 16:35, John via Linux-gpib-general <
> lin...@li...> wrote:
>
>>
>> 1) Not plugged into the bus
>>
>> The device is plugged in and the Perl script works so its not
>> connectivity.
>>
>> 2) Not powered on
>>
>> Again, the Perl script works on the same device.
>>
>> 3) Device is hung
>>
>> There is no change after power cycling the device and computer.
>>
>> I am fairly certain its a software issue, but would need to dig into the
>> library code and maybe attach a logic analyser to understand what's
>> happening behind the scenes so to speak.
>>
>> What does it mean by "but there are no listeners currently addressed." ?
>> The gpib.dev() addressing command is presumably opening a listen or talk
>> communication handle?
>>
>> Could be an issue with how the device is responding I suppose, but why
>> would Perl work and Python not when its supposedly doing the same thing?
>>
>> I do at least have the option to run with Perl for now, but it would be
>> nice to have Python.
>>
>> _______________________________________________
>> Linux-gpib-general mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>
>

Re: [Linux-gpib-general] Working with secondary addresses

[dave p. <dpe...@gm...>]

OK,
I'll look into it.


On Wed, 25 Mar 2026 at 16:35, John via Linux-gpib-general <
lin...@li...> wrote:

>
> On 25/03/2026 10:28, dave penkler wrote:
>
>
>
> On Wed, 25 Mar 2026 at 01:12, John <su...@qc...> wrote:
>
>>
>> I get the following error:
>>
>> $ ./test_storage.py
>> Traceback (most recent call last):
>>   File "/home/johnc/Test/linux-gpib/./test_storage.py", line 27, in
>> <module>
>>     gpib.write(cmd_find, b'\x31\x0D')
>>     ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
>> gpib.GpibError: write() failed: You have attempted to write data or
>> command bytes, but there are no listeners currently addressed.
>>
>> The script uses the same technique that worked in Perl so not sure what I
>> am doing wrong at this point:
>>
>
> Your code looks fine. This is not a python issue, it is hardware related.
> The problem with the device you are talking to is in one or more of:
> 1) Not plugged into the bus
> 2) Not powered on
> 3) Device is hung
> cheers,
> -Dave
>
>
> _______________________________________________
> Linux-gpib-general mailing lis...@li...://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>
>
> 1) Not plugged into the bus
>
> The device is plugged in and the Perl script works so its not connectivity.
>
> 2) Not powered on
>
> Again, the Perl script works on the same device.
>
> 3) Device is hung
>
> There is no change after power cycling the device and computer.
>
> I am fairly certain its a software issue, but would need to dig into the
> library code and maybe attach a logic analyser to understand what's
> happening behind the scenes so to speak.
>
> What does it mean by "but there are no listeners currently addressed." ?
> The gpib.dev() addressing command is presumably opening a listen or talk
> communication handle?
>
> Could be an issue with how the device is responding I suppose, but why
> would Perl work and Python not when its supposedly doing the same thing?
>
> I do at least have the option to run with Perl for now, but it would be
> nice to have Python.
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

Re: [Linux-gpib-general] Working with secondary addresses

[John <si...@gm...>]

On 25/03/2026 10:28, dave penkler wrote:
>
>
> On Wed, 25 Mar 2026 at 01:12, John <su...@qc...> wrote:
>
>
>     I get the following error:
>
>     $ ./test_storage.py
>     Traceback (most recent call last):
>       File "/home/johnc/Test/linux-gpib/./test_storage.py", line 27,
>     in <module>
>         gpib.write(cmd_find, b'\x31\x0D')
>         ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
>     gpib.GpibError: write() failed: You have attempted to write data
>     or command bytes, but there are no listeners currently addressed.
>
>     The script uses the same technique that worked in Perl so not sure
>     what I am doing wrong at this point:
>
>
> Your code looks fine. This is not a python issue, it is hardware 
> related. The problem with the device you are talking to is in one or 
> more of:
> 1) Not plugged into the bus
> 2) Not powered on
> 3) Device is hung
> cheers,
> -Dave
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general


1) Not plugged into the bus

The device is plugged in and the Perl script works so its not connectivity.

2) Not powered on

Again, the Perl script works on the same device.

3) Device is hung

There is no change after power cycling the device and computer.

I am fairly certain its a software issue, but would need to dig into the 
library code and maybe attach a logic analyser to understand what's 
happening behind the scenes so to speak.

What does it mean by "but there are no listeners currently addressed." ?
The gpib.dev() addressing command is presumably opening a listen or talk 
communication handle?

Could be an issue with how the device is responding I suppose, but why 
would Perl work and Python not when its supposedly doing the same thing?

I do at least have the option to run with Perl for now, but it would be 
nice to have Python.

Re: [Linux-gpib-general] Working with secondary addresses

[dave p. <dpe...@gm...>]

On Wed, 25 Mar 2026 at 01:12, John <su...@qc...> wrote:

>
> I get the following error:
>
> $ ./test_storage.py
> Traceback (most recent call last):
>   File "/home/johnc/Test/linux-gpib/./test_storage.py", line 27, in
> <module>
>     gpib.write(cmd_find, b'\x31\x0D')
>     ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
> gpib.GpibError: write() failed: You have attempted to write data or
> command bytes, but there are no listeners currently addressed.
>
> The script uses the same technique that worked in Perl so not sure what I
> am doing wrong at this point:
>

Your code looks fine. This is not a python issue, it is hardware related.
The problem with the device you are talking to is in one or more of:
1) Not plugged into the bus
2) Not powered on
3) Device is hung
cheers,
-Dave

Re: [Linux-gpib-general] Working with secondary addresses

[John <su...@qc...>]

Dave,

Thank you, this worked perfectly fine in Perl. I did have to remove the 
hex() function and just use the literal 0x73 etc, but the principle of 
setting up a handle for each secondary command was the solution.

Unfortunately I have not been able to do the same thing in Python yet.

I get the following error:

$ ./test_storage.py
Traceback (most recent call last):
   File "/home/johnc/Test/linux-gpib/./test_storage.py", line 27, in 
<module>
     gpib.write(cmd_find, b'\x31\x0D')
     ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
gpib.GpibError: write() failed: You have attempted to write data or 
command bytes, but there are no listeners currently addressed.

The script uses the same technique that worked in Perl so not sure what 
I am doing wrong at this point:


#!/usr/bin/python3

import gpib
import time

# GPIB interface 0, address 5
con = None
paddr = 5
eot = 1


# GPIB interface 0, address 5 - section added to establish the initial 
connection
try:
     con = gpib.dev(0,5)
except gpib.GpibError as e:
     print(e)
     exit()
# GPIB interface 0, address 5 - section added to establish the initial 
connection


cmd_find =  gpib.dev( 0, paddr, 0x73, gpib.T10s, eot, 0 )
cmd_input =  gpib.dev( 0, paddr, 0x6D, gpib.T10s, eot, 0x0D )
cmd_type =  gpib.dev( 0, paddr, 0x66, gpib.T10s, eot, 0x0D )


# FIND file
gpib.write(cmd_find, b'\x31\x0D')

#INPUT first line
line = gpib.read(cmd_input, 100).decode()

print(line)


# Close down
gpib.close(cmd_find)
gpib.close(cmd_input)
gpib.close(cmd_type)



On 24/03/2026 16:11, dave penkler wrote:
> Hi John,
> ibsad() does not send the secondary address but does configure it on 
> the device descriptor for
> use in subsequent ibrd()  ibwrt() calls.
> Your code looks good BTW.
> I'm not familiar with Perl but you might try the following to avoid 
> potential issues with gpib.conf:
> use LinuxGpib;
> $result = "";
> # setup write descriptor minor 0, pad 5, sad 27, timeout 3 secs, 
> assert eoi, no eos
> my $devw = LinuxGpib::ibdev(0, 5, hex(0x7B), 12, 1, 0);
> # setup read descriptor minor 0, pad 5, sad 13, timeout 3 secs, assert 
> eoi, eos = cr
> my $devr = LinuxGpib::ibdev(0, 5, hex(0x6D), 12, 1, 13);
> LinuxGpib::ibwrt($devw,"1\r",2);
> sleep 1;
> LinuxGpib::ibrd($devr,$result,100);
> print $result;
> print "\n";
>
> cheers,
> -Dave
> ...
>
> On Tue, 24 Mar 2026 at 16:02, John <su...@qc...> wrote:
>
>     I am trying to work with secondary addresses on a storage device
>     using
>     linux-gpib. For example, I would like to read a file. The device
>     emulates a Tektronix 4924 tape drive and is on primary GPIB
>     address 5.
>     Normally, on a Tektronix 4051 computer I would run a find command
>     followed by an input command, for example:
>
>     FIND@5:1
>
>     INPUT@5:A$
>
>     This would send a '1' to SAD 0x7B followed by SAD 0x6E to prompt the
>     device to send data.
>
>     For a text file, this should read the first line of data up to a CR
>     terminator.
>
>     I initially tried doing this with Python, but quickly found that
>     the ib*
>     commands in the reference do not correlate to the Python gpib module,
>     and that the pythin gpib module does not have methods for writing
>     to or
>     reading from secondary addresses.
>
>     I then looked at Perl. This was far more promising, as the ib*
>     commands
>     in the reference do have a direct correlation to LinuxGpib::ib*
>     functions, but I could still get no output.
>
>     This is my current Perl script. What is not clear to me is whether
>     ibsad() actually sends the secondary address?
>
>     Perhaps someone can tell me whether I am going the right way about
>     this?
>
>
>     #!/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 <http://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 = "";
>
>     my $dev = LinuxGpib::ibfind($device) ||
>          die "Can't open device $device!\n";
>
>     print "FIND file .....\n";
>     LinuxGpib::ibsad($dev, hex(0x7B));
>     LinuxGpib::ibwrt($dev,"1\r",2);
>     sleep 1;
>
>     print "INPUT first line from file .....\n";
>     LinuxGpib::ibsad($dev, hex(0x6D));
>     LinuxGpib::ibrd($dev,$result,100);
>     print $result;
>     print "\n";
>
>     print "Done.\n";
>
>
>     # clear
>     LinuxGpib::ibclr($dev);
>     exit 0;
>
>
>
>
>     _______________________________________________
>     Linux-gpib-general mailing list
>     Lin...@li...
>     https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>
-- 
John.

Re: [Linux-gpib-general] Working with secondary addresses

[Christian G. <boe...@ce...>]

Hi John,

>
> I initially tried doing this with Python, but quickly found that the ib*
> commands in the reference do not correlate to the Python gpib module, and
> that the pythin gpib module does not have methods for writing to or
> reading from secondary addresses.
>

I wrote some Python code which is doing a very similar thing,  talking to
HP disk drives over GPIB.

https://codeberg.org/Boeingflieger/lif80utils

In particular, the code within the lif80utils/src/lif80utils/amigo.py file
should be helpful.

What I'm doing there is opening a separate connection for each secondary
address. This is working like a charm and much easier than setting the SAD
for one connection over and over.

Regards

Christian

Re: [Linux-gpib-general] Working with secondary addresses

[dave p. <dpe...@gm...>]

>
>> I initially tried doing this with Python, but quickly found that the ib*
>> commands in the reference do not correlate to the Python gpib module,
>> and that the pythin gpib module does not have methods for writing to or
>> reading from secondary addresses.
>
>
Just checked the python extension and you can use (ib)dev in the same way
as perl.
import sys
sys.path.append('/usr/local/lib64/python3.9/site-packages') # or wherever
they are
import gpib
devw=gpib.dev(0, 5, 0x7B, 12, 1, 0)
devr=gpib.dev(0, 5, 0x6D, 12, 1, 0)
gpib.write(devw,"1\r")
result=gpib.read(devr, 100)
print result
print "\n"

Re: [Linux-gpib-general] Working with secondary addresses

[dave p. <dpe...@gm...>]

Hi John,
ibsad() does not send the secondary address but does configure it on the
device descriptor for
use in subsequent ibrd()  ibwrt() calls.
Your code looks good BTW.
I'm not familiar with Perl but you might try the following to avoid
potential issues with gpib.conf:
use LinuxGpib;
$result = "";
# setup write descriptor minor 0, pad 5, sad 27, timeout 3 secs, assert
eoi, no eos
my $devw = LinuxGpib::ibdev(0, 5, hex(0x7B), 12, 1, 0);
# setup read descriptor minor 0, pad 5, sad 13, timeout 3 secs, assert eoi,
eos = cr
my $devr = LinuxGpib::ibdev(0, 5, hex(0x6D), 12, 1, 13);
LinuxGpib::ibwrt($devw,"1\r",2);
sleep 1;
LinuxGpib::ibrd($devr,$result,100);
print $result;
print "\n";

cheers,
-Dave
...

On Tue, 24 Mar 2026 at 16:02, John <su...@qc...> wrote:

> I am trying to work with secondary addresses on a storage device using
> linux-gpib. For example, I would like to read a file. The device
> emulates a Tektronix 4924 tape drive and is on primary GPIB address 5.
> Normally, on a Tektronix 4051 computer I would run a find command
> followed by an input command, for example:
>
> FIND@5:1
>
> INPUT@5:A$
>
> This would send a '1' to SAD 0x7B followed by SAD 0x6E to prompt the
> device to send data.
>
> For a text file, this should read the first line of data up to a CR
> terminator.
>
> I initially tried doing this with Python, but quickly found that the ib*
> commands in the reference do not correlate to the Python gpib module,
> and that the pythin gpib module does not have methods for writing to or
> reading from secondary addresses.
>
> I then looked at Perl. This was far more promising, as the ib* commands
> in the reference do have a direct correlation to LinuxGpib::ib*
> functions, but I could still get no output.
>
> This is my current Perl script. What is not clear to me is whether
> ibsad() actually sends the secondary address?
>
> Perhaps someone can tell me whether I am going the right way about this?
>
>
> #!/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 = "";
>
> my $dev = LinuxGpib::ibfind($device) ||
>      die "Can't open device $device!\n";
>
> print "FIND file .....\n";
> LinuxGpib::ibsad($dev, hex(0x7B));
> LinuxGpib::ibwrt($dev,"1\r",2);
> sleep 1;
>
> print "INPUT first line from file .....\n";
> LinuxGpib::ibsad($dev, hex(0x6D));
> LinuxGpib::ibrd($dev,$result,100);
> print $result;
> print "\n";
>
> print "Done.\n";
>
>
> # clear
> LinuxGpib::ibclr($dev);
> exit 0;
>
>
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>