search

pyvisa / pyvisa-py

A pure python PyVISA backend
https://pyvisa-py.readthedocs.io
MIT License
288 stars 124 forks source link

[COM] Communication issue with Ansritsu MG37022A using TCPIP, infinite loop in open_resource #227

Closed Schneider1 closed 4 years ago

Schneider1 commented 4 years ago

Instrument details

Output of pyvisa-info

Machine Details:
   Platform ID:    Linux-5.4.0-28-generic-x86_64-with-glibc2.29
   Processor:      x86_64

Python:
   Implementation: CPython
   Executable:     /usr/bin/python3
   Version:        3.8.2
   Compiler:       GCC 9.3.0
   Bits:           64bit
   Build:          Apr 27 2020 15:53:34 (#default)
   Unicode:        UCS4

PyVISA Version: 1.10.1

Backends:
   ni:
      Version: 1.10.1 (bundled with PyVISA)
      Binary library: Not found
   py:
      Version: 0.4.0.dev0
      ASRL INSTR:
         Please install PySerial (>=3.0) to use this resource type.
         No module named 'serial'
      USB INSTR:
         Please install PyUSB to use this resource type.
         No module named 'usb'
      USB RAW:
         Please install PyUSB to use this resource type.
         No module named 'usb'
      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'

Opening the connection with rm.open_resource('TCPIP0::10.22.197.10') gets stuck in an infinite loop, without throwing a timeout.

After some search, I found that pyvisa-py keeps waiting for a second segment, since the first segment has the "last" flag disabled. However, there is no next segment sent. So this looks like a bug in the device, BUT when I try the same using the NI-VISA backend, everything works well. In the latter case, I checked with Wireshark that device again sends the "last=False" flag (resulting in a RPC Fragment), but NI-VISA can shomehow cope with the situation.

If I do a very dirty fix and setlast=Truein protocols/rpc.py:377, everything works fine and all other commands set the "last" flag correctly.

Any ideas, why this device behaves so strange? Why does NI-VISA not have a problem with that? How can I solve this?

MatthieuDartiailh commented 4 years ago

Thanks for the report. So obviously we need to fix the timeout implementation to avoid the infinite loop in the case where we expect a new packet but none show up.

After lets say I am not exactly surprised that NI-VISA has workaround for imperfect implementation of the protocol. I tried to check the VXI-11 specification but it does not suggest that this is an ok behavior. I am not sure however how to best handle it in pyvisa-py. One way would be to add a way to specify the number of packet expected when receiving records and force it to be one when creating the link. I am honestly a bit worried by this solution since the specification never mentions how many packets will be used for an operation. But I do not see a another workaround. Do not hesitate to open a PR if you come up with a solution, I personally won't have time to work on this soon.