Design Talk: Automation
Make It Easier To Learn Instrument SCPI
By Conrad Proft, Agilent Technologies
Your job as a test engineer is to automate test equipment to verify your company’s products. Many of you spend way too much time learning how to program that test equipment. Have you ever quickly and successfully configured an instrument from its front panel or Web interface and then spent hours or days trying to do that same task programmatically? Have you been frustrated with programming manuals that give you a dictionary of ASCII programming commands and few examples or interrelations between those commands? This frustration can come even if you are using instrument drivers for your programming environment.
Many instruments use the SCPI programming language which is designed to be self-explanatory and quite intuitive. Agilent requires that its products use SCPI as the native programming language. SCPI is supposed to reduce the programming efforts substantially, which it can once you become familiar with it and are using multiple instruments that utilize SCPI. Even if you are familiar with SCPI, instruments today have so much functionality built in that it can be time consuming to understand the many subsystems, parameters, and interrelations between commands. Since direct SCPI programming is used in over 50% of test systems, you need a plan for learning it quicker. If you can get your hands on any tools to help you learn quicker, you’d likely be happy to use them. Time is of the essence.
This paper does not teach you SCPI – it helps you to learn the SCPI of any instrument by describing a process. It also describes a free SCPI Learning utility that uses the process to determine the instrument SCPI commands necessary to take the instrument from one state to another. The utility is preconfigured for a number of commonly used Agilent instruments; however, once you understand the process you can easily modify the Excel spreadsheet tool to accommodate new instruments – even instruments that are not SCPI but are an ASCII-type language that are similar in concept.
What is SCPI?
SCPI can be sent to an instrument over many interfaces such as LAN, GPIB, RS-232, and USB. All of these interfaces are directly supported by Agilent VISA or NI VISA I/O Libraries which make programming in the environment of your choice relatively easy, efficient, reliable, and fast. Many instruments from Agilent, for example, include several interfaces: LAN, GPIB, and USB, so you have programming flexibility for a particular environment.
SCPI is an ASCII language that consists of configuration and query commands that are specific to the instrument and a set of IEEE 488.2 operations and commands that are common to all SCPI-based instruments. SCPI commands have long and short forms, where the long form is very descriptive, and the short form is an abbreviation: “TRIGGER:COUNT” can be “TRIG:COUN”.
Every instrument has a state, and that state determines what it is going to do next. It might be configured for DCV, 5 volt range, 100usec aperture, take 10 readings on a trigger from an external source, etc. That state can be changed with commands, and it can be queried with commands. Some commands change multiple state parameters and some queries only return dynamic data that has been captured by the measurement engine. SCPI commands can be broadly categorized as follows:
CONF:VOLT:DC 5.00, 0.1
Configure – Query Commands
The query form of the previous command actually reads the state variable for that configuration of the instrument. The previous examples showed the CONF command, where many state variables are affected. It may take a number of queries to determine what changed in the instrument to determine what the CONF command changed.
Query Only Commands
Reading the Instrument State Variables
A properly designed instrument will have a configure command to change every state variable and have an associated query of that state variable. This is the Configure-Query combination of SCPI commands. These are the commands we use to learn the SCPI of the instrument. You need to acquire all the SCPI commands of the instrument and separate these commands from all the other commands. This can be done quite easily for modern day instruments which have electronic manuals. Every well written manual or on-line help tool such as 34410A_SCPI_Reference.chm, provides a listing of all the SCPI commands of the instrument. You simply weed out all the commands that are not of this form. The following is an excerpt from an electronic manual to illustrate:
This may seem tedious, but I have taken instruments like the Agilent 34410A DMM or Agilent 33220A Function Generator and extracted all the valid queries in 15-30 minutes each. Once you have all these queries, you are ready to use the SCPI Learning Process.
SCPI Learning Process
1. Bring the instrument to some initial state - typically Reset or power ON
With sometimes 100 or more queries, you probably want this automated somehow. With a tool like Excel, it is pretty easy to run through all the queries and dump them into columns that can later be compared. If any two columns are different, you note those changes, and those are the state variables you need to change to get the instrument to that new state. With the Command-Query commands as the basis, you now have the new state variable result, and you know the original command (without the “?”). All you need to do is send that command with that result concatenated to it to change the instrument to that state.
For learning how to program the instrument, this technique is perfect. For using the commands to reprogram the instrument directly, you need to be aware of a peculiarity of certain instruments. Some instruments like commands in a particular order; otherwise, you can generate errors or warnings. You learn this quickly by sending the commands back to the instrument. It really is a function of the order in which you read the results, build the return command-parameter, and send the new command back to the instrument.
SCPI Learning Utility
You can see the instrument’s Query commands in the lower left hand corner, under Start. You need only supply all the valid Configure-Query commands in this column, and the tool does the rest of the work.
Sometimes, you are only interested in a certain subsystem of the instrument. In that case, you need only provide the Configure-Query commands for that subsystem. The free Excel SCPI Learning Tool provides an easy way for you to send the particular commands for understanding the instrument. You only task is to find all the Configure-Query command pairs and extract the Query form. You do not need to understand the commands first. You just need to locate the commands.
Locomotive Manufacturers Case Study
New System Status Module for Locomotive Control Consoles
Conventional system status modules include up to six illuminated indicators per unit that display "ready" or "warning" states for various critical subsystems. There can be five to seven modules in an operator control cab. As part of the locomotive start-up routine, each module must be tested independently by the cab crew, a time-consuming process that slows ready time and may increase operator error. Replacing modules often is a maintenance headache that involves costly removal and lamp replacement. Illumination in most status modules uses power-hungry incandescent lamps, with relatively short service lives of approximately 5,000 – 10,000 hours, that are susceptible to premature failure from shock, vibration, and power fluctuations. Incandescent lamps are associated with reduced reliability and decreased energy efficiency in the challenging environment of an operating locomotive.
To meet safety and performance objectives, crews need to be assured that locomotives are in proper working order before leaving the yard. One clear contributor to assuring locomotive performance and safety is the attention the industry has given to human factors in the design and evaluation of new and existing locomotive cabs. The need for improvement has been closely examined by the Federal Railroad Administration (FRA) in its assessment of standards developed by the Association of American Railroads on crashworthiness and working conditions that affect safety and productivity. The FRA's conclusion is that the two most important factors are working conditions and the incorporation of information technology.