Timing in GPIB

[Tomas_E]

This is my own opinion in experiment.
First the IEEE488 protocol is not exact in time, this is a common problem if we use the way of handshaking communication. And in LabVIEW actually, the objective instrument executes the command after we send a string. The handshaking is not seen at this level, so we could directly think that the PC has just delievered a command to the instrument.

However, while we send the command to read data from the instrument, say a counter, the data can be very misleading. I am not sure how the buffer handling in that counter, but when the data gets ready to be read, and the GPIB reading process starts, the current frequency information just loses. It is somewhat like a digital osc while data processing.

My suggestion is
, can IEEE488 work in a style just like RS232? Send the Ready data broadcastly, and don't not care whether the PC has the chance to read or not. In this situation, the counter does not stop to count frequency and keeps the data fluent in time domain.

We all know that the benefit of GPIB is that it can connect many instruments and organize them; and the RS232 could only be point to point style when general simple use.

What is your opinion about this?

[JLS]

Hello,

If you feel timing is the issue, you can consider the HS488 protocol if your instrument in compliant with it. This is the high speed version of communication via GPIB which does not use the usual handshake. As far as getting 232-like behavior, they are simply inherently different interfaces; a GPIB controller and UART simply behave differently. I imagine you should be able to achieve your desired functionality via GPIB, unless you require transferring more data that can be handled within a give time period via GPIB. You may simply be encountering a programming issue. If you can be more specific about the program it may help understand the root cause of the problem you are seeing.

Thank you,

JLS

[GPIB_Guru]

Because of the full-duplex nature of RS-232, it can be reading from the device at the same time it is sending data to the device.

GPIB is a half-duplex bus. It uses a single set of data lines to pass information to and from devices. Since it uses a shared set of data lines, the host can either be talking or listening, but not both.

However, while this is the nature of GPIB, any instrument that is a GPIB instrument should work correctly. In addition, if you could do something to fake the instrument into a 232 type of mode, it would not help it since it sounds like the instrument is broken. What I mean by that is that it sounds like the instrument has some internal problems that causes it to lose information. I recommend talking to the instrument manufac
turer to find out why their device is non-compliant to the standards it claims compliance to.