You must add a |reason= parameter to this Cleanup template – replace it with {{Cleanup|February 2006|reason=<Fill reason here>}}, or remove the Cleanup template.
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 Voltmeters and oscilloscopes.
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.
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).
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 :-)