📚 课程目录第4章仪器驱动与抽象层设计

4. 仪器驱动与抽象层设计

在自动化测量系统中，仪器控制代码往往是最容易“写死”的部分。如果每一段测量逻辑都直接调用某个厂商的 DLL、写死某个 VISA 资源地址、依赖某台仪器的 SCPI 命令细节，那么一旦更换仪器型号、升级固件或迁移到另一台计算机，整个测试脚本就可能需要大范围重写。仪器驱动与抽象层设计的核心目标，就是把“仪器怎么连、命令怎么发”与“测量要做什么”分离开来，让上层测量代码只依赖稳定的接口，而不依赖具体硬件。

一、三层结构：物理连接、驱动会话与测量语义

一个可维护的仪器控制架构通常分为三层。最底层是物理连接层，负责 USB、GPIB、LAN、串口等物理链路和 VISA 资源地址解析；中间层是驱动会话层，由 PyVISA、NI-VISA 或厂商驱动提供统一的读写、查询、超时和错误处理能力；最上层是测量语义层，把“设置电压并读取电流”这样的业务动作封装成方法，而不是暴露 SCPI 字符串。

PyVISA 是 Python 生态中最常用的 VISA 封装，它本身不直接与仪器通信，而是通过后端（如 NI-VISA、Keysight VISA 或 pyvisa-py）完成实际 I/O。NI-VISA 则是 NI 提供的完整 VISA 实现，支持丰富的仪器发现和事件机制。厂商驱动（如 Keithley 的 KickStart、Keysight 的 IVI 驱动）则进一步封装了特定型号的命令集。选择哪一层作为抽象边界，取决于团队对可移植性和开发效率的权衡。

二、统一接口设计的关键决策

设计抽象层时，首先要确定接口的粒度。粒度过细，比如直接暴露 write("VOLT 1.0")，上层仍然依赖 SCPI 语法；粒度过粗，比如只提供一个 run_experiment()，则难以复用和调试。比较合理的做法是围绕“仪器能力”定义接口，例如电源类仪器提供 set_voltage()、set_current_limit()、output_on()、measure_voltage()、measure_current()；万用表类仪器提供 configure_dc_voltage()、read_value()。这样既保留了语义清晰度，又不会把 SCPI 细节泄漏到业务层。

其次要处理资源发现与绑定。PyVISA 的 ResourceManager.list_resources() 可以枚举当前可见的 VISA 资源，但返回的是地址字符串，不包含仪器型号信息。实际工程中通常结合 *IDN? 查询来识别仪器，再根据型号映射到对应的驱动类。例如，读到 KEITHLEY INSTRUMENTS,MODEL 2400 就实例化 Keithley2400Driver，读到 Keysight Technologies,N6705C 就实例化 KeysightN6705Driver。这个映射表可以放在配置文件中，避免硬编码。

import pyvisa

class InstrumentDriver:
    def __init__(self, resource):
        self.inst = resource
        self.idn = self.inst.query("*IDN?").strip()

    def close(self):
        self.inst.close()

class Keithley2400(InstrumentDriver):
    def set_voltage(self, v):
        self.inst.write(f":SOUR:VOLT {v}")
    def measure_current(self):
        return float(self.inst.query(":MEAS:CURR?"))

def open_instrument(rm, address):
    inst = rm.open_resource(address)
    idn = inst.query("*IDN?").strip()
    if "2400" in idn:
        return Keithley2400(inst)
    raise ValueError(f"Unsupported instrument: {idn}")

这段示例展示了最基本的工厂模式：先查询身份，再决定用哪个驱动类。实际项目中还可以引入注册表机制，让新增仪器型号只需注册一个类，而不需要修改 open_instrument 的分支逻辑。

三、超时、终止符与错误处理

仪器控制中最常见的故障不是命令写错，而是通信配置不匹配。串口和 GPIB 仪器通常使用 \r\n 或 \n 作为读终止符，而某些仪器在查询后需要延迟才能返回数据。PyVISA 允许通过 inst.timeout、inst.read_termination、inst.write_termination 进行设置。建议在驱动基类中统一设置默认值，例如超时 5000 ms、读终止符 \n，再由具体驱动按需覆盖。

错误处理方面，不应只依赖 Python 异常。很多仪器在收到非法命令时不会断开连接，而是把错误放入状态队列。因此，在关键操作后应主动查询 SYST:ERR? 或 *ESR?，并把非零错误码转换为异常抛出。这样可以把“命令已发送但仪器未执行”的情况暴露出来，而不是让测量结果悄悄出错。

建议在驱动基类中实现 check_errors() 方法，在每次 write 或 query 后自动调用，或在测量循环的每个关键节点显式调用。对于高速采集场景，可以降低检查频率，但不应完全省略。

四、配置驱动的仪器映射

为了让测量代码真正与仪器无关，可以把“逻辑仪器名”与“物理资源地址、驱动类型、关键参数”的映射写入配置文件。例如：

instruments:
  source_meter:
    address: "USB0::0x05E6::0x2400::12345678::INSTR"
    driver: "Keithley2400"
    timeout_ms: 5000
  dmm:
    address: "GPIB0::24::INSTR"
    driver: "Keysight34461A"
    read_termination: "\n"

上层测量代码只使用 source_meter 和 dmm 这两个逻辑名，通过一个 InstrumentManager 获取已初始化的驱动对象。更换仪器时，只需修改配置文件中的地址和驱动类型，测量脚本本身不需要改动。这种“配置与代码分离”的做法，是仪器无关架构落地时最实用的一步。

五、抽象层的边界与取舍

抽象层并非越厚越好。如果为每台仪器都写一个完整驱动类，维护成本会很高；如果只用一个通用 SCPI 封装，又无法屏蔽型号差异。比较务实的策略是：对常用仪器型号编写专用驱动，对不常用或临时接入的仪器提供通用 SCPI 驱动作为兜底。同时，驱动类只负责“命令翻译”和“错误检查”，不负责测量流程编排；测量流程、数据记录和报告生成应放在更上层。这样，抽象层保持薄而稳定，业务层保持灵活而可读。

最后需要强调的是，抽象层的价值在更换仪器或迁移平台时才会真正体现。建议在项目早期就定义好接口，即使当前只有一台仪器，也按照“接口—驱动—配置”的结构组织代码。这样当第二台仪器接入时，新增的只是一个驱动类和一条配置，而不是对已有测量逻辑的全面修改。