Standard Commands for Programmable Instruments: Difference between revisions

Revision as of 05:40, 14 April 2006

Revision as of 06:21, 14 April 2006

Line 4:

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 [[Voltmeters]] and [[oscilloscopes]].

SCPI likeand 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]] (CVS), and [[SubVersion]]. SCM tools can allow automated audit, history, and distribution methods for for textual programs,. forThe rapid test application development I use is to exampleembed SCPI commands embedded in a Python program canand bemanage its manageddistribution with SCM tools on networked production test machines.

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, likee.g. 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).

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.

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 :-)

Line 15:

* [http://www.scpiconsortium.org/scpiinfo2.htm The SCPI consortium]

* [http://www.jpacsoft.com/scpi_explained.htm JPA conulting]

* [http://epccs.org/indexes/Software/PyWinGPIB/ Python GPIB to try some SCPI with]

[[Category:Electronic engineering]]