pyvisa / pyvisa-py

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

Add support for LAN device name in TCPIP INSTR resources #225

Closed MatthieuDartiailh closed 4 years ago

MatthieuDartiailh commented 4 years ago

As reported in https://github.com/pyvisa/pyvisa/issues/508 support for lan device name would enable some user extra user cases.

garlick commented 4 years ago

Using wireshark to watch the vxi11 protocol exchange, it looks like the lan device name required by my GPIB ethernet gateway (e.g. gpib0,4 or gpib0,9,3) passes through OK, but after establishing the link, _devicewrite fails. I noticed that the flag termcharset (0x80) is set in the _devicewrite RPC, but the VXI-11 spec says:

termchrset(80): This flag is set to one(1) if a termination character is specified on a read. The actual termination character itself is passed in the termchr parameter. This flag is only valid for device_read.

(B.5.3. Operation Flags, pg 32) https://www.icselect.com/vxi_spec.html

So maybe the protocol implementation is wrong, and this device is more pedantic about it than others?

I tried modifying TCPIPInstrSession.write() to skip setting this flag and the _devicewrite succeeds.

--- tcpip.py.bak    2020-05-02 13:28:15.291195706 -0700
+++ tcpip.py    2020-05-03 07:14:17.939321057 -0700
@@ -164,10 +164,7 @@
         chunk_size = 1024

         try:
-            if send_end:
-                flags = vxi11.OP_FLAG_TERMCHAR_SET
-            else:
-                flags = 0
+            flags = 0

             num = len(data)
             offset = 0

However, then things go wrong processing the data in the response:

Traceback (most recent call last):
  File "./testprog.py", line 25, in <module>
    print(inst.query("*IDN?"))
  File "/home/garlick/.local/lib/python3.6/site-packages/pyvisa/resources/messagebased.py", line 613, in query
    return self.read()
  File "/home/garlick/.local/lib/python3.6/site-packages/pyvisa/resources/messagebased.py", line 427, in read
    message = self._read_raw().decode(enco)
  File "/home/garlick/.local/lib/python3.6/site-packages/pyvisa/resources/messagebased.py", line 400, in _read_raw
    chunk, status = self.visalib.read(self.session, size)
  File "/home/garlick/.local/lib/python3.6/site-packages/pyvisa-py/highlevel.py", line 345, in read
    ret = self.sessions[session].read(count)
  File "/home/garlick/.local/lib/python3.6/site-packages/pyvisa-py/tcpip.py", line 133, in read
    self.lock_timeout, flags, term_char)
  File "/home/garlick/.local/lib/python3.6/site-packages/pyvisa-py/protocols/vxi11.py", line 226, in device_read
    self.unpacker.unpack_device_read_resp)
  File "/home/garlick/.local/lib/python3.6/site-packages/pyvisa-py/protocols/rpc.py", line 452, in make_call
    unpack_func)
  File "/home/garlick/.local/lib/python3.6/site-packages/pyvisa-py/protocols/rpc.py", line 257, in make_call
    self.unpacker.done()
  File "/usr/lib/python3.6/xdrlib.py", line 153, in done
    raise Error('unextracted data remains')
xdrlib.Error: unextracted data remains

Trying to run that down but wanted to post an update.

MatthieuDartiailh commented 4 years ago

Thanks a lot for investigating this ! I am not exactly surprised to learn that the protocol implementation is not perfect. Keep me posted and let me know if I can help.

garlick commented 4 years ago

On the xdrlib error, I think this is a separate problem. There an extra 4 bytes of padding in the read response that as far as I can tell should not be there. Not pyvisa-py's problem?

Although commenting out the self.unpacker.done() cal in Client.make_call(), which asserts that all data in the xdr packet has been consumed, gets all my gear working:

--- rpc.py.bak  2020-05-03 08:39:02.726624763 -0700
+++ rpc.py  2020-05-03 10:24:44.664317205 -0700
@@ -254,7 +254,6 @@
             result = unpack_func()
         else:
             result = None
-        self.unpacker.done()
         return result

     def start_call(self, proc):
garlick commented 4 years ago

Want me to submit a PR with the first change?

I could tack on the second one too, if relaxing that assertion is OK.

MatthieuDartiailh commented 4 years ago

Please open a PR with both changes and comment pointing out why we do things the way we do. Also please remove the comment saying that lan device name are not supported in open. Thanks for your time !