Amost all instrument control communication is logically serial communication at some level. Since you connect a PC to an instrument via a cable that has either a couple or perhaps 8 data lines (in the case of GPIB), you don't have random access to the instrument, so you have to rely on messages that send commands or queries to the instruments, and messages to send and receive data in a flat, serial format to and from the instrument.

VXI (and PXI?) is the only communication mechanism that I'm aware of that presented a random access view of instruments to the controller, which means you're dealing with "dumb" instruments. I say dumb because one tenet of modern software design is information-hiding. If you don't have to know the inner details of every system you touch you can work at a higher level and get your immediate job done faster and easier. Twidlling bits on an instrument across the VXI backplane is the opposite of information hiding. An instrument that exposes its guts like that can't change or do any software "work" for you because it would get in the way of this random access to the instrument. Anyway, VXI is for another day

So what makes serial hard? Two things: data formats and a deterministic way to tell a transmission is complete.

Data formats refer to how to serialize data from a complex, binary representation in the PC or instrument, to a flat, serial representation that can go across the wire. This is alternately called marshalling. In the instrumentation world the answer has always been to create formats that are human readable and intuitive. So a IEEE Standard 754 binary representation of a particular floating point number in the memory of a PC is changed into the ASCII text "1.049e-3" for transmission over the wire. These textual representations of datatypes common in T&M were standardized into IEEE Standard 488.2.

One thing missing from most 488.2 representations is framing. Framing means putting information at the beginning of a serialized value saying how much data to expect in the value. If you always know how much to read, you know when to stop reading. There are some 488.2 binary types that have framing, they are called definite-length 488.2 binary blocks.

The language of commands and queries used by most T&M instrumentation is called SCPI (Standard Commands for Programmable Instruments). For example, to ask a DMM (Digital Multimeter) what voltage it is currently reading, you would send it "MEAS:VOLTS?". SCPI also has no framing for its commands.

One thing SCPI does have is a defined read termination character. Whenever a SCPI device reads this character, it knows the current message is complete. The character is the ASCI linefeed, code 10. This is not too unexpected, since old line printers would receive a Carriage return code followed by a linefeed code to start a new line of text. Trivia: it takes longer for the printer head carriage to move all the way back to the beginning of a line than it does for the paper roll to advance one line, so CR, ASCII code 12, was always sent first.

GPIB (formerlly HP-IB for Hewlett-Packard Interface Bus and standardized as IEEE 488) has an alternate solution to this problem. Anyone who's bought a GPIB cable knows how thick (and expensive) they are. One of the things you're paying for is a line devoted to telling you to stop reading data. There is an EOI transmission line, that when raised during the transmission of a byte, indicates that that byte is the last byte in the message, so you can stop reading. On well-formed SCPI over GPIB, the EOI line is always raised when the Linefeed character is sent to indicate the end of the message. Your GPIB I/O librarys (VISA, NI-488, SICL, or what have you) Read() method will return, and you'll have a well-formed message to read.

So why is serial so hard? If you want to send binary data over serial, assuming the data is random about every 255th character will be the ASCII linefeed character. That explains the existence of the 488.2 Definite-length binary block with its built-in framing. Someone reading from a 488.2-compatible data stream would see the # character and if the following character was a numeral, they would know it was a definite length block with the length information prepended before the start of the data payload. There are I/O libraries, such as VISA (Virtual Instrument Software Architecture) that have methods for interpreting such blocks. If you get it wrong and read too much, you'll either time out and your read function will return an error or your program will hang indefinitely.

Getting all this right can be a real pain, and sometimes there's no hope. A team I was on had to deal with an instrument that was designed to send a waveform image to a GPIB printer. It would format the data as a raw binary block that the printer expected. Apparently those that designed the printer data format decided that since a printer has nothing to do when it isn't reading data, there is no reason to tell it when the data is complete. :(

There was no other way to get the nice waveform image out of the instrument to give to the user. Users could choose to hook up their PC to the instrument via a serial cable, and it is reasonable to expect the same behavior of our application on any supported I/O method. We settled on an intra-character timeout. We read one byte at a type from the incoming I/O stream, and tell the I/O library we were using to stop reading and report an error if more than, say, a quarter-second went by without receiving data. This meant that the operation to display the waveform to the user would always take a quarter-second longer than it needed to.

But... we found in testing that sometimes the instrument would burp. It would process data to generate the waveform as it went, and it would sometimes pause as it was processing longer than we expected. I think in the end we had to settle for a one-second intracharacter timeout, which was a far from ideal solution.

A problem specific to older serial devices is handshaking. Handshaking is serial's way of traffic coordination. A serial cable would typically have 4 or more transmission lines. One for data up, one for data down, and the other two to coordinate those data lines up and down. If a receiving device kept a handshaking line high, the talking device would continue to talk. If the receiving device set the line to low, the talking device would stop talking. This allowed both sides to absorb data at a rate they could handle so that no bits would be lost.

On another project, we had an instrument that was sending us malformed data on some computers but not others. We got the bad data during line-by-line debug, but not during run debugging. We spent several weeks looking into NT's serial implementation, the source code behind the I/O libraries we were using, and probably a dozen different places. Can you guess what the problem was?

The instrument had a broken handshaking implementation. Older instruments sometimes used their own implementation of RS-232 rather than the defacto-standard RS-232 chipset to save a couple of bucks (back when they cost that much.) This particular instrument had a flawed handshaking implementation that would rear its ugly head when the PC couldn't keep up with the instrument, making the data look malformed. It may be a truism that more bad things happen when people try to save a couple of bucks than when malice is intended.

Today serial is being killed by USB for higher-end devices, but it is still a common way of controlling devices under functional test and for communication between embedded devices. Many T&M instruments support raw TCP/IP socket communication, which can still have the read termination problem, but thankfully not the handshaking problem of days past.

Perhaps I could have boiled this essay down to something simpler

Serial Considered Harmful