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 commands are ASCII textual strings, which are handled well by most general purpose programing languages; including C/C++, Visual Basic, Python, etc. GUI based Application Software such as Lab View and HP VEE, interact with the instruments using these commands. SQL is another well recognized textual command language, which has some advantages when Software Configuration Management (SCM) tools are used. Both ISO_9000 and SOX require audit, history, and controlled distribution methods for production software. One low cost way to surpass most auditors expectations is to combine an SCM tool like SubVersion with a scripting language like Python that has SCPI commands embedded. Some programmers find a web viewable interface to the SCM repository helpful, like ViewVC, and if shown to an auditor that may be worth something also. Program development with SCPI commands is generally comparable to GUI methods, however cut, past, modify of textual routines is much faster, so once a number of SCIP routines is developed productivity increases substantially.
Some instrument manufactures, notably Agilent and Tektronix, have implemented SCPI on all new general purpose instruments. Agilent has even back ported the standard on a few instruments, e.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 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 less command set creep and long term compatibility, one example is the Agilent N3300A includs the same SCPI commands found on the last generation 6050A.
Instrument communication interfaces are in a phase of rapid transition, many new instruments are introduced with multiple interface options including; USB, LAN and GPIB. SCPI works the same on all of them. It is reasonable to write software wrappers for any interface and bind to the interface within software as needed. LAN and USB is quickly gaining favor for low cost test systems, however older instruments with GPIB will linger around for many years.
SCPI and SQL are readable textual command languages, which are liked by some programmers because they are crufty, they can be directly Differenced against other versions, reusing is as easy as cut and past, and logical flow is as easy to discern as reading. Some of these positives are considered negativities by other programmers, so its probably best for each group of developers to decide how to solve the issues of concern.