Cannot read status byte, assert trigger, or perform device clear

[caiser01]

When I try to either read the status byte of instrument or send a measurement trigger using the appropriate VISA functions, I get errors from the VISA library that seem to indicate reading the status byte or sending a trigger are unsupported. But looking at the source code for the adapter, it looks like these functions are implemented.

I have tried this with multiple instruments, VISA libraries, and operating systems. Here are some examples:

Windows 10 machine #1 running latest Rohde & Schwarz VISA

Windows 10 machine #2 running latest Keysight IO VISA

RaspiOS Buster running pyvisa with pyvisa-py

If I'm running pyvisa, should I not be able to read status byte using read_stb() or send a trigger with assert_trigger()? Similarly, shouldn't the built-in test programs for R&S or Keysight VISA also be able to do this?

Or am I doing something wrong?

Thanks for looking!

[caiser01]

I've discovered that device clear does not seem to work either. Although it does not return any VISA errors, executing a device clear from VISA does not seem to anything. I found this out when try to clear an error message from my HP 5385A frequency counter. You should be able to do this with device clear but instead nothing happens, and the error message remains on the instrument remains until you manually press the reset button on the front panel. This is particularly troublesome on the HP 5385A as it will not accept any GPIB commands if an error message is present.

[xyphro]

Hi!

ReadSTB is reported already to be not working. I wanted to have that fixed already long time ago, but could not find time. However: I just got my build system finally working again and will work on it.

The device clear is not implemented. Will do this as part of this fixing.

Best regards,

Kai

[dazz100]

Hi I'd just like to say thank you for releasing this project to open source, and thank you again for continuing to support and improve the project.

[caiser01]

Yes, indeed. Thank you for your response and continued work on this project.

Getting Read STB, Trigger, and Device Clear working would be useful for many instruments. I have multiple instruments I can use to test these functions so I'd be happy to help in that regard when the time comes.

Thanks again!

[xyphro]

Hi Caiser01,

I am busy experimenting - coding & fixing.

Read status byte works for me in general, but there is a race condition. E.g doing a long read and then read stb fails and the reason is known to me and will get addressed.

I wonder why it does not work at all for you.

Does your instrument support the STB? Query? Could you try that one out?

More updates later today :-)

Best regards,

Kai

[xyphro]

Hmm, trigger works like charm here using pyvisas assert_trigger function on a HP3457a multimeter. Every time I trigger it does sample a new value.

Clear is indeed not sending an SDC to the instrument. I fixed that already.

Question: can I mail you a hex and you try it again with that one?

Is is possible that you maybe don't have the latest firmware in use? Anyway, if I send you a .hex that is also fixed.

My email address: Xyphro@gmail.com

[xyphro]

Wait, let's don't overcomplicate - I attached an updated .hex file. Can you try this image? TestAndMeasurement_fixed_clear.zip

Expectation is: read status byte works clear works trigger works.

Limitation: read status byte race condition is not fixed (an issue from an earlier issure report - I continue fixing it), however in the way you test it, it should not matter.

Crossing fingers - hoping for positive news :-) EDIT: updated the .zip to include also the .bin file.

[xyphro]

And here a short video of my testing: https://youtu.be/Wb4bvuhdoK0

[caiser01]

Hello Kai,

I flashed the updated hex file you provided. My results are mixed.

I tested with my HP 3478A multimeter, which I know functions correctly when reading the status byte, triggering, or sending device clear using other GPIB adapters.

On a Windows 10 machine with Rohde & Schwarz VISA installed: -Simple functions (read, write, etc) work as expected -Send device clear is now working as expected; the meter resets as it would at power up -Attempting to read the status byte or assert trigger fails with a VISA error message about invalid setup

On a Raspberry Pi with the open source pyvisa-py VISA backend installed: -Simple functions (read, write, etc) work as expected -Device clear, read status byte, and assert trigger all fail with VISA errors indicating not supported or not implemented

I don't know enough about how USBTMC and VISA work together to understand why the behavior would be different with different VISA libraries but maybe different vendor's VISA interprets the capabilities of the adapter differently?

Here is my demonstration video: https://www.youtube.com/watch?v=xesP5ex2vMw Sorry for the clumsy, one-handed typing ;-)

Thanks!

[xyphro]

Chris -

Let me test on a raspberry too!

Best regards,

Kai

[xyphro]

I wonder.... maybe I need to send a bulk message back when a trigger was received. Not doing this right now. You used R&S visa (no clue why I am with NI visa right now). Will try the same.

[xyphro]

I now managed to look at the video. Thanks a lot, this is very useful. I am busy flashing a fresh SD card now for my RP 400 and will report out again once it I tested it on it.

[xyphro]

While the RP400 is flashing I tried R&S Visa.

behavior: read status byte: does NOT work trigger: does NOT work clear: works.

I clearly need to do more.

Thanks a lot for reporting and patience :-)

[caiser01]

I don't think I did anything too special when I set up my RPi. I think just:

pip install pyvisa pyvisa-py pyusb

I don't recall having to do anything special to get libusb.

Here's the output of pyvisa-info on my RPi running Bullseye:

Machine Details:
   Platform ID:    Linux-6.1.21-v8+-aarch64-with-glibc2.31
   Processor:      

Python:
   Implementation: CPython
   Executable:     /usr/bin/python3
   Version:        3.9.2
   Compiler:       GCC 10.2.1 20210110
   Bits:           64bit
   Build:          Feb 28 2021 17:03:44 (#default)
   Unicode:        UCS4

PyVISA Version: 1.11.3

Backends:
   ivi:
      Version: 1.11.3 (bundled with PyVISA)
      Binary library: Not found
   py:
      Version: 0.5.1
      ASRL INSTR: Available via PySerial (3.5b0)
      USB INSTR: Available via PyUSB (1.2.1). Backend: libusb1
      USB RAW: Available via PyUSB (1.2.1). Backend: libusb1
      TCPIP INSTR: Available 
      TCPIP SOCKET: Available 
      GPIB INSTR:
         Please install linux-gpib (Linux) or gpib-ctypes (Windows, Linux) to use this resource type. Note that installing gpib-ctypes will give you access to a broader range of funcionality.
         No module named 'gpib'

[caiser01]

While the RP400 is flashing I tried R&S Visa.

behavior: read status byte: does NOT work trigger: does NOT work clear: works.

I clearly need to do more.

Thanks a lot for reporting and patience :-)

Glad you could replicate it. Maybe it's not just me!

[xyphro]

It's clearly not "just you" :-) The fact that different visa implementations behave different annoys me. This is a new learning!

[xyphro]

Short update: Debugged R&S Visa. I see that when read_stb() and assert_trigger() do not generate any USB transactions by the PC. This means likely, that something in the TMC_capabilities structure is inconsistent and not ok.

[caiser01]

If I run pyvisa-shell, open the instrument, and then run the 'attr' command to get the VISA attributes table, both R&S VISA on Win10 and pyvisa-py on the RPi seem to indicate that VI_ATTR_4882_COMPLIANT is false or unsupported.

Maybe this means something?

Win10 with R&S VISA:

+---------------------------+------------+----------------------------+------------------------------------------+
|         VISA name         |  Constant  |        Python name         |                   val                    |
+---------------------------+------------+----------------------------+------------------------------------------+
|   VI_ATTR_4882_COMPLIANT  | 1073676703 |     is_4882_compliant      |                    0                     |
|    VI_ATTR_DMA_ALLOW_EN   | 1073676318 |         allow_dma          |                    0                     |
|   VI_ATTR_FILE_APPEND_EN  | 1073676690 |                            |                    0                     |
|   VI_ATTR_INTF_INST_NAME  | 3221160169 |                            |            USB0 (USBTMC_base)            |
|      VI_ATTR_INTF_NUM     | 1073676662 |      interface_number      |                    0                     |
|     VI_ATTR_INTF_TYPE     | 1073676657 |       interface_type       |                    7                     |
|      VI_ATTR_IO_PROT      | 1073676316 |        io_protocol         |                    1                     |
|      VI_ATTR_MANF_ID      | 1073676505 |      manufacturer_id       |                   1003                   |
|     VI_ATTR_MANF_NAME     | 3221160050 |     manufacturer_name      |                XyphroLabs                |
|  VI_ATTR_MAX_QUEUE_LENGTH | 1073676293 |                            |                    50                    |
|     VI_ATTR_MODEL_CODE    | 1073676511 |         model_code         |                   8293                   |
|     VI_ATTR_MODEL_NAME    | 3221160055 |         model_name         |                 GpibUsb                  |
|  VI_ATTR_RD_BUF_OPER_MODE | 1073676330 |                            |                    3                     |
|    VI_ATTR_RD_BUF_SIZE    | 1073676331 |                            |                   4096                   |
|     VI_ATTR_RM_SESSION    | 1073676484 |                            |                    1                     |
|     VI_ATTR_RSRC_CLASS    | 3221159937 |       resource_class       |                  INSTR                   |
| VI_ATTR_RSRC_IMPL_VERSION | 1073676291 |   implementation_version   |                 5245962                  |
|  VI_ATTR_RSRC_LOCK_STATE  | 1073676292 |         lock_state         |                    0                     |
|    VI_ATTR_RSRC_MANF_ID   | 1073676661 |                            |                   4015                   |
|   VI_ATTR_RSRC_MANF_NAME  | 3221160308 | resource_manufacturer_name |           Rohde & Schwarz GmbH           |
|     VI_ATTR_RSRC_NAME     | 3221159938 |       resource_name        | USB0::0x03EB::0x2065::HP5.0361E+0::INSTR |
| VI_ATTR_RSRC_SPEC_VERSION | 1073676656 |        spec_version        |                 5244928                  |
|    VI_ATTR_SEND_END_EN    | 1073676310 |          send_end          |                    1                     |
|  VI_ATTR_SUPPRESS_END_EN  | 1073676342 |                            |                    0                     |
|      VI_ATTR_TERMCHAR     | 1073676312 |                            |                    10                    |
|    VI_ATTR_TERMCHAR_EN    | 1073676344 |                            |                    0                     |
|     VI_ATTR_TMO_VALUE     | 1073676314 |          timeout           |                   2000                   |
|   VI_ATTR_USB_INTFC_NUM   | 1073676705 |      interface_number      |                    0                     |
| VI_ATTR_USB_MAX_INTR_SIZE | 1073676719 |   maximum_interrupt_size   |                    2                     |
|    VI_ATTR_USB_PROTOCOL   | 1073676711 |        usb_protocol        |                    1                     |
|   VI_ATTR_USB_SERIAL_NUM  | 3221160352 |       serial_number        |               HP5.0361E+0                |
|     VI_ATTR_USER_DATA     | 1073676298 |                            |                    0                     |
|  VI_ATTR_WR_BUF_OPER_MODE | 1073676333 |                            |                    2                     |
|    VI_ATTR_WR_BUF_SIZE    | 1073676334 |                            |                   4096                   |
+---------------------------+------------+----------------------------+------------------------------------------+

RPi with pyvisa-py:

+---------------------------+------------+----------------------------+-----------------------------------------+
|         VISA name         |  Constant  |        Python name         |                   val                   |
+---------------------------+------------+----------------------------+-----------------------------------------+
|   VI_ATTR_4882_COMPLIANT  | 1073676703 |     is_4882_compliant      |            VI_ERROR_NSUP_ATTR           |
|    VI_ATTR_DMA_ALLOW_EN   | 1073676318 |         allow_dma          |            VI_ERROR_NSUP_ATTR           |
|   VI_ATTR_FILE_APPEND_EN  | 1073676690 |                            |            VI_ERROR_NSUP_ATTR           |
|   VI_ATTR_INTF_INST_NAME  | 3221160169 |                            |            VI_ERROR_NSUP_ATTR           |
|      VI_ATTR_INTF_NUM     | 1073676662 |      interface_number      |            VI_ERROR_NSUP_ATTR           |
|     VI_ATTR_INTF_TYPE     | 1073676657 |       interface_type       |            InterfaceType.usb            |
|      VI_ATTR_IO_PROT      | 1073676316 |        io_protocol         |            VI_ERROR_NSUP_ATTR           |
|      VI_ATTR_MANF_ID      | 1073676505 |      manufacturer_id       |            VI_ERROR_NSUP_ATTR           |
|     VI_ATTR_MANF_NAME     | 3221160050 |     manufacturer_name      |            VI_ERROR_NSUP_ATTR           |
|  VI_ATTR_MAX_QUEUE_LENGTH | 1073676293 |                            |            VI_ERROR_NSUP_ATTR           |
|     VI_ATTR_MODEL_CODE    | 1073676511 |         model_code         |            VI_ERROR_NSUP_ATTR           |
|     VI_ATTR_MODEL_NAME    | 3221160055 |         model_name         |            VI_ERROR_NSUP_ATTR           |
|  VI_ATTR_RD_BUF_OPER_MODE | 1073676330 |                            |            VI_ERROR_NSUP_ATTR           |
|    VI_ATTR_RD_BUF_SIZE    | 1073676331 |                            |            VI_ERROR_NSUP_ATTR           |
|     VI_ATTR_RSRC_CLASS    | 3221159937 |       resource_class       |                  INSTR                  |
| VI_ATTR_RSRC_IMPL_VERSION | 1073676291 |   implementation_version   |            VI_ERROR_NSUP_ATTR           |
|  VI_ATTR_RSRC_LOCK_STATE  | 1073676292 |         lock_state         |            VI_ERROR_NSUP_ATTR           |
|    VI_ATTR_RSRC_MANF_ID   | 1073676661 |                            |            VI_ERROR_NSUP_ATTR           |
|   VI_ATTR_RSRC_MANF_NAME  | 3221160308 | resource_manufacturer_name |            VI_ERROR_NSUP_ATTR           |
|     VI_ATTR_RSRC_NAME     | 3221159938 |       resource_name        | USB0::1003::8293::HP5.0361E+0::0::INSTR |
| VI_ATTR_RSRC_SPEC_VERSION | 1073676656 |        spec_version        |            VI_ERROR_NSUP_ATTR           |
|    VI_ATTR_SEND_END_EN    | 1073676310 |          send_end          |                   True                  |
|  VI_ATTR_SUPPRESS_END_EN  | 1073676342 |                            |            VI_ERROR_NSUP_ATTR           |
|      VI_ATTR_TERMCHAR     | 1073676312 |                            |                    10                   |
|    VI_ATTR_TERMCHAR_EN    | 1073676344 |                            |                  False                  |
|     VI_ATTR_TMO_VALUE     | 1073676314 |          timeout           |                   2000                  |
|   VI_ATTR_USB_INTFC_NUM   | 1073676705 |      interface_number      |            VI_ERROR_NSUP_ATTR           |
| VI_ATTR_USB_MAX_INTR_SIZE | 1073676719 |   maximum_interrupt_size   |            VI_ERROR_NSUP_ATTR           |
|    VI_ATTR_USB_PROTOCOL   | 1073676711 |        usb_protocol        |            VI_ERROR_NSUP_ATTR           |
|   VI_ATTR_USB_SERIAL_NUM  | 3221160352 |       serial_number        |            VI_ERROR_NSUP_ATTR           |
|     VI_ATTR_USER_DATA     | 1073676298 |                            |            VI_ERROR_NSUP_ATTR           |
|  VI_ATTR_WR_BUF_OPER_MODE | 1073676333 |                            |            VI_ERROR_NSUP_ATTR           |
|    VI_ATTR_WR_BUF_SIZE    | 1073676334 |                            |            VI_ERROR_NSUP_ATTR           |
+---------------------------+------------+----------------------------+-----------------------------------------+

[xyphro]

Yes sir! I enabled 488.2 mode and all of the sudden it works fully with R&S Visa.

I will not manage today anymore to test on my Raspberry PI.

TestAndMeasurement_enable_488.2.zip

Please find attached a FW update. More testing is required also by me to get better confidence that it works.

[caiser01]

Okay, things are looking better!

On Win10 with R&S VISA, asserting the trigger now works. Read status byte still does not work but the VISA error message is now different. Previously, it was VI_ERROR_INV_SETUP whereas now it is VI_ERROR_NSUP_ATTR, so I think this is still progress.

Unfortunately, nothing has changed on the RPi. The attribute table is still the same as in my earlier post.

Thanks for working on this today!

[xyphro]

Thanks for testing, so we got a bit of progress. Hope we solve it today. Strange that the attribute table on the PI did not change - it gets this via the capabilities structure which I adjusted. But also this I will see after testing on the PI.

[xyphro]

Cause: 488.2 requires the status byte to be delivered via interrupt endpoint on top of beeing delivered via control transfer. The interrupt endpoint is disabled as it was a 488.1 device.

Working now on enabling the interrupt endpoint.

R&S visa is more strictly following the usbtmc class standard than NI visa it seems - which is good :-)

[xyphro]

Interim status: Readstb works now too via interrupt transfer.

R&S visa requires also SR1 feature to be enabled for readstatusbyte to work.

Note: on a 2nd PC R&S visa behaves as you reported. On my normal development machine it simply worked fine before. The 2 visas have different versions. Did not check if this is the reason.

I will now step over to PI based testing.

Will only share the firmware if you look for adventures and ask for it. Otherwise please wait for my PI testing :-)

Ps: the PI does now also not report anymore that the config descriptor is not ok .

Update: the raspberry pi with pyvisa-py is still troublesome.

[xyphro]

Update: After debugging I am 99% confident that:

1. assert_trigger is not implemented in pyvisa-py (It falls back to superclass defined in session.py where assert_trigger returns NotImplementedError)
2. Same for clear() and read_stb(). Just that another error is raised - also from superclass sessions.py

I crosschecked it with a RTM2034 scope with native usbtmc. Works fine with R&S Visa on my windows PC. With pyvisa-py on my Rasberry PI 400, I get exactly the same error codes.

I suggest, that you try with a native USBTMC device too to see if I am right.

So with this finding: I think things are as expected now (not as we'd like to have them of course).

Can you crosscheck the below firmware image on your PC with R&S Visa?

TestAndMeasurement_488.2_support_with_Interrupt_endpoint_and_fixed_descriptors.zip

PS: R&S visa is available also for the PI. Have no experience with it, but maybe worth a try.

BTW: Check the pyvisa-py's USB code here: https://github.com/pyvisa/pyvisa-py/blob/main/pyvisa_py/usb.py

This does create a class based on sessions.py and overloads functions like read and write. However, it does not overload the ones for trigger, clear and read_stb. So it uses then the ones defined in sessions.py which default wise report an error - without talking in any way to the device. With just a tiny bit of effort this functionality could be added to pyvisa-py.

[caiser01]

I've been testing this evening and it's all good news so far!

assert_trigger(), clear(), and read_stb() all seem to be working as expected under Windows 10, macOS Sonoma 14.0 (more on this below), and Raspi OS Bullseye with R&S VISA. I also checked pyvisa-py with my Rigol DS1202Z-E scope with native USB and I believe you are correct that none of those three methods are implemented in pyvisa-py. Everything worked correctly with R&S VISA. It's too bad no one has yet added that functionality to pyvisa-py but I'm happy using R&S VISA since it's very lightweight and the install is far less intrusive than NI or KeySight. Also, trying to get pyvisa-py to recognize USB instruments with PyUSB and libusb is a huge pain under any OS except Linux but works flawlessly with R&S VISA.

So far I have only tested with my HP 3478A multimeter but tomorrow I will expand to other instruments in my collection. Here is the script I have been using with my 3478A, which incorporates all three of the newly implemented functions:

# HP 3478A Multimeter read test

import pyvisa
from time import time
from time import sleep

rm = pyvisa.ResourceManager()

multimeter = rm.open_resource('USB0::0x03EB::0x2065::GPIB_23_3423331363435161F191::INSTR')

multimeter.clear()
while(multimeter.read_stb() == 0):
    pass

# Set function to DC volts, trigger to single
multimeter.write('F1T3')

trigger_timeout = 3

try:
    multimeter.assert_trigger()
    last_trigger = time()
    while True:
        if(multimeter.read_stb() < 1):
            # Check if we've passed the timeout for triggering a reading
            if(time() - last_trigger > trigger_timeout):
                # Try triggering again
                multimeter.assert_trigger()
                last_trigger = time()
        else:
            print(float(multimeter.read().strip()))
            multimeter.assert_trigger()
            last_trigger = time()
except KeyboardInterrupt:
    multimeter.clear()
    multimeter.close()
    rm.close()

If running on Raspi OS with R&S VISA, make the following change:

rm = pyvisa.ResourceManager("/usr/lib/librsvisa.so@ivi")

If running on macOS with R&S VISA, make the following change:

rm = pyvisa.ResourceManager("/Library/Frameworks/RsVisa.framework/RsVisa@ivi")

I don't know how much you changed but you managed to fix a couple of other issues I was having but had not mentioned. For one thing, when using R&S VISA on the RPi, the read() function would always time out; this is now corrected. Additionally, under macOS the UsbGpib wasn't recognized by R&S VISA at all with the old firmware; now it is recognized and all functions are working great! In fact, while running the above test script on one of my Macs, I walked away and the Mac went to sleep for an hour. I came back, woke the Mac from sleep, and the test script resumed reading the meter without any issues!!

I am eager to test with my other instruments tomorrow to see if another bad behavior I had encountered with the old firmware is magically corrected now.

Thank you for your hard work! This project just became even more useful!!

[xyphro]

Very happy to read this message in the morning :-)

Thanks a lot for extensive testing, will push the code and updated files this evening to git.

I did not use those functions myself so far, but scpi equivalents. Also had not seen any issue, allthough I use it often. Why? I only used it in my fixed cornercases which is windows with NI visa. So if I don't see it I have to get pushed by an issue report.

I want any issue to be fixed, so please continue reporting them! Just my reaction time might not always be good as this is a side project and not the main thing I do as it generates no money for living :-)

Chris Isert @.***> schrieb am Di., 17. Okt. 2023, 02:58:

I've been testing this evening and it's all good news so far!

assert_trigger(), clear(), and read_stb() all seem to be working as expected under Windows 10, macOS Sonoma 14.0 (more on this below), and Raspi OS Bullseye with R&S VISA. I also checked pyvisa-py with my Rigol DS1202Z-E scope with native USB and I believe you are correct that none of those three methods are implemented in pyvisa-py. Everything worked correctly with R&S VISA. It's too bad no one has yet added that functionality to pyvisa-py but I'm happy using R&S VISA since it's very lightweight and the install is far less intrusive than NI or KeySight. Also, trying to get pyvisa-py to recognize USB instruments with PyUSB and libusb is a huge pain under any OS except Linux but works flawlessly with R&S VISA.

So far I have only tested with my HP 3478A multimeter but tomorrow I will expand to other instruments in my collection. Here is the script I have been using with my 3478A, which incorporates all three of the newly implemented functions:

HP 3478A Multimeter read test

import pyvisa from time import time from time import sleep

rm = pyvisa.ResourceManager()

multimeter = rm.open_resource('USB0::0x03EB::0x2065::GPIB_23_3423331363435161F191::INSTR')

multimeter.clear() while(multimeter.read_stb() == 0): pass

Set function to DC volts, trigger to single

multimeter.write('F1T3')

trigger_timeout = 3

try: multimeter.assert_trigger() last_trigger = time() while True: if(multimeter.read_stb() < 1):

Check if we've passed the timeout for triggering a reading

      if(time() - last_trigger > trigger_timeout):
          # Try triggering again
          multimeter.assert_trigger()
          last_trigger = time()
  else:
      print(float(multimeter.read().strip()))
      multimeter.assert_trigger()
      last_trigger = time()

except KeyboardInterrupt: multimeter.clear() multimeter.close() rm.close()

If running on Raspi OS with R&S VISA, make the following change:

rm = @.***")

If running on macOS with R&S VISA, make the following change:

rm = @.***")

I don't know how much you changed but you managed to fix a couple of other issues I was having but had not mentioned. For one thing, when using R&S VISA on the RPi, the read() function would always time out; this is now corrected. Additionally, under macOS the UsbGpib wasn't recognized by R&S VISA at all with the old firmware; now it is recognized and all functions are working great! In fact, while running the above test script on one of my Macs, I walked away and the Mac went to sleep for an hour. I came back, woke the Mac from sleep, and the test script resumed reading the meter without any issues!!

I am eager to test with my other instruments tomorrow to see if another bad behavior I had encountered with the old firmware is magically corrected now.

Thank you for your hard work! This project just became even more useful!!

— Reply to this email directly, view it on GitHub https://github.com/xyphro/UsbGpib/issues/38#issuecomment-1765489789, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFXEGEGFBXTCHEEE6K27H3X7XJ2DAVCNFSM6AAAAAA4VD7OIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRVGQ4DSNZYHE . You are receiving this because you commented.Message ID: @.***>

[xyphro]

The update is pushed. The bin / hex matches what I shared yesterday in this PR.

[caiser01]

Thanks for the update!

After a lot of testing today, I can confirm the following instruments working and the newly implemented features (assert_trigger, clear, read_stb) are behaving as expected with each:

• HP 3478A multimeter (test script from previous post has been running 18+ hours with no errors)
• HP 5385A frequency counter
• HP 53131A universal counter
• HP 33120A function generator
• Fluke 6060B RF signal generator

Unfortunately, my HP 34401A is still having some overall issues working with UsbGpib but I am certain those are unrelated to what's been discussed here, so I will open a separate issue later for that.

Thanks again for getting these functions working!

P.S. Also, did some quick testing with KeySight VISA on Windows 10 and the new functions also seem to be working correctly with this combination.

[xyphro]

HP 34401A? I think I can test that one too. Give me a rough indication what doesn't work and I'll check. A seperate ticket is indeed good - not for me but for others that have the same problems and can find it back.

And: thanks a lot for testing!!

[xyphro]

HP 34401A? I think I can test that one too. Give me a rough indication what doesn't work and I'll check.

Update: I made today extensive experiments on it and will share my feedback later today. The instrument is a bit special in handling triggered readouts, but with an NI and usbgpib I got same consistent behavior.

[caiser01]

The trouble I'm having with 34401A is not (I don't believe) related to any of the recent changes because I was having this issue before with the previous 2022 version of the UsbGpib firmware.

It's probably easier to demonstrate than to explain: https://www.youtube.com/watch?v=vV5Avpao3gw

Basically, something is causing the meter to freeze up during communication. It often happens the first time you attempt to read from the meter after connecting the adapter. Other times you might be able to communicate successfully for a short time before it freezes but it always freezes, and then you must power cycle the meter. There is also some strange behavior with the meter's setting for how many digits it displays changing when the adapter is connected. I've demonstrated this in the video.

I don't think there is anything wrong per se with my meter because it works very well with other GPIB adapters. I suppose it could be a quirk with the firmware revision in my meter but the service bulletins from KeySight, Agilent, HP make no mention of any GPIB issues that affect 34401A meters in the range of mine's serial number. My meter has Rev 03-01-01 firmware and the build date stamped inside the case is April 1 1993 (April Fool edition meter!).

[xyphro]

Thanks for extensive description, the video makes it very clear. And it is a very annoying issue.

I have a love and hate relationship to my idea of Auto ID. If it does not work, instruments come up with an error. That can be timing related or related to *IDN? or ID? not beeing supported. I think I would not implement it again and think I should default it to OFF.

Allthough it seems good with Auto ID off, we can still say, that the Auto ID feature does bring the device to some bad state. I cannot explain the switch to more digits right now.

I have the 34401A, but a newer version (display is still VFD, but blueish and it has an Agilent label. It MIGHT be possible that the internal firmware changed a bit and that I cannot see the same behavior. Why I say this: I did not see any Error in Auto ID on powerup with UsbGpib connected (differen timing behavior). I think a switch to more digits I would not have noticed at all. My FW version is 10-5-2 (Assuming that this last part of the *IDN? response shows the FW ID).

Seeing your video I have now a clear thing to focus on testing. Let me come back on this on friday.

I feel there is a potential GPIB timing related issue. Allthough I had so far a rock solid feeling about GPIB function timings. Is this other adapter also open source? If so, I could compare the low level functions to see for potential timing issue.

Hope I see anything, otherwise it gets down to a logic analyzer based thing, which is very tough to do remote - if possible at all :-(

Let's cross fingers that I see similar things on friday...

[caiser01]

For completeness, I should also say that I tested on the RPi with both R&S VISA and pyvisa-py and the issue was still there.

I think Auto ID is a cool feature. I like that it gives a VISA resource string with the instrument name so it's obvious what's what. But I like that it can be turned off and on for cases like this. Maybe a feature for future development is another ID option where the user could set a custom name string? That way you could still have a more descriptive resource string without relying on the instrument to self report a name.

There were several firmware for the 34401A over the years and that topic itself is a rabbit hole (https://www.eevblog.com/forum/testgear/agilent-34401a-revisions/). Upgrading is possible but requires re-calibration ($$$). It would not surprise me for there to be undocumented "quirks", though maybe not outright defects, in the GPIB implementation of earlier firmwares.

The other adapter I use is indeed open source: https://github.com/Twilight-Logic/AR488 The code runs on many common AVR Arduino boards. The version I assembled uses an Arduino Micro Pro 32U4 mounted on this PCB: https://oshpark.com/shared_projects/yfUOmUzA There is an extensive thread started by the developer at the EEVblog forum: https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/

I like both adapters for different use cases. I really like the fact that yours works natively with VISA :-)

I have a logic analyzer. It's only 8 channels so might be tricky debugging GPIB but I can try to provide captures if you need them.

[xyphro]

Update: it works fine with the multimeter firmware I have :-( I will compare the low level gpib code now to see if there are meaningful differences.

[xyphro]

Hi Chris,

I do have a suspicion why it hangs on the 2nd try.

Can you try the following with the adapter that has auto ID turned off? precondition: instrument off, adapter connected to PC and GPIB 1.) turn instrument on 2.) connect with RSVisa 3.) send ID? query and check if it works (might do that multiple times also :-) 4.) Send VI_GPIB_REN_DEASSERT (see Gpib tab in rs visa tester app) 5.) disconnect RS Visa 6.) connect RS Visa 7.) Try to see if ID? query works now

Best regards,

Kai

[xyphro]

and I think, I just found something. Stay tuned!

[xyphro]

TestAndMeasurement_21stOct_0.zip

Hi Chris,

please ignore my previous test request.

I have found out that I am not waiting for a condition in the gpib_tx function which MIGHT be asserted by some meters to create a push back (=slow down). This can lead to bytes beeing not received = skipped and a wrong detection on queries. And if bytes are not received by the multimeter it will not respond.

This could have happened btw. on GPIB command bytes, but also payload bytes.

I added it in above firmware. Can you do me a favor and check it? Ideally with the non Auto ID setting. Hoping this is the cause. Debugging this remote is a bit tricky.

Best regards,

Kai

Ps: I am happy to look into speedup too once we got your issue ressolved. There are some options like enabling double buffering for the usb endpoints!

[caiser01]

Hello Kai,

Still bad news, I'm afraid. No change in behavior with this firmware.

For good measure, I went back to your earlier post and tried VI_GPIB_REN_DEASSERT, but that didn't do anything either.

The root problem of the meter front panel freezing up remains.

One additional thing I noticed that I forgot to put in the video: With Auto ID disabled, the meter powered off, and the adapter connected, if you power on the meter there is no ERROR annunciator and the number of digits on the front panel stays at the default. However, during the power up, I hear two clicks from relays inside the meter, as if it's changing ranges or similar, although nothing visible happens on the display. Without the adapter connected, there's no relay activity at power on. So even with Auto ID disabled, it seems as if the meter thinks it's getting some garbled instruction during power up. Could this be related to the way the adapter determines the GPIB address?

Another thing worth mentioning: When Auto ID is enabled, the adapter never fails to get the instrument name from *IDN? when the adapter is connected to the meter. So that initial query that the adapter does by itself always works and never causes the meter freeze up. Only when you start communicating through VISA over USB does the trouble start...

[xyphro]

Do you think it would make sense to build a special firmware for a test that does not do anything on startup? No gpib address search, no autoid?

I could fix the gpib address to e.g. 9 or so...

[caiser01]

Yes, I think either a firmware that does nothing on startup with a hard-coded address or perhaps a firmware that waits maybe 2 seconds after the instrument powers up before attempting the address search.

That might help rule out whether the issue is related to start up or not.

[xyphro]

Will make a firmware as suggested to try out. I am quite confident that the gpib layer functions themselves are OK and what I thought of beeing a bug before is none. Studied a lot of hpib waveforms in docs but also comparing with NI USB logic analyzer traces yesterday. Also compared against AR488 low level routines.

So it is likely this initial phase (I hope).

If sh## hits the fan: You don't know anybody close in Germany Düsseldorf area which would like to get a free USB gpib adapter for some hours of me sitting in his/her lab debugging with his old fiirmware hp DMM? Or sharing it for a week or so? :-) Unlikely, but who knows!

Chris Isert @.***> schrieb am So., 22. Okt. 2023, 00:56:

Yes, I think either a firmware that does nothing on startup with a hard-coded address or perhaps a firmware that waits maybe 2 seconds after the instrument powers up before attempting the address search.

That might help rule out whether the issue is related to start up or not.

— Reply to this email directly, view it on GitHub https://github.com/xyphro/UsbGpib/issues/38#issuecomment-1773940702, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFXEGC4NKKMVZCKSS2JSZDYARHJFAVCNFSM6AAAAAA4VD7OIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZTHE2DANZQGI . You are receiving this because you commented.Message ID: @.***>

[xyphro]

Hi Chris,

I did remove ALL automatic stuff. This means: No automatic GPIB address selection and also no AUTO ID. TestAndMeasurement_22ndOct_0_TurnedOffAllAutoStuff.zip

The GPIB address is hardcoded to 22 (why? Lazyness: My instrument has it right now configured).

The ONLY thing it does itself : Turn on the REN on (drive it low).

Best regards,

Kai

[xyphro]

Hope this will end up in positive news for weekend.

IF this helps, we can do the following: Short term: I would make a new mode where you can set a GPIB address and serial string yourself. Long term: I might ask you to do 1 or 2 tests further to get the actual root cause.

But let's see first if this does change something at all.

[caiser01]

Sadly, this didn't solve it either. There's nothing strange happening with the meter on power up, but it's still freezes up as before. I tried several things, different commands and sequencing, but the behavior remains the same.

I don't have any engineer friends in Germany so can't help there.

I don't know if this would be useful in debugging but I was able to build a custom version of the AR488 firmware which runs on the xyphro adapter. This is working well with the problematic meter.

AR488-xyphro.zip

You can load this bin file using the normal method with your bootloader. Perhaps this would be helpful if you need to compare low-level timings?

I can also try doing some logic captures for you but again I only have an 8-channel logic analyzer so have some limits.

Here are a couple of Python scripts I've been using for testing different adapters: HP34401A_read_tests.zip

[xyphro]

Damn! :-)

Your alternative approach is worth a try! Beginning next week I will be away, but from mid next week onwards I will try to spot deltas from logic analyzer traces!

Thanks Chris for trying things out and staying positive.

Working on a new hw version btw. in parallel. Smaller, cheaper to produce and with daisy chain option on usb side, but this issue demotivates me a bit, so hope to have soon a solution.

Chris Isert @.***> schrieb am So., 22. Okt. 2023, 21:53:

Sadly, this didn't solve it either. There's nothing strange happening with the meter on power up, but it's still freezes up as before. I tried several things, different commands and sequencing, but the behavior remains the same.

I don't have any engineer friends in Germany so can't help there.

I don't know if this would be useful in debugging but I was able to build a custom version of the AR488 firmware which runs on the xyphro adapter. This is working well with the problematic meter.

AR488-xyphro.zip https://github.com/xyphro/UsbGpib/files/13064444/AR488-xyphro.zip

You can load this bin file using the normal method with your bootloader. Perhaps this would be helpful if you need to compare low-level timings?

I can also try doing some logic captures for you but again I only have an 8-channel logic analyzer so have some limits.

— Reply to this email directly, view it on GitHub https://github.com/xyphro/UsbGpib/issues/38#issuecomment-1774183889, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFXEGH6X62P3YKJPAKK5VTYAV2SZAVCNFSM6AAAAAA4VD7OIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZUGE4DGOBYHE . You are receiving this because you commented.Message ID: @.***>

[caiser01]

Thanks for sticking with the debugging process, Kai. I know issues can be very difficult to track down sometimes so I appreciate your effort.

Looking forward to seeing what you come up with on the new hardware design. Daisy chain USB sounds very interesting. Maybe you can also revise the enclosure since I've encountered some clearance issues connecting to some instruments ;-)

[xyphro]

At least we can decrease the likelyhood of causes from the list:

• autoid and gpib address search do not trigger the trouble
• usb side is unlikely as it works for many other instruments I tested and you tested

So back to gpib transfer side...

I did btw. already improve the housing for for the new hw design!

Especially hp=agilent=keysight equipment has the tendency of too low clearance on the bottom of gpib connectors (or the 3d printed housing depending on the perspective :-D).

Updates on the issue will come on wednesday only.

[xyphro]

Will go logicanalyzing now. Might be a multi day investigation I foresee.

[xyphro]

Xyphro_Query_ID_HP3457A.zip

In case you'd like to look too... Unzip and look with Sigrok Pulseview software. It also has a GPIB decoder, making it very easy to look at :-) This is a traces with my UsbGpib software of all GPIB lines doing a: inst.query('ID?') Out[5]: 'HP3457A\r\n'

[xyphro]

GPIBUsbTraces.zip

Thanks Chris for the special compile of AR488. I managed to make now 2 different captures for both devices, so in total 4 for detailed comparison. Pulseview did not save the channel names correctly. rename the first 8 channels to dat1, dat2, ... dat8. Then in the gpib decoding line assign dat1, 2, ... to d1, d2, d3, ...

Keep in mind, that there might be crosstalk causing spikes due to bad grounding. I do see some differences. Let's see what can be meaningful.