汇川机器人与PLC的ModbusTCP通信：从配置到寄存器规划实战

去年我接过一条汽车零部件装配线的改造，设备已经运行了三年多，原来的方案是机器人跟PLC之间走硬接线I/O，光是上下料工位就有将近40个信号点，柜子里继电器排了两层。改造的时候甲方要求加两台汇川机器人做协同搬运，信号点数直接翻倍，旧柜体根本塞不下，最后我把机器人和PLC之间的通信整体换成了ModbusTCP，用网线替代了那捆直径快赶上手臂的电缆。这篇文章就把整个改造过程中踩过的坑、配置步骤和寄存器规划完整记录下来，给后面接手这类项目的朋友做个参考。

先说个结论：汇川机器人与PLC之间走ModbusTCP，不是唯一方案，但在“要改点表、要扩信号、预算有限、现场有交换机”的前提下，它是我认为最经济、最不容易出错的方案。下面从方案选型开始，一步步讲。

1. 机器人通信方案选型：为什么我最后锁定了ModbusTCP

1.1 传统I/O接线方案的隐性成本

很多老工程师习惯机器人跟PLC之间用硬线I/O，每个信号点一根线，电源、公共端、屏蔽层算下来，40个点就要接近60根线。线多不是最可怕的，最可怕的是改造周期内的点表变动。这个项目里甲方中途改过一次检测信号逻辑，本来只用改PLC程序，硬接线方案要动柜内端子排、重新捋线、标记线号，总共花了两个晚上。而通信方案里，改点表只需要在配置文件里改两行地址映射，五分钟搞定。

另一个隐性问题是信号抖动。硬接线在电柜里走线距离长，电焊机、变频器一启动，感应电压经常把I/O点打跳，轻则报警，重则误动作撞机。我还在现场见过地电位不一致导致两个柜体之间的I/O信号一直不稳的情况。通信方案在抗干扰和自诊断能力上明显更强。

1.2 ModbusTCP在工业通信里的定位

这里得先把各种通信方式摆在一起说清楚，大家才知道选择依据是什么。

汇川机器人的控制柜标准配置一般都带以太网口，不需要额外加通信模块。ModbusTCP协议又是完全开放的，PLC侧无论是西门子、汇川、三菱、欧姆龙，都有现成的功能块可用。也就是说整个方案的增量成本几乎只有一根工业网线和一个交换机端口，这在实际项目中是很大的优势，尤其预算审批比较麻烦的场合。

实时性方面，ModbusTCP的响应周期通常在10~100毫秒量级，这在上下料、码垛、搬运这类“机器人到位后告知PLC，PLC放行下一步”的应用里完全够用。但如果你要做多轴协调插补或实时轨迹同步，那就得考虑EtherCAT或专用总线了，这点要提前判断。

1.3 汇川机器人与PLC通信的典型拓扑

ModbusTCP通信的拓扑很直观：机器人控制柜作为服务器（从站），PLC作为客户端（主站）。为什么这样分配角色？因为机器人程序的运行节奏由机器人控制器决定，服务器端可以随时响应PLC的读写请求；而PLC作为整站的主控逻辑大脑，主动发起轮询是最自然的信号流方向。反过来如果PLC做服务器，机器人做客户端，虽然也能跑，但机器人的程序扫描周期和PLC的扫描周期很难对齐，调试起来麻烦很多。

网络拓扑上，我用了一台工业交换机，把机器人控制柜、PLC CPU、触摸屏和调试笔记本放在同一个网段。机器人IP设为192.168.1.10，PLC设为192.168.1.1，触摸屏192.168.1.20，笔记本设192.168.1.100。这里要特别强调，尽量单独划一个设备网段，不要跟办公网络混在一起，否则广播报文会把通信链路拖得很不稳定。

2. 动手配置前必须做好的三件事

2.1 画出一张IP与端口规划表

现场经常出现的问题不是不会配，而是配置前没规划，到了调试时候发现PLC和机器人的IP冲突，或者跟触摸屏不在同一网段，半天时间全耗在找冲突上。我的习惯是拿到项目后第一件事就画下面这张表，贴在电柜门内侧：

ModbusTCP的标准端口是502，这是IANA分配的保留端口。PLC侧发起连接时用本地随机端口，目标端口固定502，机器人控制柜内的服务程序会持续监听这个端口。如果现场改了端口，必须两边都改，而且很多PLC功能块在参数里写死的就是502，所以不建议改。

2.2 确认机器人的ModbusTCP寄存器寻址规则

这里要花点时间看手册，不同品牌的机器人，甚至同一品牌不同版本的控制器，对“保持寄存器地址”的起始编号定义可能不一样。有的从0开始，有的从1开始，有的显示为40001起始。汇川机器人的控制器配置界面里，地址通常直接显示为0-65535的偏移量，对应Modbus报文中的寄存器地址字段。也就是说，你在PLC里填地址0，配置界面里也填0，两边是对得上的。如果你用第三方工具比如ModbusPoll去读，工具里可能会自动加1或显示成40001格式，调试时注意换算，不要被数字搞晕。

2.3 快速回顾ModbusTCP报文结构

ModbusTCP报文在TCP/IP之上封装，格式是：事务处理标识符（2字节）+ 协议标识符（2字节）+ 长度（2字节）+ 单元标识符（1字节）+ 功能码（1字节）+ 数据（N字节）。

• 事务处理标识符：每次请求递增，用来匹配请求和响应，PLC侧功能块会自动处理。
• 协议标识符：固定为0，表示Modbus协议。
• 长度：后面的字节数。
• 单元标识符：相当于从站地址，通常填1，但在串联多个设备时要特别留意，这个字段必须跟机器人侧配置的从站地址一致。
• 功能码：读保持寄存器是0x03，写单个保持寄存器是0x06，写多个保持寄存器是0x10。

实际调试时不需要手写这些字节，但我还是建议理解一下，因为用Wireshark抓包分析问题时，没有人会替你翻译这些字节是什么意思。

3. 汇川机器人侧配置实操：把控制柜变成ModbusTCP服务器

3.1 进入通信配置界面

以汇川机器人常见的控制柜为例，示教器开机进入主界面后，在“系统参数”或“通信设置”菜单里可以找到ModbusTCP配置项。不同软件版本菜单名称可能有差异，我手上这台机器用的是较新的系统版本，菜单路径是“设置-通信-ModbusTCP”。如果找不到，直接在示教器右上角搜索“Modbus”，一般都能跳到对应页面。

进入配置页后，先把“使能”开关打开。这里有一个细节：改完配置之后，系统通常会提示是否重启服务或重启控制柜。如果只改寄存器映射，有些版本可以热加载，但为了稳妥，我还是建议配置完成后重启一次控制柜，确保所有通信任务重新加载。

3.2 配置IP地址和通信参数

在机器人控制柜的网络设置里，将网口IP设置为规划的192.168.1.10，子网掩码255.255.255.0，网关可以不填或填交换机管理IP。网关这块容易踩坑，如果机器人网口和PLC处于同一网段，其实不需要网关；填了错误的网关反而可能导致控制柜尝试走三层转发，出现通信时通时断的现象。

ModbusTCP参数里通常需要设置最大连接数、响应超时时间、单元标识符。我习惯把单元标识符设为1，最大连接数设为2，一个给PLC用，一个留给我笔记本上的调试工具用。这样我在调试PLC程序的时候，不用先断开PLC的连接才能用ModbusPoll去读寄存器，非常方便。

3.3 建立寄存器映射表

这是机器人侧配置的核心步骤。汇川机器人的寄存器映射思路是：把Modbus的保持寄存器地址映射到机器人控制器内部的变量或I/O点。也就是说，PLC读写Modbus寄存器，实际就是在读写机器人内部的某个状态变量或控制字。

我在项目中是这样映射的：

这个表里的地址范围都在0-9999以内，Modbus标准允许的常规范围足够覆盖。配置完成后，保存并重启控制柜。注意，如果寄存器映射表里映射的是32位浮点数，要确认好字节顺序是“大端字序”还是“小端字序”，在界面上找到字节序选项，并记录下当前选择，后面PLC侧解析数据时要用同一规则。

4. PLC侧ModbusTCP客户端编写：以西门子S7-1200为例

4.1 TIA Portal中的网络组态

我这里用的PLC是西门子S7-1200 1215C，编程软件TIA Portal V17。虽然汇川机器人跟汇川PLC配合自然是首选，但很多终端用户现场已经有指定的PLC品牌，西门子占的比例很高，所以以S7-1200举例有通用性。其他品牌的PLC思路完全一样，只是功能块名称和引脚略有差异。

在TIA Portal中，不需要额外配置ModbusTCP硬件，只需要在程序里调用“MB_CLIENT”指令。这个指令在“通信-开放式通信”或是“通信-其他”指令面板里，取决于TIA的版本。S7-1200从固件版本V4.0开始支持MB_CLIENT，如果你的CPU固件版本比较老，建议先升级固件到V4.4以上，否则功能块可能不全。

4.2 MB_CLIENT指令参数详解

MB_CLIENT指令的引脚比较多，但核心就是下面几个：

• REQ：上升沿触发一次读写请求。我习惯用一个周期为500ms的脉冲位触发，频率不用太快，因为机器人控制柜内部变量刷新周期一般也就几十毫秒，读太快意义不大。
• CONNECT：连接参数，用“TCON_IP_v4”数据类型组态。这里要填机器人的IP地址192.168.1.10、端口502、本地端口可以留空让系统自动分配。连接ID要填一个不冲突的值，比如1。
• MB_MODE：读写模式。0=读，1=写。
• MB_DATA_ADDR：从站寄存器地址，注意这里是协议地址，直接填0、1、2这种实际寄存器号。
• MB_DATA_LEN：数据长度，单位是字（Word）。
• MB_DATA_PTR：指向PLC内部数据块的指针，读到的数据放到哪里，或从哪取数据发送。
• DONE和ERROR：通信完成和错误标志，必须做复位，否则下一个请求可能不会正常触发。

根本上你只需要记住一个原则：MB_CLIENT每次调用只能完成“一次读”或“一次写”。如果既想读机器人的状态，又想写命令，需要至少两次调用，或者用同一个功能块交替切换MB_MODE。为了程序结构清晰，我分开建了两个功能块，一个专门读状态，一个专门写命令。

4.3 轮询策略设计

PLC的扫描周期通常在几毫秒到十几毫秒，但ModbusTCP通信的响应周期在10毫秒以上。如果在同一个扫描周期里对该功能块连续置位REQ，会导致请求排队，甚至触发通信超时。我的做法是做一个定时器，每隔300ms产生一个脉冲，这个脉冲作为读功能块的REQ；再隔150ms产生另一个脉冲，作为写功能块的REQ。两个触发错开，避免读写在同一个TCP连接上打架。

这种方法在机器人非实时轨迹联动的场景下完全够用。如果现场要求更快的响应速度，可以把脉冲周期缩短到50-100ms，但建议不要低于机器人控制柜的刷新周期，否则会产生旧数据覆盖新数据的问题。

5. 寄存器规划与数据一致性设计：本项目最核心的部分

5.1 一份可直接抄作业的寄存器分配表

寄存器分配是整个通信方案里最容易被低估的环节。很多人程序写完了才发现命令字和状态字重叠，或者长度不够用。我给出的表分三块：命令区（PLC写机器人）、状态区（PLC读机器人）、交互区（双向使用）。

命令区从地址0开始，每个命令字占一个寄存器：

状态区从地址10开始：

交互区放在地址40-49，用于走一些临时数据，比如当前工件的批次号、机器人当前执行的步序号。

这里要特别注意，32位浮点占两个寄存器，地址20表示X坐标的低字，21表示高字。具体哪个是低字哪个是高字取决于机器人侧的字节序配置，在PLC解析时必须按同样的顺序组合。很多初次接触的人在这里把X轴的数值读出来是一个完全不合理的天文数字，基本都是字节序反了。

5.2 大端小端问题：为什么读出来的坐标是乱的

Modbus协议本身规定多字节数据采用大端序，也就是高字节在前。但汇川机器人内部的浮点存储可能是小端序，这就要求在PLC侧做字节交换。具体处理分两步：

第一步，用两个连续的MB_DATA_ADDR地址读回原始字：比如地址20读出WORD变量“X_Low”，地址21读出“X_High”。

第二步，用字节交换指令把两个字的字节顺序调整后再组合成DWORD，最后用“BITCAST”或“DWORD_TO_REAL”指令把这个DWORD值转换为浮点数。

在西门子S7-1200里，可以这样写：

#X_raw := INT_TO_DINT(#X_Low_word) + INT_TO_DINT(#X_High_word) * 256 * 256; #X_real := DWORD_TO_REAL(#X_raw);

实际操作中，还要确认“低字高字节”还是“低字低字节”的位置。如果发现读出来的值相差256倍或是一个极大数，那就是字序问题；如果是正常的数但小数位不对，那才是字节序问题。不要一上来就怀疑通信断了。

5.3 心跳位：低成本但极有效的通信健康监测

大多数项目里，PLC判断通信是否正常只看MB_CLIENT的ERROR标志。这个标志只能说明上一次Modbus请求有没有得到响应，但如果机器人控制柜的Modbus服务程序卡死、或者网线被误拔，这个标志位要到下一个触发周期才会变化，而且变化之后不一定能自动恢复。

我习惯额外做“心跳监测”。方法很简单，让机器人程序的每个扫描周期里把地址30的寄存器值在0和1之间交替。也就是上一次写0，这次写1，下次再写0，相当于一个极低频的方波。

PLC侧用上升沿计数器监视这个值的变化。如果超过500ms这个值没有变化，就认为通信中断，立即触发整站急停逻辑。我用这个方法在项目调试阶段真实抓出过一次交换机端口松动的问题，如果没有心跳，那可能要到机器人误动作撞了夹具才会被发现。

5.4 启动信号必须用沿触发

这个坑我必须单独拿出来说。假设PLC把地址0的启动命令字置为1，机器人收到后启动程序。但PLC程序跑完后，这个寄存器如果一直保持为1，机器人会是什么反应？

相当多的机器人控制器逻辑是“命令字的上升沿触发动作”，也就是从0变成1的瞬间执行启动，即使后续持续为1，也不会重复启动。但也有一些控制器的逻辑是“持续置位状态下程序结束后自动重新启动”，这就极其危险了，可能造成机器人停不下来。

我的对策是，PLC侧把启动命令做成脉冲位，按下启动按钮后，把这个命令字置1，延时200ms后复位为0。这样无论机器人侧边沿逻辑如何实现，都不会出现误重启动的问题。同理，复位命令字也必须做成脉冲。

6. 联机调试全过程与故障排查

6.1 调试顺序：先通信后逻辑

通信项目联机时，我坚决反对一上来就把整个PLC程序下载进去跑。正确顺序是：

第一步，用ModbusPoll工具连接机器人，手动读写寄存器，确认机器人侧配置正确。ModbusPoll设置很简单，选ModbusTCP，填IP192.168.1.10，端口502，从站地址1，功能码03，起始地址0，长度31。能正确读到寄存器的值，说明机器人侧已经准备好了。

第二步，把PLC和机器人连起来，用MB_CLIENT功能块单独读地址10，在PLC的监控表里观察主状态值。读上来之后，再单独写地址0，观察机器人是否响应。

第三步，确认读写都正常后，才联入完整的PLC逻辑程序，否则出了问题根本分不清是通信问题还是程序逻辑问题。

6.2 用Wireshark抓包的几个实战技巧

通信调试最大的难度是“看起来都正常但数据不对”。一次读请求发过去，响应报文回来了，但数值完全不对，这时候ModbusPoll只能显示结果，不能告诉你为什么。我通常用Wireshark抓包来分析。

抓包时过滤条件填“tcp.port == 502”，就能看到所有ModbusTCP报文。重点看两点：

第一，看请求报文中的请求起始地址和寄存器长度是不是跟PLC功能块里填的一致。有一次我填地址时本意是20，结果不小心填成了2，读回来的坐标值一直等于命令字，抓包一眼就发现了。

第二，看响应报文的数据区字节长度。比如请求读6个寄存器，期望数据区长度应该是12字节。如果响应里的长度值和请求对不上，大概率是功能块参数和机器人侧映射表不匹配。

Wireshark抓包的另一个价值是定位建立连接失败。如果请求发出后没有响应报文，先看是不是有“TCP Dup ACK”或“RST”标志，这说明PLC到机器人之间的TCP连接根本没有建立成功，重点排查防火墙、端口和IP地址。

6.3 典型故障现象对照表

我整理了现场调试中常见的几类问题，直接列成表方便现场对照：

6.4 一次现场处理案例：通信时断时续的根因

这个案例很有代表性。项目调试第二天，现场反映PLC与机器人通信每隔十几分钟就会断开一次，断开几十秒后自动恢复。从PLC报错时间点看，没有明显规律。我跑到现场第一件事是看交换机，发现这个24口百兆工业交换机上同时接了机器人、PLC、触摸屏和几台变频器的调试网口，指示灯都在闪，但端口17号灯偶尔会熄灭几秒。

拿万用表量了那根从机器人控制柜到交换机的网线，发现屏蔽层在机器人控制柜侧的压接端松动，控制柜底座有一台大功率伺服驱动器，振动加上电磁干扰，让这个接头间歇性失效。换了一个金属航空插头后，断联问题再也没出现过。这件事的教训是：通信方案在逻辑层面省下来的时间和成本，一定要花在硬件施工质量上，尤其是网线接头和屏蔽层的处理，不能凑合。

7. 稳定运行的细节：从能用到好用

7.1 工业网络施工的基本要求

ModbusTCP虽然用普通百兆网线就能跑，但在工业现场，网线选择不能省钱。我推荐使用至少CAT5e以上的工业以太网线，带屏蔽层，且屏蔽层必须在控制柜侧单端接地。网线长度控制在80米以内，超过这个距离必须加工业交换机中继。现场如果存在变频器、伺服驱动器等强干扰源，网线走线要远离动力电缆，保持至少30厘米的安全距离。

交换机建议选用网管型或至少是工业级非网管型，不要用办公网络用的塑料壳交换机。现场环境粉尘大、温度高，办公级交换机用不了多久就会因为散热不良导致丢包。

7.2 通信状态在HMI上的可视化管理

这里分享一个加分项。我在触摸屏上专门做了一页“通信诊断”页面，显示以下内容：PLC到机器人的连接状态（通过MB_CLIENT的DONE标志）、心跳超时次数、最近一次通信错误代码、累计通信异常次数。运维人员在生产中看到异常，不用等故障停机后才去翻程序，直接就能通过这页判断是网络问题还是机器人本体问题。

实现方法也不复杂，把心跳超时的计数器做个累加，每超时一次加1。如果这个数字在稳定增长，说明网络环境有问题，需要排查硬件；如果这个数字一直为0，但机器人偶尔报警，那问题大概率出在机器人本体或PLC逻辑上。

7.3 如何从ModbusTCP平滑升级到总线方案

最后说一个扩展思路。如果后续这条产线要升级为更完整的智能制造方案，需要机器人实时上传坐标轨迹、PLC下发复杂的任务队列，ModbusTCP的报文长度和刷新周期可能就不够用了。这个时候可以把通信方案升级为汇川机器人支持的总线协议，比如PROFINET或EtherCAT。

但升级的前提是，当前ModbusTCP的寄存器规划已经形成了清晰的“数据字典”，每个信号的含义、数据类型、量纲都记录清楚。这个数据字典可以直接映射为总线方案中的过程数据，PLC侧逻辑改动很小。所以我一直强调，通信协议可能会换，但数据模型的设计是一劳永逸的工作，前期多花半小时画清楚寄存器表，后期无论怎么换通信方式，都能快速平移。

8. 配置要点速查（现场施工经常要翻）

8.1 现场快速配置清单

• 机器人侧：启用ModbusTCP服务；IP设为192.168.1.10；单元标识符设为1；映射表按本章5.1节的表配置。
• PLC侧：组态MB_CLIENT；CONNECT参数填机器人IP和502端口；读功能块读地址0-49；写功能块写地址10-31；触发周期设为300ms。
• 网络侧：工业交换机隔离设备网段；网线屏蔽层单端接地；网线长度低于80米。

8.2 推荐调试工具清单

• ModbusPoll或ModbusScan：手动读写机器人寄存器，验证机器人侧配置。
• Wireshark：抓包分析TCP连接和Modbus报文级别的问题。
• IBHLink或S7自带的在线监控：查看MB_CLIENT的返回状态。

8.3 开工前半小时检查法

我习惯在每次通信调试之前花半小时做一遍全流程检查：先把调试笔记本接到交换机上，ping机器人的IP通不通；再用ModbusPoll读一遍机器人的寄存器，确认服务正常；最后把PLC程序设置为只读状态，下载到CPU后手动触发一次MB_CLIENT，确认DONE位亮起。完成这三步再开始联调，后面遇到问题基本都能定位到是逻辑问题而不是通信基础问题。

这套ModbusTCP通信方案在项目验收后运行了半年，没有出现过一次通信故障。总结起来无非就是：选型时想清楚实时性需求，配置时把寄存器表规划细致，调试时按“先通信后逻辑”的顺序走。做到这三点，汇川机器人与PLC的ModbusTCP通信就能稳稳跑在生产线上。