控制器对接：西门子、三菱、欧姆龙、台达和汇川怎么接

MES 真正进现场以后，第一件让软件工程师不适应的事，往往不是业务复杂，而是设备太“各说各话”。

西门子有西门子的工程习惯，三菱有三菱的软元件地址，欧姆龙有 FINS，台达和汇川常见 Modbus。再加上扫码枪、测试机、视觉设备、老设备串口、厂商 SDK，现场接入很快就会从“读几个点位”变成一场细活。

这篇不讲大架构，专门讲控制器怎么接。

我会把它当成一次现场联调来写：先拿设备清单，再拿点位表，再确认协议，最后才写采集程序。

控制器对接这件事，文档看起来通常很清楚。

地址、寄存器、数据类型、读写周期，表格一列，好像照着做就行。但现场一接，才会发现每个品牌、每台设备、甚至每个改造过的柜子都有自己的脾气。

有的点位刷新慢，有的信号要组合判断，有的设备断电后状态保持，有的网关会丢一小段数据。

所以控制器对接不能只按协议写代码，还要按现场行为做验证。

一、先别急着写协议客户端

到现场第一天，我最想要的不是 PLC 型号，而是两张表。

第一张是设备清单：

设备编号
设备名称
产线 / 工位
品牌和型号
控制器型号
通信方式
IP / 端口 / 串口参数
是否允许写入
电气负责人

第二张是点位表：

点位编码
点位名称
地址
数据类型
单位
读写权限
采样周期
业务含义
报警规则
存储策略

没有这两张表，后面的开发很容易靠猜。

最怕的是软件侧读到了一个地址，数值也在变，但没人能确认它到底代表设备运行、工位节拍、产量计数，还是一个临时调试变量。

这时候程序写得再漂亮，也是在不确定的地基上跑。

二、西门子：OPC UA 更清楚，但要先确认权限

西门子 S7-1200 / S7-1500 在新项目里比较常见。

如果现场条件允许，我更倾向于优先考虑 OPC UA。西门子官方文档里提到，S7-1500 CPU 从固件 2.0 开始带 OPC UA Server 能力，客户端可以访问 CPU 上开放出来的变量和方法。

OPC UA 的好处是语义更清楚。

MES 边缘层看到的可能是 Line01.Screw01.Running，而不是一个裸地址。后续点位维护、权限控制和变量命名都会更友好。

但 OPC UA 不是一句“支持”就结束。

现场要确认：

CPU 型号和固件是否支持。
是否需要许可证或启用配置。
证书和安全策略怎么配。
哪些变量允许暴露。
变量命名是否稳定。
读取周期会不会影响 PLC。
MES 是只读，还是允许写入。

如果不用 OPC UA，而是通过 S7 通信或其他方式读取 DB 块，就要确认 DB 块是否开放访问、地址是否会变、变量是否有优化访问限制。

我的习惯是：MES 默认只读。

启停设备、复位报警、修改配方这类写操作，不应该随便开放给业务系统。真要写，也要有权限、审计、联锁和电气侧确认。

三、三菱：软元件地址表必须版本化

三菱 MELSEC 现场常见 MC Protocol / SLMP。

它不像 OPC UA 那样天然带变量语义，更多是在读软元件地址，比如 D、M、X、Y 等区域。三菱官方 SLMP 资料里也把 MC Protocol 描述为访问兼容设备或可编程控制器的通信协议。

这类接入最重要的是地址表。

比如：

D100: 当前工单产量
D102: 良品数
D104: 不良数
M200: 设备运行
M201: 设备报警
M202: 自动模式

这张表必须由电气侧确认，最好版本化保存。

因为地址一旦变了，MES 读到的值可能仍然在变化，但语义已经错了。系统不会报错，只会悄悄变脏。

接三菱时还要确认：

TCP 还是 UDP。
ASCII 帧还是二进制帧。
一次批量读取多少地址。
不同数据区是否能合并读取。
读取周期是否会给 PLC 带来压力。
设备型号是否支持对应 SLMP 功能。

不要每个点位单独发一次请求。

现场点位多起来以后，这种读法效率差，也更容易触发超时。能批量读，就尽量按连续地址规划。

四、欧姆龙：FINS 不只是填一个 IP

欧姆龙控制器常见 FINS/UDP、FINS/TCP，也可能走 EtherNet/IP 或由上位软件转接。

FINS 的麻烦在于，它不是只填一个 IP 就完事。

现场经常要确认：

FINS/UDP 还是 FINS/TCP。
本机节点号。
目标节点号。
网络号。
内存区，比如 DM、CIO 等。
目标 CPU 是否允许 FINS 命令。
防火墙或包过滤是否放行。

欧姆龙 NX 系列 FINS 功能手册里也明确提到，若启用了 Packet Filter，需要允许接收 FINS 命令，否则客户端会超时。

所以“能 ping 通，但读不到数据”，不一定是程序错了。

也可能是节点号、网络号、包过滤、PLC 设置或端口策略没配对。

这类问题最好现场和电气一起抓包或逐项核对，不要只在软件里改来改去。

五、台达、汇川：Modbus 简单，但坑也朴素

台达、汇川这类现场常见 Modbus RTU / Modbus TCP。

Modbus 的优点是通用、简单、资料多。缺点是它把很多语义都交给点位表了。

你读到 40001，并不知道它代表什么。

你读到两个寄存器，也不知道它是 int32、float，还是两个独立 int16。

所以 Modbus 对接时要重点确认：

站号或 Unit ID。
功能码：01、02、03、04、05、06、16。
地址是否从 0 开始，还是从 1 开始。
Holding Register 和 Input Register 有没有混用。
32 位和 64 位数据的字节序。
有符号和无符号。
缩放系数，比如读到 253 实际表示 25.3 摄氏度。
轮询间隔。

汇川 H5U 相关资料里可以看到，它支持基于 RS485 的 Modbus RTU 和基于以太网的 Modbus TCP；汇川欧洲产品资料也提到 H5U 以太网连接支持 Modbus TCP 和 Socket 编程指令。这些信息能帮助我们先判断接入路线，但最终还是要回到现场点位表。

Modbus 最常见的坑，是地址偏移和字节序。

同一个浮点数，不同设备可能是：

ABCD
BADC
CDAB
DCBA

如果读错，数值不是轻微偏差，而是完全离谱。

六、不要只盯 PLC，测试机和扫码枪也很关键

MES 不只接 PLC。

扫码枪可能是串口，也可能是 TCP Client，扫到条码后主动推送。

测试机可能把结果写 CSV，或者写本地数据库，或者提供 HTTP API。

视觉设备可能通过 TCP Socket 推送 OK/NG、缺陷代码和图片路径。

这些设备的接入方式更杂，但它们对追溯很关键。

如果测试结果没有绑定 SN，追溯就断了。

如果扫码枪重复扫，系统没有去重，工序记录就会乱。

如果视觉图片只留在本地工控机，过几个月再查质量问题，可能已经找不到图片。

所以我会把这些非 PLC 设备也纳入边缘采集层，而不是让 MES 业务服务直接去读文件、连串口、查中间库。

边缘层负责适配，中心系统只接收统一事件：

barcode_scanned
test_completed
vision_result_created
equipment_alarm
process_passed

这样后面的业务模型才不会被设备差异拖乱。

七、现场联调要一步一步来

控制器对接不要一上来就接 MES 全链路。

我更倾向于按这个顺序来：

1. 网络连通：IP、端口、VLAN、防火墙。
2. 协议连通：能否读到一个测试点位。
3. 数据校验：数值、单位、字节序、缩放系数是否正确。
4. 点位批量读取：确认轮询周期和 PLC 压力。
5. 业务绑定：设备状态、产量、报警、测试结果对应到 MES 模型。
6. 异常测试：断网、重连、PLC 重启、边缘服务重启。
7. 只读边界确认：哪些点位绝不允许 MES 写入。

每一步都要留下记录。

否则上线后出了问题，很难判断是网络问题、PLC 配置问题、点位错误、协议解析错误，还是 MES 业务处理错误。

八、小结

控制器对接这件事，真正难的不是某一个协议。

难的是把现场差异收敛成稳定的设备接入模型。

西门子可以优先看 OPC UA，三菱要重视软元件地址和批量读取，欧姆龙要确认 FINS 网络和节点配置，台达、汇川这类 Modbus 场景要盯紧地址偏移和字节序。

测试机、扫码枪、视觉设备也不要忽略，它们往往决定质量追溯能不能闭环。

MES 边缘层的价值，就是让这些复杂度留在现场适配层，不要扩散到业务系统里。

参考资料

本系列：