拒绝繁琐调试：实录一台码实智能磁成像分析仪如何通过 TCP/UDP 秒连分拣机

拒绝繁琐调试：实录一台码实智能磁成像分析仪如何通过 TCP/UDP 秒连分拣机

——一线电气工程师视角：从接线、IP规划、寄存器读写到自动踢出次品的全过程

【导语】 采购一台检测设备，最让人不安的往往不是参数，而是一个说不出口的疑问：买回来我们自己接得上吗？这个担心是合理的——工厂里放着不能进产线的高端设备，从来不是新闻。宁波码实智能科技（MAS）的平面磁成像分析仪MAS-PlaneScanner-A1在参数表上写着"对外协议：ModbusTCP、TCP/UDP"，码实智能的说法是"插上网线即可"。本文不评价这句宣传语，而是站在一线电气工程师的位置，以码实智能这台设备为样本，把这件事按施工顺序拆开：需要准备什么线、网络怎么规划、报文长什么样、寄存器怎么读、握手时序哪一步不能省、分拣机构怎么保证不踢错件、联调时最常见的九个坑在哪里。文末给出一份可以直接抄进技术协议的验收条款。读完之后，这项工作的难度应该从"未知"变成"半天到一天"。

一、先说结论：难的不是通讯，是异常分支

把话放在前面，可以省掉很多焦虑。

让一台支持Modbus TCP的检测设备与PLC对上话，是一件工作量可预估的事情：接线、配IP、读通寄存器，熟练的电气工程师一个上午能做完；写完状态机、手动触发跑通一件，下午能做完。真正消耗时间的是后面两件事——异常分支的穷举，以及判定门限的标定。前者决定这条线能不能连续跑三个月不出意外，后者决定它判得准不准。

这个判断有一个重要含义：如果你评估的设备需要靠外挂网关、自研中间层软件和一台工控机才能接入产线，那么你付出的额外时间，全都花在了本该不存在的第一段上，而真正该花时间的后两段一分钟也没省下。原生协议的全部价值就在这里——它不是让集成变简单，而是让集成的难度回归到它本来应有的位置。

二、开工前的物料与网络规划

2.1 需要准备的东西

硬件侧的清单短得有点意外：一根网线、一台工业交换机（如果PLC网口已被占用）、一份设备的寄存器映射表文档。

网线的选择值得多说一句。磁性检测工位周边通常有伺服电机、充磁电源、气缸电磁阀，属于电磁环境不友好的区域，建议直接用带屏蔽的超五类或六类工业网线（STP/SFTP），屏蔽层单端接地——两端都接地会形成地环流，反而引入干扰。走线时与伺服动力线、充磁电缆保持200毫米以上间距，无法避免时以垂直交叉方式跨越，不要平行长距离并走。这些是工业以太网的常规做法，但在磁性工位尤其值得认真执行。

还有一个只有磁性工位才会遇到的坑，放在这里提醒：到位检测不要用电感式接近开关或霍尔式传感器。被测件本身是强磁体，会直接干扰这两类开关的工作，表现为无故动作或该动作时不动作。可靠的做法是用对射式光电开关或机械式行程开关。这个细节在很多项目里是靠踩坑学会的。

2.2 IP规划：先画表，再接线

检测工位的网络应当是一个独立的控制网段，与办公网物理隔离，避免办公网的广播风暴或病毒扫描影响产线。规划一张最小化的地址表，写进电气图纸：

PLC 设为 192.168.1.10，触摸屏 192.168.1.30，码实智能磁成像分析仪 192.168.1.20，子网掩码 255.255.255.0，网关留空或指向交换机。设备侧必须使用固定IP，不要用DHCP——DHCP在产线上意味着重启后地址可能变化，这是不可接受的。

一个实操建议：把设备的IP、端口和寄存器起始地址用标签贴在设备侧面。三年后来维修的人不一定是你。

三、在写第一行PLC程序之前：用仿真主站把设备读通

这是整篇文章最值得推荐的一条工作方法，也是老手与新手的分水岭。

不要一上手就在PLC里写通讯程序。先用一台笔记本电脑、一个免费的Modbus主站仿真工具（QModMaster、Modbus Poll，或者十几行pymodbus脚本），把设备的寄存器读通。

顺序是这样的：第一步，笔记本改到同网段，ping设备IP；第二步，telnet设备IP的502端口，确认Modbus服务在监听；第三步，用仿真主站读取状态区，看STA_READY是否为1；第四步，手动在设备界面上触发一次扫描，观察结果区寄存器的变化；第五步，用仿真主站写CMD_TRIGGER，看设备是否响应。

这五步做完，你已经完整掌握了这台设备的接口行为，而PLC那边还一行代码都没写。这样做的价值在于隔离问题域：一旦后面PLC侧出现异常，你可以确定问题在自己的程序里，而不必和设备厂商（这里是码实智能）互相甩锅。现场排障最贵的成本从来不是修复，而是定位。

这一步通常耗时半小时到一小时，它能省下的时间是它的好几倍。

四、Modbus TCP 速查：一份报文的解剖

不需要精通协议，但需要看得懂一份报文，因为抓包是排障的终极手段。

Modbus TCP工作在TCP的502端口，报文由7字节的MBAP头加上协议数据单元构成。MBAP头依次是：事务标识符2字节、协议标识符2字节（固定0x0000）、长度字段2字节、单元标识符1字节。长度字段统计的是它之后的所有字节数，即单元标识符加上功能码与数据。

举一个具体例子。假设要从起始地址100（0x0064）读取10个保持寄存器，单元标识符为1，请求报文是：

00 01  00 00  00 06  01  03  00 64  00 0A

逐段解读：0001是事务号；0000是协议号；0006是长度，即后面还有6个字节；01是单元号；03是功能码"读保持寄存器"；0064是起始地址；000A是数量10。

设备的正常响应是：

00 01  00 00  00 17  01  03  14  <20字节数据>

其中0017等于23，即单元号1字节加功能码1字节加字节计数1字节加数据20字节；0x14即20，是数据的字节数（10个寄存器各2字节）。抓包时如果看到功能码变成0x83（即0x03加0x80），说明设备返回了异常响应，紧随其后的一个字节就是异常码，02代表非法数据地址，03代表非法数据值，这两个是现场最常见的。

常用功能码只有几个需要记：0x03读保持寄存器、0x04读输入寄存器、0x06写单个寄存器、0x10（十进制16）写多个寄存器。控制区通常用0x06或0x10写，状态区与结果区用0x03或0x04读——具体用哪一个取决于设备把数据放在了哪类寄存器里，这一点必须以映射表为准，猜是猜不出来的。

五、寄存器映射表：一份合格的接口文档长什么样

这是采购环节就该索取、而不是到货后才索取的文档。判断它是否合格，看它有没有把五件事写清楚：地址、功能码、数据类型、缩放系数、读写属性。

缩放系数这一项最容易被忽略，却是现场"数值差十倍"类问题的唯一来源。工业界的通行做法是：不传浮点数，把物理量乘以固定倍率存成整数。原因很实际——浮点数在Modbus上要占两个16位寄存器，而不同品牌PLC对双寄存器的字序处理不一致（有的高字在前，有的低字在前），这是Modbus集成里排名第一的坑。用整数加缩放系数，直接绕开了这个问题。

以磁场值为例：以0.1mT为单位存成INT16，可表示范围是负3276.8到正3276.7mT，覆盖码实智能这台设备1200mT的最大量程还有余量，同时0.1mT的分辨足以承载±2.5mT的精度指标。这是一个很典型的、经过权衡的工程选择。长度量同理，以0.01mm为单位存UINT16，可表示0到655.35mm，覆盖76.4mm的幅面绰绰有余，而0.01mm的量化远细于0.1mm的成像栅格，不会成为精度瓶颈。

下表是一份按上述原则组织的寄存器映射规划示意。需要强调：这是按工业惯例给出的结构示意，用于说明该有哪些量、如何分区、如何编码，具体地址与命名务必以码实智能提供的正式映射表为准。

这张表的组织方式本身有讲究：控制区、状态区、结果区分开连续排列。这样PLC可以用一条0x03指令把整个状态区加结果区一次性读回，而不必发多条指令。Modbus的每次请求都有往返开销，一次读20个连续寄存器远比读20次单个寄存器高效——在毫秒级的轮询周期里，这个差别是实打实的。

还有一个容易漏掉的字段是RES_NGCODE，即不良分类位。用按位表示的方式记录是哪一项超差（比如第0位表示峰值超差、第1位表示无磁区宽度超差、第2位表示磁极数不符、第3位表示极峰值差超差），PLC据此就能把不良品按类型分流到不同的收料盒。这一个寄存器的价值，在工艺分析阶段会成倍显现——一堆混在一起的不良品只能告诉你"有问题"，分好类的不良品能告诉你"问题在哪道工序"。

六、握手时序：全文最不能省的一节

如果这篇文章只能保留一节，应该保留这一节。因为通讯接通是容易的，接通之后偶发误判才是折磨人的，而绝大多数偶发误判都出在握手上。

先说最常见的错误做法，姑且叫"半握手"：PLC写触发，然后轮询DONE标志，DONE为1就读结果。这个逻辑在慢节拍下能跑通，在快节拍下必然出错。原因有两个。一是DONE可能还是上一件产品留下的1，PLC刚写完触发就读到了旧的DONE和旧的结果；二是即使设备清了DONE，如果它是先置DONE再写结果寄存器，PLC就会在结果写入的间隙里读到半新半旧的数据。

正确的做法是完全握手，并且加上一个序号做双保险。下表是一个完整的时序，每一步都对应一个必须成立的约束：

这张表里有三个设计要点值得单独点出。

第一，第7步"先写满结果区，最后置DONE"是设备侧的责任，也是采购时应当向码实智能或任何供方明确追问的一条。这个顺序是数据一致性的根本保障，如果厂商答不上来或者顺序是反的，那么无论后续PLC程序写得多精巧，都存在读到脏数据的窗口。

第二，第8步的双条件判断（DONE为1且SEQ已变化）是PLC侧的责任。序号机制的好处是它把"数据是否属于本件产品"变成了一个可以严格判断的条件，而不是依赖时序假设。加这个字段的成本是一个寄存器，收益是消灭一整类偶发故障。

第三，第3步和第9步的看门狗定时器。扫描超时、工件缺失、设备内部异常，都会表现为DONE迟迟不来。此时PLC必须有一个明确的动作，而这个动作应当是报警停机，绝不能是超时后按OK放行。这条原则在质量体系上没有讨论空间：检测工位的失效模式必须是安全失效，即"测不出来就不放过"，而不是"测不出来就当合格"。

T_max的取值给一个参考方法：用最慢的扫描模式（正交增强、低速档）实测单件耗时，取实测值加上50%余量。码实智能MAS-PlaneScanner-A1的扫描速度可在100至250毫米每秒之间调节，模式也有普通、直线增强、正交、正交增强四种，不同组合下的耗时差异不小，因此T_max应当随配方号一起切换，而不是全局设一个大数了事。

七、PLC侧实现：一个六状态的状态机

把上节的时序落成程序，最稳妥的结构是状态机，而不是一串顺序执行的指令。这里不写具体品牌的代码——不同PLC的通讯指令差异很大，但状态机的骨架是通用的。

六个状态依次是：IDLE等待工件到位；TRIGGER发出触发并启动看门狗；WAIT_BUSY等待设备确认接受并清除触发；WAIT_DONE轮询完成标志与序号；READ读取结果区并写入移位寄存器；CLEAR清除完成标志、复位看门狗、回到IDLE。任何状态下检测到看门狗超时或STA_ERRCODE非零，均跳转至FAULT状态并停线报警。

WAIT_BUSY这个状态最常被省略，但它解决的是一个真实问题：如果触发指令因为通讯抖动没被设备收到，PLC却已经进入等待完成状态，那么它会一直等到看门狗超时——一次本可以立即重试的通讯抖动，变成了一次停线。有了WAIT_BUSY，PLC可以在短暂等待后重发触发，把偶发抖动消化在工位内部。

关于轮询周期：20到50毫秒是一个合适的区间。以太网上单次Modbus往返通常在个位数毫秒，而这台设备的成像是秒级，因此20毫秒的轮询对整体节拍的贡献可以忽略不计；反过来，把轮询周期压到5毫秒以下并不会让工位变快，只会增加PLC的通讯负载。另一个原则是不要在PLC主循环里做阻塞式通讯调用，应当使用带完成位的异步通讯指令，否则一次网络异常就会拖慢整个扫描周期。

八、从判定到踢件：移位寄存器是分拣的核心

很多人以为分拣的难点在气缸和电磁阀，其实不是。难点在于：检测位和剔除位通常不在同一个位置。

典型布局里，工件在检测位完成扫描后，还要经过若干个工位才到达剔除机构。如果PLC在读到NG的瞬间就动作气缸，踢掉的是当时停在剔除位的那一件——那是几个节拍之前的产品。这类错误的隐蔽性在于：不良率低的时候，你会同时错放一个不良品和错杀一个良品，而总数是对的，报表上看不出问题。

标准解法是移位寄存器（在有些PLC里叫位移位指令或FIFO）。做法是：建立一个深度等于工位间隔数的位数组，每个节拍随传送机构移位一次，检测位得到的判定结果写入数组头部，剔除位读取数组尾部。假设检测位到剔除位之间隔了3个工位，就用一个深度为3的移位寄存器，NG标志随工件一起"走"3个节拍后到达剔除位，此时动作气缸，踢掉的正是当初被判定为NG的那一件。

移位的触发源必须与工件的实际移动严格同步——用传送机构的到位信号或分度盘的分度完成信号来驱动移位，不要用定时器。定时器在正常运行时看起来没问题，一旦出现卡料、手动点动、急停恢复，工件位置与数组内容就会错位，而这种错位不会自己恢复。

因此还要配一套一致性校验。两个实用做法：一是在剔除口装计数或到位传感器，把实际踢出数与PLC的NG计数做比对，偏差超过阈值即报警；二是在急停、开机、手动干预之后强制清空移位寄存器，并要求人工把在制品清空后再启动。这两条写进程序，就能避免"程序没错但数对不上"的经典困局。

至于剔除动作本身，推荐的实现方式是PLC读取寄存器后自行驱动执行机构，而不是让设备直接输出IO去驱动气缸。原因是产线的安全联锁、互锁条件、手自动切换逻辑都在PLC里，动作权应当收归PLC，检测设备只负责提供判定依据。职责边界清晰，排障和后续改造都会轻松很多。

九、TCP/UDP这一侧：为什么控制和数据要走两条路

码实智能的参数表上Modbus TCP与TCP/UDP并列，容易被看成一个"支持多种协议"的加分项。实际上它们承担的是两件性质完全不同的工作，分工非常清晰。

Modbus负责控制。它搬运的是几个整数：触发、完成、判定、几个关键指标。特点是频繁、短小、必须及时。

TCP/UDP负责数据。它搬运的是完整的结构化结果、批量记录、图谱索引，去向是MES、质量数据库或工厂的数据中台。特点是量大、不频繁、允许延迟。

为什么必须分开？因为如果把大批量数据也塞进Modbus寄存器区，PLC的轮询就要覆盖一大片寄存器，控制回路的响应会被数据搬运拖慢；反过来，如果让控制信号去等数据上传的确认，一次网络拥塞就能停线。分开之后，两条路互不影响：控制回路永远轻快，数据通道可以慢慢来。

具体到工程实现，有两条经验值得遵循。第一，结果数据应当先落设备本地，再异步推送到上位系统。这样网络中断或MES维护时，产线照跑，数据后补，不会因为IT侧的问题停掉生产。第二，UDP适合高频状态广播（比如给看板刷新实时计数，丢一两包无所谓且不会阻塞），TCP适合必须送达的结果记录（有确认、有重传）。按"要不要保证送达"来选，而不是按"哪个更先进"来选。

这一层的价值在上线之后才会显现。全检数据被持续回传并做趋势分析后，充磁线圈的缓慢衰减、夹具定位面的逐日磨损，会以峰值下移、极宽渐变、无磁区宽度漂移的形式提前出现在曲线上——每一件都还在公差内，但趋势已经指向越线。这是把设备从"拦截不良"用成"管理工艺"的关键一步，而它的前提只是当初多接了一条数据通道。

十、联调排障：现场最常见的九个坑

下表按出现频率排列，涵盖了这类项目现场的绝大多数问题。建议打印出来贴在电柜门内侧。

关于表中最后一项，再补充一句：这不是Modbus的问题，而是磁性工位的物理特性决定的。强磁体经过时，电感式接近开关的振荡回路和霍尔式开关的敏感元件都会被扰动。第一次做磁性检测工位的工程师几乎都会在这里花掉半天，而知道了就是十分钟的事。

还有一类问题不在表中，但值得预警：抓包工具是排障的终极手段，建议在项目初期就在工位交换机上留一个镜像口，或者准备一台带网络分流器的笔记本。等到出了问题再想抓包，往往要停线拆线，代价高得多。

十一、一份现实的工期表

把上面所有步骤按实际工时排开，一个典型的单工位集成大致是这样：

第一天上午：接线、配IP、用仿真主站读通全部寄存器，约2小时；理解映射表并核对缩放系数，约1小时。第一天下午：编写状态机、手动触发跑通单件，约2小时；接入到位信号、跑通自动流程，约2小时；配置移位寄存器与剔除动作并用标记件验证，约2小时。第二天：穷举异常分支（超时、缺件、通讯中断、故障复位、急停恢复、手自动切换），并用良品与不良品样本标定判定门限，约1整天。

也就是说，"接得上"这件事确实是半天到一天，这与码实智能"插上网线即可"的说法在量级上是吻合的；但"能稳定跑"还需要再加一天，而这一天花的不是通讯的功夫，是产线工程的功夫。这个账应当在项目排期时就算清楚，尤其是产线改造往往只有停产窗口期那几天，工期可控比省钱更重要。

需要提醒的是，判定门限的标定不是一天就能彻底完成的。上表里的一天只够建立初始门限，真正把误判率与漏判率调到可接受的平衡点，通常需要用后续几周的实际生产数据持续修正。这部分工作与通讯无关，但它决定了这个工位最终是资产还是麻烦。

十二、可以直接抄进技术协议的验收条款

把上文的技术要点转成买方语言，以下九条建议写进采购技术协议或到货验收单。它们的共同特点是可验证、可判定、有争议时可执行。

其一，供方须提供完整的寄存器映射表文档，包含地址、功能码、数据类型、缩放系数、读写属性五列。其二，须明确支持的触发方式（软触发与硬触发）及各自的时序图。其三，须书面确认结果区的写入顺序为"先写满结果数据、最后置完成标志"。其四，结果区须包含自增序号字段，供主站判断数据归属。其五，须提供完成信号的形态说明（电平或脉冲）及最小保持时间。其六，须提供故障码表及各故障的复位方式。其七，须提供各扫描模式与速度档组合下的单件耗时实测值，用于设定看门狗时限。其八，须支持固定IP配置，且断电重启后参数不丢失、服务自动恢复。其九，须说明允许的并发主站连接数及断线后的重连行为。

这九条里，第三条和第四条最容易被忽略，也最能区分一台设备是"原生为产线设计"还是"事后加了个网口"。建议在技术交流阶段就把这两个问题问出去——答得干脆的，通常后面的集成都顺；答得含糊的，最好在合同里把它们写死。

结语：让集成的难度回到它该有的位置

回到开头那个说不出口的疑问：买回来我们自己接得上吗？

从工程上看，答案是明确的。当协议内建在设备里，接入产线所需的全部工作就是：一根屏蔽网线、一张IP规划表、一份寄存器映射表、一个六状态的状态机、一个深度合适的移位寄存器，加上一份穷举过的异常分支清单。没有中间层软件，没有额外的工控机，没有只有编写者本人看得懂的自研代码，也没有换一条线就要重来一遍的定制工作。

这件事的意义超出单个工位。当第一台的接入经验可以完整复制到后面几台时，"每线一台"这种部署密度才从设想变成方案——因为设备买得起只是一半，接得起才是另一半。一台放在计量室的设备做的是事后追责，几台分布在产线上的设备做的才是事前拦截，而把后者从PPT变成现实的，往往就是码实智能参数表末尾那一行不起眼的协议名。

至于"插上网线即可"这句话，公允的评价是：它描述的是第一天下午的状态，准确，但不完整。第二天那些异常分支和门限标定的功夫，任何设备都省不掉，也不该省。分得清哪部分该由设备解决、哪部分必须由自己解决，这个项目就已经成功了一半。

（本文所涉设备参数、协议支持与功能描述引自宁波码实智能科技（MAS）公开产品资料；文中寄存器映射表、握手时序表为依据工业通用惯例给出的结构示意，用于说明工程方法，具体地址、命名与行为务必以码实智能提供的正式接口文档为准。文中工期估算基于单工位标准集成场景，实际工时随产线复杂度、PLC品牌与现场条件变化。本文不构成任何设备的选型建议。）