Driver-side handling of old instrument without EOI line

Using SweepMe!
1

Hi.

I am currently programming a driver for an older instrument that does not use EOI (End-Or-Identify) via GPIB. While this wasn’t very uncommon back then, it was often possible to activate the EOI optionally via parameters, as with the HP 3456A driver. Now, this option is not available on the current device.

Thanks to the really detailed SweepMe Wiki, I am aware of the EOI customization option. When sending, a modification of behaviour isn’t even required, it works just fine the normal way, the EOI being sent is simply ignored by the instrument.

Problems start to arise when receiving data because the device does not send an EOI and the GPIB request initialted by the self.port.read() command cannot recognize the end of the response.

Fortunately, in my case (as is often the case with instruments that use no EOI) the response is always the same length. In pyvisa, this is usually made an advantage of by using read_bytes() to retrieve a fixed sum of bytes, avoiding the need to receive an identifier for the end of the response (a.k.a. EOI). Often, this is done in combination with the wait_for_srq() function since many devices offer the SRQ signal to show that the measurement data is ready to be retrieved (then you don’t have to rely on the measurement result being ready faster than the VISA timeout that is being running when SweepMe waits for the response of the self.port.read() command).

Is there a possibility in SweepMe to use at least read_bytes() from pyvisa and maybe even the wait_for_srq() function?

Best wishes,
Christian

1 Like
2

Hi Christian,

thanks for posting this issue.

SweepMe! uses our open-source library pysweepme to handle the port communication. The library can be used standalone in your own python projects but is also used in SweepMe! to make sure the handling is the same and we only need to maintain one code base.

Please have a look into the module Ports where the communication is handled for all Port types like GPIB, COM port, USBTMC, TCPIP an so on.

Of course, this file does not replace a proper description in the Wiki, but it could of great help if you need to do or test things on your own.

The class GPIBport takes care about the GPIB ports.
It is the object

self.port

that you use in the SweepMe! instrument driver.

You can use the object

self.port.port

to get access to the underlying port object that comes either from pyvisa or pyserial.

We do not recommend to use self.port.port as things can break in future in case we would change to other libraries or other adapters like the Prologix GPIB adapter use other functions. However, sometimes not all functions are wrapped into self.port yet and it is needed to call functions from self.port.port

Ports like COM ports have additional functions like read_raw or write_raw implemented that can be used to directly send and read bytes. However, GPIB ports do not support/overwrite these functions yet which is why you would have to implement your own solution for now using self.port.port and the underlying pyvisa functions.

The wait for service request handling also requires the use of the pyvisa functions.

A good example how to use SRQ events in SweepMe! drivers can be found in the Accretech wafer prober driver. There you can see the mechanism how to register und unregister events and how to wait for an event.

Hope this helps to proceed.

We are also open to improve pysweepme and make more functions available. In case of interest please let us know.

Thanks and best,
Axel

1 Like
3

Hello Axel.

Thanks for the detailed explaination. I visited the links you gave me and had a deeper look into the driver again, trying out some ideas.

Once, when the Visa driver went into time out again, I restarted the instrument while the NI I/O Tracer tool was still running. I could see that upon restart of the maschine, the Visa driver recognized this as a sign to abort it’s waiting loop and all data already transfered went into the protocol of the tracer tool as one single long string.

Now I could see that each measured value in the transfer string was separated by two characters from the others. Looking at the hex values, it was visible that those two characters were 0A 0D, in ASCII terms Carrier Return and Line Feed, or, \r\n in Python. Studying the manual of the instrument again, I now realized that one paragraph mentioned the output format as 0.000000 CRLF. Yeah, stupid me. CRLF wasn’t some sort of 80s UK slang for TL;DR or “etc. etc.”. It was meant as CR and LF in consecutive order.

Anyhow, having read the SweepMe documentation about the port properties, I just had to set GPIB_EOLread to “\r\n” and voilà, a talking instrument.

I will take the driver for a trip around the measuring block in the next days and do some polishing before being released.

Best wishes,
Christian

1 Like
4

Happy to hear that you were able to proceed. Every question is welcome and every answer will help another person, too.
The test&measurement world is again a somewhat safer place now. :slight_smile:

1 Like