SCPI标准与编程指南

5星 · 超过95%的资源需积分: 48 138 浏览量更新于2024-07-28 3 收藏 4.17MB PDF 举报

"SCPI（Standard Commands for Programmable Instruments）是一种通用的编程接口标准，用于控制和通信测试测量设备，如示波器、信号发生器、频谱分析仪等。SCPI由SCPI Consortium制定，并在1999年发布了1999.0版本。该标准旨在统一仪器的编程命令，方便用户通过各种编程语言或接口（如VISA）与仪器进行通信。文档包含了SCPI的语法和风格指南，以促进不同制造商的仪器之间的互操作性。用户可以复制整份文档或部分文档，但必须保留文档开头的版权信息和授权声明。" SCPI的主要特点和知识点包括： 1. **命令结构**：SCPI命令通常遵循“:/command:parameter”结构，其中“/”用于分隔命令层级，“:”表示命令的开始，“command”是具体的操作，“parameter”则是操作的参数。 2. **数据类型**：SCPI支持多种数据类型，包括数值（实数、整数）、字符串、数组以及布尔值。例如，数值可以用十进制、十六进制或二进制表示。 3. **错误处理**：通过“*ER?”命令查询仪器的错误状态，而“*ESR?”返回错误代码和描述。 4. **命令组**：SCPI定义了多种预定义的命令组，如“IDN?”用于获取仪器的识别信息，“SYST:ERR?”用于查询系统错误，以及“OUTP”用于控制输出状态。 5. **数据传输**：SCPI支持ASCII和二进制两种传输模式。ASCII模式方便阅读，而二进制模式则提供更高的传输效率。 6. **设置与查询**：使用“:SET”命令进行设置，配合“:Q?”命令进行查询，如“VOLT:DC 10”设置直流电压为10伏，然后用“VOLT:DC?”查询当前设置。 7. **范围与限制**：许多命令允许指定范围，例如“VOLT:MIN 0, MAX 10”设置电压的最小和最大值。 8. **通道管理**：多通道仪器可以通过通道选择命令来操作特定通道，如“CHAN1:VOLT 5”设置通道1的电压。 9. **定时与触发**：SCPI提供了定时和触发功能，如“SOURce:TIMer”用于设置源的延迟时间，而“TRIGger:SRC”定义触发源。 10. **子系统和配置**：仪器中的复杂功能被划分为不同的子系统，如“SOURce”，“MEASure”，“DISPlay”等，每个子系统有自己的命令集。 SCPI的广泛应用使得测试工程师可以通过统一的接口来控制各种不同的仪器，减少了学习和开发的时间。同时，VISA（Virtual Instrument Software Architecture）通信库通常支持SCPI协议，使编程更为简单，无论是使用C，VB，Python还是其他编程语言，都能方便地与SCPI兼容的设备进行通信。

4.1.3.1 Overlapped and Sequential Commands

KI005IEEE 488.2 defines a distinction between overlapped and sequential commands. As defined

in IEEE 488.2, a sequential command is one which finishes executing before the next

command starts executing. An overlapped command is one which does not finish executing

before the next command starts executing. These types of commands are described in IEEE

488.2, section 12. Examples are given in IEEE 488.2, appendix B.

KI005IEEE 488.2 defines three common commands (*OPC, *WAI, *OPC?) which a device

controller can use to synchronize its operation to the execution of overlapped commands.

The definitions for these common commands appear in sections 10.18, 10.19, and 10.39 of

IEEE 488.2. All three are required by IEEE 488.2, even if none of the device’s commands

are overlapped.

KI005Implementing any device commands as overlapped will increase the complexity of the

implementation of the three synchronization common commands.

KI005Each overlapped command has associated with it a Pending Operation flag. The device sets

this flag TRUE when it passes the corresponding command from the Execution Control

block to the Device Action block. The device sets the flag false when the device operation is

finished, or has been aborted.

KI005IEEE 488.2 defines a No Operation Pending flag. This flag is FALSE whenever any Pending

Operation flag is TRUE, and is TRUE whenever all Pending Operation flags are FALSE.

IEEE 488.2 also permits device designers to decide which overlapped commands are

included in the No Operation Pending flag. A device may implement commands which

select which overlapped commands are included in the No Operation Pending flag, although

the SCPI standard does not include such a command.

KI005IEEE 488.2 requires user documentation to clearly indicate which commands, if any, are

overlapped, and which overlapped commands are included and which are excluded from the

No Operation Pending flag.

KI0054.1.3.2 *CLS

KI005This command clears all status data structures in a device. For a device which minimally

complies with SCPI, these registers are:

KI005 SESR (IEEE 488.2)

OPERation Status Register (SCPI)

QUEStionable Status Register (SCPI)

Error/Event Queue (SCPI)

KI005Execution of *CLS shall also clear any additional status data structures implemented in the

device. The corresponding enable registers are unaffected. See the table in Command

Reference, 20.7.

KI005*CLS forces the device into OCIS and OQIS (see 4.1.3.3 and 4.1.3.4) without setting the No

Operation Pending flag TRUE and without setting the OPC bit of the SESR TRUE and

without placing a “1” into the Output Queue.

KI005

1999 SCPI Syntax & Style

4-2 SCPI Compliance Criteria

For example, suppose a device implements INITiate[:IMMediate] as an overlapped

command. Assuming that the trigger model is programmed so that it will eventually return to

the IDLE state, and that INITiate[:IMMediate] takes longer to execute than *OPC, sending

these commands to this device:

KI005 INITiate;*OPC

KI005results in initiating the trigger model and, after some time, setting the OPC bit in the SESR.

However, sending these commands:

KI005 INITiate;*OPC;*CLS

KI005still initiates the trigger model. Since the operation is still pending when the device executes

*CLS, the device does not set the OPC bit until it executes another *OPC command.

KI0054.1.3.3 *OPC and *WAI

KI005A device is in the Operation Complete Command Active State (OCAS) after it has executed

*OPC. The device returns to the Operation Complete Command Idle State (OCIS) whenever

the No Operation Pending flag is TRUE, at the same time setting the OPC bit of the SESR

TRUE. See IEEE 488.2 Fig 12-4. The following events force the device into OCIS without

setting the No Operation Pending flag TRUE and without setting the OPC bit of the SESR:

KI005power on

KI005receipt of the dcas message (device clear)

KI005execution of *CLS

KI005execution of *RST

KI005Implementation of the *OPC and *WAI commands is straightforward in devices which

implement only sequential commands. When executing *OPC the device simply sets the

OPC bit of SESR. Executing *WAI is a no-operation. The device is, in effect, always in

OCIS.

KI005In devices which implement overlapped commands the implementation of *OPC and *WAI

is a little more complicated. After executing *OPC the device must not set the OPC bit of

SESR until the device returns to OCIS, even though it continues to parse and execute

commands. After executing *WAI the device must execute no further commands or queries

until the No Operation Pending flag is TRUE, or receipt of a dcas message, or a power on.

KI0054.1.3.4 *OPC?

KI005SCPI adds the requirement that *OPC? is implemented as a sequential command.

KI005A device is in the Operation Complete Query Active State (OQAS) after it has executed

*OPC?. The device returns to the Operation Complete Query Idle State (OQIS) whenever

the No Operation Pending flag is TRUE, at the same time placing a “1" in the Output Queue.

See IEEE 488.2 Fig 12-6. The following events force the device into OQIS without setting

the No Operation Pending flag TRUE and without placing a ”1" in the Output Queue:

KI005power on

KI005receipt of the dcas message (device clear)

KI005

1999 SCPI Syntax & Style

SCPI Compliance Criteria 4-3

Implementation of the *OPC? query is straightforward in devices which implement only

sequential commands. When executing *OPC? the device simply places a “1" in the Output

Queue.

KI005The implementation of overlapped commands in a device complicates the implementation of

*OPC? and places some restrictions on the implementation of the Message Exchange

Protocol (MEP). IEEE 488.2 dictates that devices shall send query responses in the order that

they receive the corresponding queries (IEEE 488.2 6.4.5.4). Although IEEE 488.2

recommends that *OPC? be the last query in a program message, there is nothing to prevent

a controller program from ignoring this suggestion. This is why *OPC? must be sequential.

KI0054.1.3.5 *RST

The “*RST Conditions” chapter of Volume 1 gives pretty a lucid description of the SCPI

requirements of *RST. There are, however, some implications.

KI0054.1.3.5.1 Interaction With the Synchronization Commands

KI005*RST stops the execution of any overlapped commands. The natural outcome of this is that

the No Operation Pending flag will go TRUE. Execution of *RST must place the device in

OCIS before setting the No Operation Pending flag TRUE, so that the effect of any pending

*OPC command is nullified (that is, the OPC bit of the SESR does NOT get set).

KI0054.1.3.5.2 Implications For *SAV and *RCL

KI005In devices which implement the optional *SAV and *RCL common commands, the scope of

instrument settings affected by these commands shall be the same as that affected by *RST.

This means that if *RST has any effect upon a command, then so must *RCL. Conversely, if

the device designer wants *RCL to have an effect upon a command, then *RST must also

have an effect upon that command. Inversely, and more importantly, if the device designer

wants a command to be EXCLUDED from the scope of *SAV and *RCL, then it must also

be excluded from the scope of *RST.

KI005KI0054.1.3.5.3 *RST and *RCL as Overlapped Commands

KI005While *RST stops the execution of running overlapped commands, the instrument designer

may find it useful to make the *RST command, itself, overlapped. For example, if resetting

requires the return to an initial position of a slow-reacting, electro-mechanical device. In this

case, performance may be better served with *RST overlapped as subsequent commands

may be parsed and executed while the resetting is completing. Even while overlapped, the

*RST command shall always complete the resetting of device state variables before

subsequent commands are processed to insure the integrity of *RST exception programming.

For similar reasons, *RCL may be an overlapped command.

KI005If *RST or *RCL is overlapped, its Pending-Operation flag shall be reported in the

No-Operation-Pending flag.

KI005If execution of *RST or *RCL causes a device operation which is equivalent to executing an

overlapped command, the device shall set TRUE the Pending-Operation flag associated with

that command.

1999 SCPI Syntax & Style

4-4 SCPI Compliance Criteria

PH022

4.2.2 Optional Commands

All other commands in the “Command Reference” are considered optional, depending on the

capabilities of the instrument. That is, the control of any instrument capability that is

described in SCPI shall be implemented exactly as specified by using the appropriate SCPI

defined commands. For example, an instrument dedicated to voltage measurement would

not implement commands for sensing frequency. Certain commands, if implemented,

require that other commands also be implemented.

When a device does not support all alternative parameter values that are allowed for a SCPI

command, it may implement a subset of these values unless otherwise stated. For example,

if an instrument implements only RECTangular and UNIForm data shaping for its

CALCulate:TRANSform:WINDow command, it may generate an error on receipt of any

other SCPI defined parameter value (FLATtop,HAMMing, etc). However, a device must

implement all parameters of a multi-parameter SCPI command.

Commands required to implement a SCPI-described capability may be omitted under special

conditions. The special condition exists when a command to be implemented affects a part

of the instrument in which the configuration is fixed, and that the fixed configuration for that

command corresponds to the value it would take on when an IEEE 488.2 *RST reset

command is issued. For example, an instrument with a display that is configured to be

permanently on does not need to implement the command that turns the display ON or OFF,

since at *RST it is required by SCPI to be ON. If an instrument has a fixed configuration in

which a setting does not correspond to the *RST value, then the instrument shall implement

the command for that setting even though it has only a single legal value.

4.2.3 Documentation Requirements

The documentation for a SCPI instrument shall list the version number for which the

instrument complies. This information shall appear on instrument specification sheets and

related documents, as well as the programming manual.

HP076The manual for a SCPI instrument shall have a separate section titled “SCPI Conformance

Information”. This section shall list separately:

The SCPI version to which the instrument complies

The syntax of all SCPI confirmed commands implemented by the instrument.

Confirmed commands are those commands which are published in the latest

version of SCPI to which the instrument conforms. Commands in the

DIAGnostic subsystem, and other commands which are not intended for end-user

use need not be documented in this section.

HP000,HP001

The syntax of all SCPI approved commands implemented by the instrument.

Approved commands are those commands which have been approved by the

SCPI Consortium, but are not contained in the version of SCPI to which the

instrument conforms.

HP000

The syntax of all commands implemented by the instrument, which are not part of

1999 SCPI Syntax & Style

4-6 SCPI Compliance Criteria

剩余818页未读，继续阅读

nothingzjc

粉丝: 0
资源: 10

SCPI标准与编程指南

SCPI命令表_(中文版).

SCPI标准命令

osc_address:开放声音控制消息的类型安全路由和基于serde_osc的抽象

studio:跨平台视觉开发工具和SCPI仪器控制器

WinSCP附带el教程

Agilent_33220A中文手册(全套教程)

SQL21日自学通：理解安捷伦N9030A频谱仪SCPI接口协议与基础SQL教程

理解SCPI命令：构建与操作高压气压控制器

Keysight(安捷伦)数字万用表操作与维护及SCPI编程

RIGOL DS1000Z数字示波器SCPI编程指南

最新资源