SCPI-99：可编程仪器标准指令全英文版

需积分: 25 117 浏览量更新于2024-07-20 收藏 3.22MB PDF 举报

"这是关于SCPI (Standard Commands for Programmable Instruments) 99版的文档，全英文原版，由SCPI Consortium在1999年发布。文档详细定义了SCPI标准，旨在供测试和测量市场全面考虑和采用。用户被授权复制整个文档或其部分，但必须保留版权及复制许可声明。" SCPI（标准可编程仪器命令）是一种通用的、基于ASCII的通信协议，用于控制和配置各种类型的电子测试设备，如示波器、信号发生器、数字多用表等。该标准的制定旨在提供一种标准化的方法，使不同厂商的仪器能够通过相同的命令集进行编程，从而简化测试系统的集成和自动化。 SCPI-99版本是SCPI标准的重要更新，它在1999年由SCPI Consortium发布，这个组织是由多家仪器制造商组成的，致力于推动标准化工作。文档的"Syntax and Style"部分通常会详细解释SCPI命令的语法结构和风格指南，包括： 1. **命令结构**：SCPI命令通常由命令头、操作符、参数和可能的子命令组成。命令头通常以":"开头，例如"SYST:ERR?"用于查询系统错误。 2. **数据类型和格式**：SCPI支持多种数据类型，如字符串、数值（浮点和整数）、布尔值等，并规定了它们在命令中的表示方式。例如，数值可以使用E-notation（科学记数法）或固定点表示。 3. **路径和命名约定**：SCPI允许使用层次化的命名结构来访问仪器的不同功能，如"CH1"代表第一个通道，"FUNC"可能代表函数选择。 4. **询问与响应**：SCPI支持询问-响应机制，即命令可以带有问号（?），如"VOLT?"，用来获取当前电压值。仪器将返回一个响应，通常是符合预定格式的数据。 5. **错误处理**：SCPI定义了如何报告和处理错误，包括错误代码和错误消息。 6. **风格指南**：为了保持一致性，SCPI建议使用特定的命名和缩写规则，如使用大写字母表示命令，用下划线代替空格等。 7. **命令子系统**：SCPI允许创建嵌套的命令子系统，使得复杂的仪器功能可以组织得更加有序。 8. **扩展性**：标准允许制造商添加自定义命令，以扩展标准功能，但这些自定义命令仍需遵循基本的SCPI语法，以保持兼容性。 9. **错误检查**：SCPI提供了错误检查机制，确保输入的命令是有效的，防止因误操作导致的设备损坏。 SCPI的实施促进了仪器间的互操作性，减少了用户学习新设备控制语言的时间，同时也降低了软件开发的成本。了解并熟练掌握SCPI-99标准对于进行仪器自动化测试和系统集成的工程师来说是至关重要的。通过阅读这个英文原版文档，用户可以深入理解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页未读，继续阅读

fjun_1118

粉丝: 0
资源: 5

SCPI-99：可编程仪器标准指令全英文版

SCPI 1999 PDF WORD.rar

SCPI-1999.pdf

SCPI程控仪器标准命令

java-scpi-parser

csdn scpi-1999

scpi-by-c51.rar

c scpi-parser

SCPI编程指南手册下载

程控仪器标准命令scpi

c#程控仪器 SCPI

最新资源