Default GPIB termination character

[bronger]

What's the best assumption for a default GPIB termination character?  So far, I assumed "CR LF", however, newer instruments seems to tend to "LF".  What are your experiences?

I know that it differs between instruments.  The question is which is the best default value (which the programmer can change if necessary).

[Dennis_Knutson]

Most GPIB instruments don't use either LF or CR. They just use the EOI (End or Identify) line. This has been true since 488.2 was adopted in 1987.

[GPIB_Guru]

The best default termination character is none. GPIB (IEEE 488.1) defines a special hardware line, EOI, which is asserted with the last byte to signify the end of a transfer. You should rely on this method to terminate a GPIB transfer, as opposed to a termination byte that is stuffed into the bytestream. Some older devices (primarily those that were initially RS-232) use only a EOS character, and that can be CR, LF, or CR-LF, which is why the option exists to terminate a read transfer on EOS with NI-488.2.

Most devices (such as those following the IEEE 488.2 protocol) use both (they send a LF at the end with EOI asserted). Even in that case, however, you should only really be concerned with the EOI since that is the native termination of the GPIB.

[bronger]

Thank you for your replies.  EOI is the way to go of course, however, often you have to strip a LF from the end of the message or things like that, especially when reading binary data.  Therefore I still let the user of my library define a termination character (sequence).

[GPIB_Guru]

If you are doing binary transfers, the linefeed may not be a linefeed, but instead a binary character. It is especially for binary transfers that termination characters should be avoided.

Allowing them to define a sequence is not the same as providing one as the "default".

[bronger]

---

@GPIB Guru wrote:
If you are doing binary transfers, the linefeed may not be a linefeed, but instead a binary character. It is especially for binary transfers that termination characters should be avoided.

---

Tell this the manufacturer of my DMM!  😉  (It prepends #0 and appends LF.)

[GPIB_Guru]

Ahh, but that is the way that a properIEEE 488.2 device behaves. It is terminating the TRANSFER with LF+EOI as all IEEE 488.2 devices must. The #0 indicates that it is binary data all the way until the LF+EOI (a.k.a. arbitrary binary data). You don't need to use a LF as a termination character (meaning to terminate the data transfer) since you should get an EOI. However, when you are parsing, you need to be aware that the last byte is not part of the binary data.

[bronger]

Okay, then let me reformulate my question:

What's the most typical character (sequence) that you have to strip from the end of a message sent from a GPIB instrument?  CRLF, LF, ...?  (No matter what the standard says, just your impression of the real-world situation.)

Message Edited by bronger on 07-19-2005 02:01 AM

[GPIB_Guru]

That is a better question! My experience is mostly with IEEE 488.2 instruments, which are required to terminate with LF+EOI. Unfortunately, each different (non IEEE 488.2) instrument is unique.

Since this only should matter for binary data (with ASCII data, CR and LF characters are typically considered whitespace), you need to look at how binary data is transferred. With IEEE 488.2, there are two forms of binary data:
1) #0...LF+EOI
2) #x123...

The first one is arbitray binary data which starts with #0 and has binary data all the way until the next-to-last byte. The last byte is always LF+EOI. The second one is defiite binary data which starts with a # sign followed by one number that indicates the number of digits in the count. The count then follows. After the count is exactly count number of binary characters. Afterwards you would expect to either see LF+EOI or perhaps a semicolon to start a subsequent response message unit.

If you are using an IEEE 488.1 device to transfer binary data, you will need to consult the user's manual for the parsing information. If others have experience with non IEEE 488.2 instruments, please post your general experience.

No knowing exactly what you are producing and how you plan to let your users interact with the software, I have never seen a termination character except for LF, CR, and CRLF.

I don't know if I answered your question exactly, but I hope so.... 🙂

[Noel]

IEEE-488.2 defines two different binary standards for transfer. 

Definite Length Arbitrary Block

Indefinite Length Arbitrary Block

Both of these binary formats are a mix of ASCII and binary data. The Indefinite Length Arbitrary Block data starts with "#0" and ends with a new line followed by EOI.    The Definite Length Arbitarary Block format precedes the binary data with information about the number of binary data values.   This format does not include a termination character unless you configure your GPIB communication accordingly.

The most commonly used binary format used in GPIB instruments is Definite Length Arbitrary Block format.  Examples of how to parse data in this format are included at link below.  Also, an NI tutorial describes this format in more detail.

Example:

http://sine.ni.com/apps/we/niepd_web_display.DISPLAY_EPD4?p_guid=C993A8A8911F19DDE034080020E74861&p_...

Tutorial:

http://www.ni.com/swf/presentation/us/instcontrol/

For ASCII data parsing, I would recommend using the Scan From String function.  With this function you don't have to strip off termination characters to extract information from the instrument response string.  For example, suppose your instrument returns data in the form of "10\n".   By using the Scan from String function and passing a "%d" as the format specifier, the "10.0" will be extracted from the string and converted to an integer.   Similarly, if the response string returns text information and you know the termination character is "\r\n" and included in the string, then the format specifier can be "%s\r\n", thus all text before the termination can be stripped.