PLC与工业网关的通信方式
——从Modbus到S7，讲透每一层

Modbus帧结构拆解 · RTU/TCP转换 · 扫描周期与采集周期 · S7连接数 · 4G调优 · 实战案例

类型：技术干货　|　适用：工业自动化/物联网从业者

关键词：PLC · 工业网关 · Modbus · S7协议 · 数据采集 · 协议转换

⚡ 速读盒子 · 30秒看完核心

▸ 核心结论：PLC与网关通信是"时序、协议、缓冲区"三层博弈——技术没有高低，只有合不合适

▸ 技术硬核点：扫描周期vs采集周期无声丢数据、字节序Byte/Word swap陷阱、S7-1200连接数上限8个、4G下超时500-2000ms

▸ 案例结果：数据丢点率85%→0，触摸屏与MES同步3秒→实时，12台PLC轮询周期2.7秒→200ms

做工业通信这些年，被客户问过："PLC和网关到底怎么通信？"说句得罪人的实话：从来不是"连上就完事"，而是时序、协议、缓冲区三层博弈。这篇文章把每一层机理掰开揉碎：Modbus帧怎么组、RTU转TCP改了什么、为什么上线就丢点、4G下为什么时断时续。技术讲透了，你自然知道怎么配。

一、先搞清楚：PLC和网关之间，到底在传什么

通信本质是双向闭环：数据上行（采集）+ 指令下行（控制）。网关不只是"数据管道"，要做三件事：

协议转换：把PLC私有协议翻译成上层协议（Modbus/S7 → MQTT/OPC UA）

数据映射：把寄存器地址映射成统一点位表，上层不用关心设备内部结构

边缘处理：本地缓存、清洗、阈值判断，减少无效数据上行

一张表看清主流PLC通信协议：

注意看：没有一种协议是"万能"的。Modbus简单但只能轮询，S7私有但效率高，OPC UA语义强但资源大，MQTT适合上云但实时性一般。选协议，本质是选"时延、成本、生态"的平衡。

二、拆开看：Modbus这条"老路"的底层机理

Modbus RTU的一帧报文：

地址(1字节) + 功能码(1字节) + 数据(N字节) + CRC校验(2字节)

读保持寄存器：01 03 00 00 00 01 84 0A（01从站地址 / 03功能码 / 00 00起始地址 / 00 01数量 / 84 0A CRC16）

Modbus TCP则去掉CRC，换成7字节MBAP头（事务标识+协议标识+长度+单元标识），端口502。所以RTU转TCP，本质是"去CRC、加MBAP头"。

隐蔽的坑：RTU的从站地址（如01）转TCP后对应MBAP头的Unit-ID字段。有些网关默认把Unit-ID填成0或255，云端平台按从站地址路由时，就找不到设备了。

Q: 为什么RTU转TCP后，云端找不到设备了？

因为Unit-ID丢了。RTU帧里的从站地址01，转TCP后如果网关没做Unit-ID透传，会被改成00。判断方法：抓包看TCP帧的第7个字节，是不是你预期的从站地址。选网关时务必确认支持"Unit-ID透传"。

三、西门子S7协议：不是Modbus，是"私有协议"

S7-1200/1500原生不支持Modbus从站（要额外组态）。S7协议走ISO-on-TCP，端口102，用PDU封装读写请求。几个容易被忽略的特点：

端口是102，不是502——很多采集软件默认连502，连不上就报"连接失败"

有连接数上限：S7-1200的Modbus TCP连接数通常8个，超出直接拒绝新连接

老设备只有MPI口：S7-200只有串行MPI口，要加网关转

连接数上限是隐蔽的坑：测试阶段1-2台采集器没事，上线后5-6台同时轮询就频繁断连——不是代码逻辑变了，是通信处理器的并发能力到顶了。正确做法：让网关做"连接聚合"，一个网关统一采集，而不是每台采集器都直连PLC。

四、真正的坑：扫描周期 vs 采集周期（时序博弈）

这是PLC数据采集最隐蔽、最致命的坑。

每一台PLC都在循环执行扫描：读输入(PII)→执行程序→更新DB/寄存器→写输出(PIQ)。通信任务在扫描的"间隙"执行，优先级低于用户程序。

不同品牌PLC的典型扫描周期：

注意：上表的"采集频率建议上限"不是PLC的极限，而是不对产线正常运行产生干扰的上限。强行拉到10ms，通信处理器占用过多总线带宽，操作工触摸屏响应都会变慢。

缓存覆盖：PLC扫描周期20ms，采集器每200ms读一次，一个采集周期内PLC更新了10次数据，采集器只读到1次——中间9次变化被无声跳过。如果是脉冲信号（如按钮上升沿30ms），恰好错过。

串行轮询的数学：12台PLC串行轮询，单台采集周期=200ms+45ms=245ms，最差情况下最后一台要等245ms×11≈2.7秒。操作工按下按钮的信号只维持一个扫描周期就被覆盖——"数据线都接好了，寄存器地址都对，但采集系统在认真地采集错误的数据"。

字节序陷阱：西门子S7用大端序，x86电脑用小端序。32位浮点数3.14存为0x40 0x48 0xF5 0xC3，按小端解析变成-1.94e9。有些PLC（尤其罗克韦尔）字内大端、字间小端，只做字节翻转不够，还要做字翻转（Word swap）。

五、4G/5G无线场景：Modbus的"水土不服"

有线直连好好的，一上4G就时断时续。问题不在Modbus协议本身，而在无线链路：时延抖动、丢包、运营商NAT静默断链。

时延抖动：4G平时30ms，高峰期飙到300ms。超时设太紧（200ms），正常响应晚到就被判超时重发，从站收到重复请求返回异常码06（设备忙），形成恶性循环。

4G下Modbus参数调优建议：

心跳包：运营商静默终止空闲TCP连接（尤其NAT场景），网关显示"在线"但会话已死。配自定义心跳包，间隔30-60秒，可以是空帧或Modbus功能码08（诊断）。

透传 vs 协议转换：透传是"管道"原样转发；协议转换会去CRC、加MBAP头。云端只认RTU却设成协议转换，CRC校验直接失败。

Q: 为什么4G下PLC通信时断时续？

三个原因：一是超时设太紧，时延抖动导致误判超时；二是没有心跳包，NAT静默断链；三是多主站冲突，云平台和本地SCADA同时轮询。解决：超时放宽到500-2000ms、配30-60秒心跳、错开轮询间隔。

六、避坑指南：三个值几十万学费的坑

以下坑都来自真实的现场教训，每一条都值几十万学费：

❌ 坑一 只看协议支持列表，不看连接数

网关标称"支持Modbus TCP/S7/OPC UA"，但没写连接数上限。一台网关接8台PLC，连接数不够就频繁断连。选型时问清"并发连接数"和"采集点数上限"。

❌ 坑二 字节序不验证，读到错数据

32位浮点数有四种字节序：ABCD、CDAB、BADC、DCBA。文档没写就挨个试。先直连PLC验证数值，再抓包对比，确认网关没"帮倒忙"。

❌ 坑三 4G超时设太短

有线100ms超时习惯带到4G，高峰期误判超时重发，从站返回异常码06。先用ping测无线链路最大时延，超时设为2-3倍。

七、案例故事：某汽车零部件厂12台S7-1200采集改造

客户背景：某汽车零部件厂，12台西门子S7-1200，需把产线数据实时采集到MES，甲方要求"采集频率不低于200ms"。

遇到的问题：上线第一天就出事。触摸屏显示的数值和MES差了整整3秒，操作工按下按钮后，MES那边有时根本收不到信号。

诊断与设计：排查三天，最后发现原因令人哭笑不得：

PLC扫描周期约25ms（程序量中等）

采集器用Modbus TCP轮询12台PLC，每台读取20+个寄存器

轮询间隔200ms，但忽略了单次请求-响应的网络往返时间

实际单台完整采集周期=200ms+45ms=245ms，12台串行轮询最差等2.7秒

操作工按钮信号只维持一个扫描周期就被覆盖

技术选型要点：第一，网关做连接聚合，一台网关统一采集12台PLC；第二，事件驱动采集，变量变化超阈值才上传；第三，字节序统一，32位浮点数做Word swap；第四，采集周期规划，12台并行（网关多线程）而非串行轮询。

最终数据结果：

八、总结：通信的本质，是算清这笔账

选型根本不是"哪个协议更强"，而是三个问题：

数据要什么频率？秒级采集Modbus够用；毫秒级实时控制才需要PROFINET IRT。

走什么协议？Modbus简单便宜，S7私有但高效，OPC UA语义强但资源大，MQTT适合上云。先算清"采集频率×点数×连接数"是否在PLC通信能力内。

有线还是无线？有线稳定，无线灵活但有时延抖动。4G下务必放宽超时、配心跳、错开轮询。

技术硬核不等于天花乱坠。真正让客户信服的，是你把Modbus帧怎么组、RTU转TCP改了什么、扫描周期怎么博弈、字节序怎么翻、连接数怎么规划这些细节都讲得清清楚楚。PLC和网关不是对手，是搭档，分清自己要采什么，就能选对通信方式。

你的PLC，还在"插上网线就完事"吗？