Monday, September 28, 2015

Common SCPI Errors

Common SCPI Errors


The Standard Commands for Programmable Instruments (SCPI) was first released with IEEE 488.2 (GPIB Standard Codes, Formats, Protocols, and Common Commands) specification in 1987.  SCPI defined a syntax, commands, and data formats to be used with all instruments.  It defined generic commands (e.g. SENSe, SYSTem and MEASure) that could be used with all instruments of a similar class.

SCPI defines the error query as “SYSTem:ERRor?” and a fairly complete set of errors that can be generated.  There are many types of errors and events defined (command, execution, device specific, and query). 

A quick note on SCPI mnemonics, SCPI typically defines a long form and short form for each command.  The mixed case indicates what is short form by what’s capitalized and the rest is the long form.  E.g. SYSTem means the SYST is the short form of system and is as valid as using “SYSTEM”.  SCPI mnemonics are case insensitive, so SYSTEM, SyStEm, and system are all valid.

Common Errors

I am just going to cover a few common errors and the likely causes for the error.  The first is the command error “Undefined header”.

-113,”Undefined header”

This indicates the instrument did not recognize the command message.  This is arguably the most common error during development.  It can be generated by transposing letters, misspelling, spaces in the wrong place, no separation between command and parameter, or a command not supported by this instrument.  E.g

:meas:rse?   // typo
:mews:res?  // typo
:meas: res?  // space after the :
:meas:res?100  // No space between ? and parameter.
:output:imp 10  // Not valid on measurement device.

The next two errors that will be discussed are “Query Errors”.  These errors are often confused with each other.  These errors indicate problems with the output queue and are defined in the IEEE 488.2 Message Exchange Protocol (MEP).  There are only two reasons these MEP errors occur:
  1.         Trying to read from the output queue when there is no data.
  2.         The data in the output queue has been lost.

The first of these errors that will be covered is “Query Interrupted”.

-410,”Query Interrupted”

This error is generated when you send a valid query and before reading the response you send another message.  Another way of saying this is the instrument was addressed to listen while it has contents in the output buffer.  This error can be avoided by staying in sync with the last query or command that generates output.  Examples of this error might include:

Send :system:error?
Send *opc?

This generated the “Queue Interrupted” because you must read the response from the “:system:error?” before sending another command or query that will generate output.

It’s also important to remember to read the entire response so after you have read the response the output queue is empty.  You do have to be aware if the instrument appends newlines to the end of responses and when reading responses that the newline is accounted for and not left in the output buffer.

The next Query Error to be discussed is “Query Unterminated”.

-420,”Query Unterminated”

This error is generated when you read from the instrument when the output queue is empty.  Some reasons for this might be a malformed query generated a “-113,”Undefined header” then the read will add the “Query Unterminated” error to the error queue.  If this error is caused by malformed program message that has multiple commands or queries, at the point this error is generated the remaining program message will be discarded so the parser is ready to accept another program message.

Non IEEE 488.2 Protocols

The last two errors discussed in this article are MEP errors that are defined in the IEEE 488.2 specification.  IO protocols that adhere to MEP are GPIB, USBTMC-USB488, VXI-11, and HiSLIP.  These IO protocols have the Message Exchange Protocol Enforcer (MEPE).  There are other protocols such as sockets and if you have old instruments RS-232 (think HP 33120A).  These protocols do not have MEPE and their behavior will be different and these Query Errors will not be generated.  For sockets, the behavior is dependent on how the socket is configured.  Typically the next read on the socket will hang or timeout.  Clearing out the parser might be as easy as doing a valid query e.g. “*stb?” to read the status byte or “:system:error?” to read the error queue.  Also, the IEEE 488.2 command “*cls” will clear the output queue, clear the MAV bit of the status byte, and forces the device to the idle state.  If the instrument supports the socket control channel, you can do a device clear.


These kinds of errors are most found when first writing an application using SCPI.  A well behaved application typically does not generate these errors but things do occur that will cause these errors, like missing a trigger and the assumption the reading is always there.  In general it’s a good idea to have a SCPI error handler to deal with any errors and to get the parser into a good state before continuing.