Standard Commands for Programmable Instruments: Difference between revisions

Revision as of 14:09, 28 March 2006

Revision as of 05:40, 14 April 2006

Line 2:

The '''Standard Commands for Programmable Instrumentation (SCPI)''' defines a standard set of commands to control programmable [[test and measurement]] devices in [[instrumentation]] systems.

The SCPI Standard specifies a [[command structure]] and [[syntax]] for programmable instruments control. The physical communications link, such as [[GPIB]], [[RS232]], [[USB]], [[VXIbus]] etc, is NOT defined by SCPI. SCPI also includes standard command sets for several classes of instruments, e.g. power supplies, loads, and measurement devices such as voltage measurement[[Voltmeters]] and Digitizers (such as [[oscilloscopeoscilloscopes]]).

SCPI like SQL commands are [[ASCII]] textual strings, which are handled well by most general purpose programing languages like C/[[C++]], [[Visual Basic]], [[Python]], etc. GUI based Application Software such as Lab View and HP VEE, interact with the instruments using these commands. One of the advantages of textual commands is that they can be version managed using the same tools as [[Software Configuration Management]] (SCM), including [[Visual SourceSafe]], [[Concurrent Versions System]], and [[SubVersion]]. SCM tools can allow automated audit, history, and distribution methods for for textual programs, for example SCPI commands embedded in a Python program can be managed with SCM tools on networked production test machines.

SCPI commands are written in ASCII format. Hence, SCPI commands can be sent easily using any programming language including C, C++, Visual Basic, etc. In addition, SCPI is supported by Test Application Software such as Lab View and HP VEE.

Some instrument manufactures, notably Agilent and Tektronix have implemented this standard on all new general purpose instruments. Agilent has even back ported the standard on a few instruments, like 6030A. Many other manufactures never signed up to this standard, Voltech, Xantrex. In truth these small players have very little impact on the goal of the standards. As long as new products remain backward compatible with the old command sets no one is hurt, unfortunately command set creep has been a problem with some manufactures. The major advantage of the SCPI command set is compactness and encapsulation, which allows test system designers to spend less time fussing with individual instruments. A side benefit is no command set creep and long term compatibility, by which I mean new instruments (N3300A) are including the same user interface of the last generation (6050A).

For many years, instrument manufacturers have worked to standardize the electrical and mechanical interface between instruments and computers. Little was done, however, to standardize messages sent over this [[interface]]. Consequently, instrument manufacturers developed a wide variety of instrument [[command set]]s, requiring users to learn a new vocabulary for each instrument. The proliferation of command sets caused users to spend much of their time learning to program instruments, made maintenance of test programs difficult, and made it difficult to upgrade test systems when new equipment became available. (from [http://www.scpiconsortium.org/scpiinfo2.htm])

Instrument communication interfaces are in a phase of rapid transition, many new instruments are introduced with a plethora of interface options, including USB, LAN and GPIB. SCPI is looking more and more to be a good idea, since it is reasonable to write software wrappers for any interface and simply binding the program with a different one as needed. GPIB is quickly falling out of favor for low cost test systems now that LAN and USB have entered the game on general purpose instruments.

In fact, SCPI is yet another effort to conolidate the plathora of formats, languages and methodes to communicate with test and measurment equipment. But, like many other similar efforts (e.g. [[IVI]]) it failed to be implemented even by the founding members of the SCPI consortium.

I would suggest viewing SCPI in the same light as SQL vender's there are a lot of them and most do not agree with each other. In addition not all things that save data are suited to be controlled by a SQL command set, by the same token not all things that measure/control electrical/environmental conditions are suited for the SCPI command set. With that said I am a huge fan of SCPI and use it, SQL and a few other textual languages almost every day :-)

==References==