Can't run consecutive queries without delay in between

[larrye11ison]

Before I get started... I seem to have this same kind of problem with other GPIB solutions. For example, I've built a few arduino-based AR-488 GPIB adapters and had problems just like this. So I'm not really convinced that there is a problem with your code. But I thought maybe you had some knowledge about what may be going on here, and/or if I'm doing things wrong, perhaps you would be willing to help me out. And if that's the case, perhaps we could improve the docs just a bit!

Using your library, I can connect to my prologix ethernet adapter and execute a single command or single query just fine. But if I try and execute two queries one right after the other, I get an error like this:

  File "./test-python-prologix-interface.py", line 21, in <module>
    print("Auto: " + gpib.query('++auto'))
  File "/usr/local/lib/python3.7/dist-packages/plx_gpib_ethernet/plx_gpib_ethernet.py", line 36, in query
    return self.read(buffer_size)
  File "/usr/local/lib/python3.7/dist-packages/plx_gpib_ethernet/plx_gpib_ethernet.py", line 32, in read
    return self._recv(num_bytes)
  File "/usr/local/lib/python3.7/dist-packages/plx_gpib_ethernet/plx_gpib_ethernet.py", line 43, in _recv
    value = self.socket.recv(byte_num)
socket.timeout: timed out

Below is the code I'm using - if I run it as shown, I get the error above. But if I uncomment the sleep() call, then it works. Is that normal?

import time
gpib = PrologixGPIBEthernet('prologix-gpib', timeout=1)
gpib.connect()
print("Ver: " + gpib.query('++ver'))
#time.sleep(.1)
print("Auto? " + gpib.query('++auto'))
gpib.close()

[nelsond]

Thank you for your request. Unfortunately, I am not an expert regarding the GPIB protocol. But I would suspect that it is caused by the particular device you are trying to control as you experienced similar problems with other interfaces. Have you checked the programming manual of your device whether that indicates any required delays before subsequent commands? In the past, I have come across devices that explicitly required some form of delay between write and read (not before the query though, as it seems to occur in your case).

To make the use of the library more convenient in your case, you could consider subclassing PrologixGPIBEthernetDevice and overwrite the query method to include the delays required for your device.

import time
from plx_gpib_ethernet import PrologixGPIBEthernetDevice

class SlowDevice(PrologixGPIBEthernetDevice):
  def query(self, cmd, buffer_size=1024):
        # implement the required delay logic here ...
        time.sleep(0.1)
	self.write(cmd)
        return self.read(buffer_size)

# create new instance of slow device
my_device = SlowDevice(host='192.168.1.14', address=10)

# open connection
my_device.connect()

# run custom commands
print(my_device.query('YOUR:COMMAND')) # => ...

# close connection
mydevice.close()

I have also updated the example in examples/sr760_device.py with a version that includes the delays required for some functions of that device.

[larrye11ison]

It happens even when executing multiple prologix commands. So if I run ++ver or ++addr, i.e. when querying the prologix controller itself. So this takes my deivce out of the equation entirely.

…

On Sun, Nov 22, 2020, 11:41 AM Nelson Darkwah Oppong < ***@***.***> wrote: Thank you for your request. Unfortunately, I am not an expert regarding the GPIB protocol. But I would suspect that it is caused by the particular device you are trying to control as you experienced similar problems with other interfaces. Have you checked the programming manual of your device whether that indicates any required delays before subsequent commands? In the past, I have come across devices that explicitly required some form of delay between write and read (not before the query though, as it seems to occur in your case). To make the use of the library more convenient in your case, you could consider subclassing PrologixGPIBEthernetDevice and overwrite the query method to include the delays required for your device. import timefrom plx_gpib_ethernet import PrologixGPIBEthernetDevice class SlowDevice(PrologixGPIBEthernetDevice): def query(self, cmd, buffer_size=1024): # implement the required delay logic here ... time.sleep(0.1) self.write(cmd) return self.read(buffer_size) # create new instance of slow devicemy_device = SlowDevice(host='192.168.1.14', address=10) # open connectionmy_device.connect() # run custom commandsprint(my_device.query('YOUR:COMMAND')) # => ... # close connectionmydevice.close() I have also updated the example in examples/sr760_device.py with a version that includes the delays required for some functions of that device. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAZMGQD5CISNCJOPK7VAF3SRFSP3ANCNFSM4TXS645Q> .

[nelsond]

Thanks for the clarification. I thought it was somehow related to the connected device as you encountered similar problems with other adapters.

The python code for talking to the GPIB adapter is actually very minimal so I am not sure what could go wrong there. Maybe you can double-check with the following code (make sure to update the host/port).

import socket

host, port = '192.168.X.X', 1234

sck = socket.socket(socket.AF_INET,
                    socket.SOCK_STREAM,
                    socket.IPPROTO_TCP)

print('Connecting...')
sck.connect((host, port))

print('Calling ++ver command...')
sck.write('++ver')
print(sck.read(1024))


print('Calling ++auto command...')
sck.write('++auto')
print(sck.read(1024))

sck.close()

Depending on the result of this test, you might want to ask the manufacturer (Prologix) about a possible required delay between "controller" commands of the form ++.... It could just be related to their specific hardware implementation. I have quickly skimmed through their documentation but did not find any information regarding the issues you encountered.

I am happy to add some information to the Readme once we have come to a conclusion.

[larrye11ison]

I think I've figured out what's going on, and I think the fix is very easy.

The short version - I think - is as follows: in the implementations of query() and/or read() on the PrologixGPIBEthernet class, don't send ++read if the initial command itself started with "++".

Examples:

If user calls controller.query('*IDN?'), then

1. Send *IDN?
2. Send ++read
3. Read from the socket

But if user calls controller.read('++ver'), then

1. Send ++ver
2. Immediately read from the socket -- do not send ++read in between

It was confusing me because this is only applicable to the the prologix "system commands" that return data -- in other words, the commands that start with "++" and return a value like "++ver" or "++addr". People that aren't using those commands would never come across the problem.

[larrye11ison]

I think I said this earlier, but I've had this same exact problem with other libraries and with other controllers (specifically, the arduino-based AR488 that tries very hard to emulate the prologix).

I'll try and do a fork/pull request, but by the time I get everything set up to do that you may beat me...

Anyway, thank you very much for being so responsive!

[larrye11ison]

Sorry for all the comment spam...

I forked the code and made the changes. But I'm a C#/.net/SQL Server guy, so Python is very much not my expertise and I feel like I'm probably doing this in a very hacky way. So rather than sending a (possibly) crappy PR, below is the only change I'd suggest - move the self._send('++read eoi') line into query(), and only do it when cmd does not start with "++".

    def read(self, num_bytes=1024):
        return self._recv(num_bytes)

    def query(self, cmd, buffer_size=1024*1024):
        self.write(cmd)
        if(cmd.startswith('++') == False):
            self._send('++read eoi')
        return self.read(buffer_size)

[nelsond]

Thanks for your detailed documentation of the issue and the PR. But I am unsure whether the behavior of query should really be changed since the command is intended to query the GPIB device and not the controller itself.

Currently, the class handles setting up the controller properties in the _setup function

prologix-gpib-ethernet/plx_gpib_ethernet/plx_gpib_ethernet.py

Lines 46 to 57 in 4e55f95

	def _setup(self):
	# set device to CONTROLLER mode
	self._send('++mode 1')
	# disable read after write
	self._send('++auto 0')
	# set GPIB timeout
	self._send('++read_tmo_ms %i' % int(self.timeout*1e3))
	# do not require CR or LF appended to GPIB data
	self._send('++eos 3')

So what is the purpose of calling the controller functions directly in your application? Are you mainly interested in receiving the version of the controller?

In general, I guess you could also use a combination of the private functions _send and _recv to achieve the desired behavior:

prologix-gpib-ethernet/plx_gpib_ethernet/plx_gpib_ethernet.py

Lines 38 to 40 in 4e55f95

	def _send(self, value):
	encoded_value = ('%s\n' % value).encode('ascii')
	self.socket.send(encoded_value)

prologix-gpib-ethernet/plx_gpib_ethernet/plx_gpib_ethernet.py

Lines 42 to 44 in 4e55f95

	def _recv(self, byte_num):
	value = self.socket.recv(byte_num)
	return value.decode('ascii')

[larrye11ison]

• Both scenarios ("getting data from an instrument" and "getting data about the state of the controller") require you to "query" the controller; so to me, it's pretty hard to argue against usage of the query() method for both use cases.
• From my perspective, requiring users of a library I wrote to hack into private members of my class would tell me that something is wrong with my API.
• Speaking of public vs. private, I'd suggest that external usage of the read() method is unnecessary and it should be made private.

Please don't take that like it may sound - I do have 20 years exp. as a developer, but ultimately it's your project and I'm just some jerk on the internet!! You've been very kind to be so responsive on such a niche subject and I appreciate your time. So you have my thoughts on that stuff and you are now free to completely ignore them!

So what is the purpose of calling the controller functions directly in your application?

Environment validation, making troubleshooting easier, etc. Am I connecting to the correct network address? Is the controller powered up and plugged into the network? Etc. In other words, before I even try sending anything to a piece of test equipment, I want to be certain that the controller itself is responding. Most of the "controller functions" return just a simple scalar value (like a 1 or 0), but ++ver's response is impossible to misinterpret, so dumping out that response is the first thing my scripts always do.

I dump out things like ++addr for similar reasons. I'm constantly moving stuff around, swapping various GPIB controllers between instruments, constantly repurposing and hacking existing scripts to automate tests, etc., so my setup is very chaotic. If something doesn't work, the first thing I want to do is confirm that things like the GPIB address are correct, so I always have that stuff dumped out right up front.

The ++auto setting is also important to me - I have many older pieces of gear, some that don't work well when ++auto is turned on. So I have a many scripts with ++auto set both ways, and having that dumped out also helps in case I'm switching the scripts around. But the bigger point - again, with the age of some of my equipment - is that I sometimes need to tweak some of those lesser-used settings, so I may need to override the settings you've chosen in _setup().

[nelsond]

Thanks for your comprehensive reply!

I just wanted to understand the details of your use case to find a solution, which might also apply to other users of the library. I certainly want to avoid breaking any existing code by modifying the behavior of the query method. Instead, I would suggest adding the function query_controller, which does exactly what you want.

In the future, it would be nice to access the different commands/settings of the controller directly from python with dedicated properties/functions in the class and a more subtle control over the _setup function. But for now, I assume that the query_controller function is enough for your specific use cases.

See #6 for my changes added to your pull request.