PI E-710 controller over GPIB unable to read from device

[KrisJa]

Hi guys,

I was having a go the other day on communicating with a PI E710 piezo controller over a GPIB bus.

More on the controller:

PI E710

This controller offers somewhat dated API's for communication in the form of a dll that allows native C++ code to communicate with the controller. Howver, this dll is no good to me since I do all development in .NET C#. I could not be bothered to try and write a wrapper for the dll or to try dll imports since these are only half solutions in my opinion.

Therefore I had a look at the NI api for IEEE-488 style protocols.

The first thing I did was modify one of the included examples: "SimpleReadWrite". I attached my slightly modified version for you to look at if needed.

The big problem with this is that if I use the program it allows me to write to the controller just fine, I can even do a SerialPoll() and see that the controller indeed sets RQS and MAV. Up to here I can see (using the NISpy) that my software makes the same calls as the supplied PI controller software. So far so good.

However, the subsequent read fails. NISpy shows me that at the beginning of the read I actually get something back from the controller, say when I try a device.read(2048) or even a device.read(). But for some reason the software keeps waiting and never returns the data already read to my form.The waiting goes on until the operation times out and then nothing happens.

I am suspecting that the E-710 controller doesn't use the proper termination character that the NI API is expecting for a read() call but I am not sure and I cannot find any documentation on this. Also, the NI API does not seem to allow to define a custom termination sequence for a read, as opposed to a board level read...

I am totally clueless. Does anybody know where to look for an answer?

Cheers,

Kris

[KrisJa]

I Have some more data on my problem...

I attached some spy screenshots:

1) The first one is the output for the device manufacturers software that is successful in communicating with the controller.

2) The second one is the one of my software (see original post).

What is strange about the second output is that right before the timeout, the line marked in yellow actually reads  ibrd(UD0, 0x0somebigumber, 2048 (0x800)) where somebignumber looks a lot like some hex pointer value or something. So _something_ is read before the timeout but it certainly isn't a human readable string as in the successful communication using the manufacturers software...

[KrisJa]

Nobody with an idea about my problem??

:s

[Michiel_H]

I indeed expect the problem to be somewhere in the method used to terminate data transfer. Basically, there are 3 different methods of data transfer termination:

- Assert the End Or Identify (EOI) hardware line with the last data byte - preferred method
- Place a specific end-of-string (EOS) character at end of data
- Allow the listener count the bytes transferred by handshaking and stop reading when the listener reaches a byte count limit

Perhaps you might try using the EOI method instead of the EOS. As you have no information on the used method, you will probably have to find the information by trial & error.

The ibrd command is actually the read command being executed. It is however returning in a timeout since no data is received.

[KrisJa]

Hey Michiel,

Thanks for the update. In the meantime I already tried contacting the OEM for my device but they "do not support C#" rather stupid if you ask me 🙂 but anyway. In the manual they claim that the only bit they ever set is MAV (from p. 29 in Manual😞

 quote: "Serial Poll Response Byte
Currently only bit 4 (hex: 0x10) of the Serial Poll Response Byte is used. According
to IEEE 488.2, bit number 4 is the Message Available Bit (MAV). It is set to 1 by
the controller when it has data to send. " : endquote

So I will try to read EOI directly when I have access to the hardware again, but I am not sure it will work.

What confuses me though is that a Device.Read() does not allow you to specify a custom EOS character while Board.Readstring() does offer this possibility. It is not clear to me why this is so. Using device is more convenient than using board, so if device read would offer to select custom EOS chars I could just give all of them a try.