没有驱动的老仪器，LabVIEW 三天怎么接上

改造老设备最常被问的一个问题是：「这台仪器有 LabVIEW 驱动吗？」

没有。厂商手册最后一版是十几年前的，官网上的驱动下载链接早就 404，NI 的仪器驱动库里也搜不到型号。

但这不代表接不上。这套系统里同时跑着三台这样的设备，都是没有现成驱动的老家伙：

Lake Shore 325 温度控制器------低温回路，RS-232 走 SCPI
Eurotherm 2404 过程控制器------加热回路，RS-232 走 Bisync
ORTEC 996 计数器/定时器------离子计数链路末端，RS-232 走纯 ASCII 命令

三台设备，三种协议脾气，全在 COM3 到 COM11 这几个串口上。接通的路径是同一条：手册定方向，监听定细节。

第一种：协议标准，直接说人话

Lake Shore 325 是最省事的一台。它跑 SCPI------这是仪器界最通用的命令集，和 GPIB 时代的那些仪器一脉相承，只是搬到了串口上。

读温度就是一句查询，设设定点就是一句写入，PID 参数、量程、传感器类型都是标准命令。LabVIEW 里有现成的 VISA 读写节点，串口参数配好（波特率、数据位、停止位、校验），拼字符串发出去就行。

对着这台设备，要做的判断只有两个：

通信参数对不对------波特率错一位，收到的全是乱码
命令终结符对不对 ------有的设备认 \n，有的认 \r\n，有的要 \r。这个错的表现是"命令发出去了，没反应"，很容易误判成线接错了

这台设备接上之后，做的是持续记录：两路温度、设定点、PID 状态，每帧测量数据都带上当时的温度值。

温度在这里不是"环境条件"，是数据的一部分。 低温下传感器灵敏度会漂，零点会移，如果测量数据不记录温度，事后出了问题根本没法回溯是哪一段温度区间造成的。数据可信度不是靠事后解释，是采集那一刻就写进去的。

第二种：协议偏门，得先把报文抓下来

Eurotherm 2404 就麻烦了。

它支持 Modbus 和 Bisync 两种协议。这套系统里跑的是 Bisync------一个比 Modbus 老得多的同步协议，手册编号 HA025132。

串口参数是 9600, E, 7, 1：9600 波特，偶校验，7 位数据，1 位停止。注意是 7 位数据，不是通常的 8 位------这一条错，整个通信就废了。

报文长这样：

复制代码

STX '0' '0' '1' '1' '1' 'P' 'V' ENQ

STX 是帧头，ENQ 是询问符，中间那一串是设备地址加参数码。设备回过来是：

复制代码

>1PV24

> 应答，1 地址，PV 是过程值（Process Value），24 是数值。

对着手册能看懂格式，但"具体该怎么拼"这件事，手册往往说不全------地址位怎么排、参数码有哪些、校验怎么算、连续读两个参数要不要重新同步，这些细节手册里要么没有，要么散在几十页里。

这套系统用的办法很土，但很有效：先用串口监听工具，把原控制软件（Rainbow / TecMass）和老设备的收发报文全抓下来，逐字节看。

老软件能正常跑，说明它发的每一帧都是对的。那么把它发的东西原样复现，新软件就一定对。这比啃手册快得多，也准得多。

抓完报文，在 LabVIEW 里按同一格式重建。新软件和老设备之间是"无感对接"------设备那边完全不知道控制它的软件换了。

顺便留了一手：软件层预留了 Modbus 分支。将来这台 2404 换成 2408，或者别的欧陆表，切协议引擎就行，业务逻辑不用动。

第三种：读数差了 100 倍

ORTEC 996 的故事最典型，也最值得说。

它是 NIM 标准插件式的定时计数器，串在放大器之后，负责给离子计数。控制命令是一组纯 ASCII：

复制代码

INIT
STOP
SET_MODE_SECONDS
SET_COUNT_PRESET 5,1
ENABLE_ALARM
START
CLEAR_COUNTS

每条命令回一个 ACK 码，形如 %00000069。计数结果回来是 00000244; 这种格式。

驱动写得很顺。问题出在切换那天：新软件的读数，比老软件大了约 100 倍。

两台软件各自都和 996 的前面板显示一致。这就很要命了------如果有一边错，好办；两边都跟面板对得上，那错在哪？

这时候最容易犯的错误是开始猜参数：是不是预置值设错了，是不是闸门时间单位不一样，是不是计数器分频比有问题。猜一个改一个，改完还是不对，越猜越乱。

正确的做法是回到协议层。用串口侦听，把老软件和 996 的完整交互序列逐字节比对。

一比就出来了：老软件的读取序列和新软件不一样。老软件在计数结束后先发了某条命令，再读；新软件少了一步。而这个差别导致读回的是另一个寄存器的值------位数不同，所以差了 100 倍。

问题定位到协议层，改一行代码，通了。

这件事说明的规律比结论本身重要： 老设备不可怕，协议不透明才可怕。只要交互是明文的、可监听的、可复现的，任何差异都能查到字节级。反过来，如果协议是加密的、二进制的、厂商私有且不公开的，那再多的经验也只能靠试。

三天是怎么算出来的

前两台设备，从拿到手册到打通通信，各用了一天左右。

第三台（996）的命令简单，半天就通了，剩下的时间全花在那 100 倍的问题上------排查比开发花的时间多，这是老设备改造的常态。

三天这个数字不是流程时间，是**"手册 + 监听"这套方法在正常情况下的效率**。前提是：

手册能拿到（哪怕是扫描件）
原控制软件还能跑（哪怕只能跑一次，够抓报文就行）
物理链路是标准的（RS-232、GPIB、网口，不是某家的专用板卡）

三条缺一条，时间就不好估了。

一套通用的接入流程

做了几台之后，流程基本固定了：

确认物理层------线怎么接、电平对不对、要不要交叉线
确认通信参数------波特率、数据位、停止位、校验、流控、终结符
抓一份能正常工作的报文------有老软件就抓老软件，没有就照手册发一条最简单的查询
在 LabVIEW 里做最小闭环------先只读一个量，能读通再往下做
把原始报文落日志------这一条最容易被省，也最有用
再往上叠业务逻辑------扫描、判定、存储、报警

第 5 步值得单独说。所有收发报文都落日志，出问题的时候回放日志就能取证：是命令发错了，是设备没回，还是回了个异常码。有日志，排查是按分钟算的；没日志，排查是按天算的。

判断一台老仪器能不能接，其实就问三句：接口是标准的不？协议是能看懂的不？有办法抓到一份正常工作的报文不？

前两条看手册就知道，第三条看现场。三条都过，接不上的情况我还没遇到过。