企业官网建设流程全解析

1. 从一条产线调试说起：为什么搞懂这两层差异能省下三天排查时间

前阵子帮朋友处理一条包装线的通讯故障，PLC 侧用的是 FX3U 加 485ADP-MB 模块，上位机走的是 Modbus TCP，中间挂了一个协议转换网关。现象很典型：上位机读到的数据偶尔跳变，重连之后又正常，过几个小时再犯。朋友一开始怀疑是网关质量问题，换了两台，问题照旧。后来抓包一看，RTU 侧的 CRC 校验错误率在特定时段飙升，而 TCP 侧完全无感——因为 TCP 那一层根本不做 CRC，它把校验甩给了以太网自己的帧校验。

这件事让我意识到，很多人把 Modbus RTU 和 Modbus TCP 当成"同一个协议换了个传输方式"，这个理解在简单场景下能跑通，一旦涉及网关、多从站、长距离布线或者跨网段，就会踩坑。Modbus RTU 和 Modbus TCP 共享同一套功能码和寄存器模型，但它们在"哪一层负责什么"这件事上，分工完全不同。这篇文章就围绕这个核心差异展开，把协议栈分层、报文结构、校验机制、端口与连接模型、以及实际调试中的排查思路讲透。

适合谁看：做过 Modbus 通讯但没系统梳理过分层差异的工程师、正在选型 RTU 还是 TCP 的项目负责人、以及被 CRC 和 502 这类问题折腾过的调试人员。读完你应该能自己判断：什么时候该用 RTU，什么时候该用 TCP，网关转换时哪些字段会被改写，以及出问题时该从哪一层下手。

2. 协议栈分层拆解：同一套问答，差在"谁负责可靠传输"

2.1 应用层是共用的，这是"同一套问答"的由来

Modbus 的应用层定义了功能码、数据地址、寄存器类型这些内容。不管是 RTU 还是 TCP，读保持寄存器都是功能码 03，写单个寄存器都是 06，写多个寄存器是 10（十六进制）。请求和响应的语义完全一致：主站发一个请求，从站回一个响应，请求里带从站地址、功能码、起始地址、数量，响应里带字节数或数据。

这就是"同一套问答"的含义。你在 RTU 上调通的逻辑，搬到 TCP 上，功能码和地址映射基本不用改。很多组态软件、PLC 编程软件里，切换 RTU/TCP 只是改一个下拉框，地址表原封不动，原因就在这里。

但"问答内容一样"不等于"传输过程一样"。应用层之下，两者走的是完全不同的路。

2.2 RTU 把可靠性压在串口链路自己身上

Modbus RTU 跑在串行链路上，典型是 RS-485 两线制，也有 RS-232。串口链路本身不提供任何错误检测和重传机制，它只负责把比特流按波特率推出去。所以 RTU 必须在应用层和物理层之间自己补一套机制：

• 帧边界靠时间间隔判断：3.5 个字符时间的静默作为帧结束标志，1.5 个字符时间作为帧内字符间隔上限。波特率越高，这个时间窗口越短，对时序要求越苛刻。
• 完整性靠 CRC-16 校验：每帧末尾两个字节，多项式 0xA001（反向表示），覆盖从站地址到数据区全部内容。
• 寻址靠帧内第一个字节：从站地址 1~247，0 是广播，248~255 保留。

换句话说，RTU 是"裸链路 + 自带保险"。链路不可靠，协议层自己扛。

2.3 TCP 把可靠性甩给了下层，自己只留一个"信封"

Modbus TCP 跑在以太网上，底下有 TCP 提供可靠传输：丢包重传、乱序重组、连接管理，这些都不用 Modbus 操心。所以 Modbus TCP 不需要 CRC，也不需要靠时间间隔判断帧边界——TCP 是字节流，但 Modbus TCP 用长度字段来切分报文。

它引入了一个叫MBAP 头（Modbus Application Protocol Header）的东西，7 个字节：

MBAP 头之后才是 PDU（功能码 + 数据），这部分和 RTU 的 PDU 完全一样。所以你可以理解为：Modbus TCP = MBAP 头 + RTU 的 PDU（去掉 CRC）。

2.4 一张表看清分层差异

这张表是后面所有排查思路的基础。记住一句话：RTU 的问题多半出在物理层和时序，TCP 的问题多半出在连接和网关映射。

3. 报文结构逐字节对比：CRC 和 MBAP 到底差在哪

3.1 RTU 读保持寄存器请求报文拆解

以读从站 1 的保持寄存器，起始地址 0，读 2 个寄存器为例，功能码 03：

01 03 00 00 00 02 C4 0B

逐字节解释：

• 01：从站地址
• 03：功能码，读保持寄存器
• 00 00：起始地址 0
• 00 02：读 2 个寄存器
• C4 0B：CRC-16 校验，低字节在前

响应：

01 03 04 00 0A 00 14 3A 2E

• 01：从站地址
• 03：功能码
• 04：后续数据字节数（2 个寄存器 = 4 字节）
• 00 0A 00 14：两个寄存器的值，分别是 10 和 20
• 3A 2E：CRC

3.2 CRC 怎么算：手算一遍就懂了

CRC-16/Modbus 的算法核心是：初始值 0xFFFF，逐字节异或后右移，遇到最低位为 1 就异或多项式 0xA001。用 Python 写出来最直观：

def crc16_modbus(data: bytes) -> bytes: crc = 0xFFFF for b in data: crc ^= b for _ in range(8): if crc & 0x0001: crc = (crc >> 1) ^ 0xA001 else: crc >>= 1 # 低字节在前 return bytes([crc & 0xFF, (crc >> 8) & 0xFF]) frame = bytes([0x01, 0x03, 0x00, 0x00, 0x00, 0x02]) print(crc16_modbus(frame).hex()) # 输出 c40b

算出来是c4 0b，和报文一致。这里有个容易踩的坑：CRC 结果低字节在前，高字节在后，和很多其他协议的 CRC 排列相反。我见过有人把高低字节写反，结果从站一直不回，抓包看请求帧明明发出去了，就是没响应——因为从站校验不过直接丢弃，连异常码都不回。

注意：CRC 计算范围是从站地址到数据区最后一个字节，不包含 CRC 自身。发送时先算好再拼到帧尾。

3.3 TCP 同一操作的报文长什么样

同样的读操作，Modbus TCP 请求：

00 01 00 00 00 06 01 03 00 00 00 02

拆开看：

• 00 01：事务标识符，主站自己定的，这里是 1
• 00 00：协议标识符，固定 0
• 00 06：长度，后面有 6 个字节（单元标识符 1 + PDU 5）
• 01：单元标识符，对应 RTU 的从站地址
• 03 00 00 00 02：PDU，和 RTU 完全一样

响应：

00 01 00 00 00 07 01 03 04 00 0A 00 14

• 00 01：事务标识符原样返回
• 00 00：协议标识符
• 00 07：长度，7 字节
• 01：单元标识符
• 03 04 00 0A 00 14：PDU

对比一下就很清楚：TCP 把 RTU 的从站地址挪进了 MBAP 的单元标识符，去掉了 CRC，前面加了 6 个字节的头。PDU 部分一字不差。

3.4 长度字段的计算容易出错

MBAP 的长度字段 = 单元标识符（1 字节）+ PDU 长度。很多人写网关或者自己拼报文时，把长度算成 PDU 长度，少算了单元标识符那 1 个字节，结果从站解析时读多或读少一个字节，响应错位。

以上面请求为例，PDU 是03 00 00 00 02，5 个字节，加上单元标识符 1 个字节，长度字段应该是 6，即00 06。这个细节在写协议转换代码时是高频错误点。

4. 连接模型与端口：一主多从和客户端服务器不是一回事

4.1 RTU 的总线共享本质

RS-485 是半双工总线，所有设备挂在同一对差分线上。同一时刻只能有一个主站发送，从站只能被动响应。这就是"一主多从"的物理基础。

主站轮询的典型节奏是：发请求给从站 1，等响应，超时或收到后，再发请求给从站 2，依次循环。从站之间不会主动说话，也不会互相通信。如果两个主站同时往总线上发，信号会冲突，谁都读不对。

这带来几个实际约束：

• 轮询周期 = 各从站响应时间之和。从站越多，单次轮询越慢。一个 9600 波特率、20 个从站的系统，轮询一圈可能要好几秒。
• 从站响应慢会拖累全局。某个从站故障不响应，主站要等超时才跳过，这段时间总线是空闲的，其他从站也被耽误。
• 总线长度和波特率成反比。9600 波特率可以拉到 1200 米，115200 波特率通常只能到几十米到一百多米，具体看线材和终端电阻。

4.2 TCP 的连接模型灵活得多

Modbus TCP 是客户端/服务器模型。客户端主动发起 TCP 连接，服务器监听 502 端口。一个服务器可以同时接受多个客户端连接，每个连接独立处理请求。事务标识符让同一个连接上的多个并发请求可以乱序返回而不混淆。

这意味着：

• 多个客户端可以同时读同一个服务器，不需要像 RTU 那样排队轮询。
• 响应时间不受其他客户端影响（在服务器处理能力范围内）。
• 可以跨网段、跨路由，只要有 IP 可达。

但灵活也有代价：连接管理成了新问题。TCP 连接可能因为网络抖动断开，客户端要处理重连；服务器要处理大量并发连接时的资源占用；防火墙可能拦截 502 端口。

4.3 网关场景：两层差异集中爆发的地方

实际项目里最常见的架构是：现场设备是 RTU，上位机或云平台走 TCP，中间加一个协议转换网关。网关一边做 RTU 主站轮询现场设备，一边做 TCP 服务器响应上位机。

这个场景下，前面说的分层差异全部体现出来：

• 网关要维护 RTU 侧的轮询调度，把 TCP 侧的并发请求翻译成串行的 RTU 轮询。
• 单元标识符和从站地址要做映射，一个 TCP 请求的单元标识符对应哪个 RTU 从站，网关要查表。
• TCP 侧没有 CRC，网关要自己给 RTU 帧算 CRC。
• RTU 侧超时或 CRC 错误时，网关要决定是返回异常码还是让 TCP 侧超时。

我朋友那条产线的问题就出在这里：网关在 RTU 侧遇到 CRC 错误时，选择了静默重试，但重试期间 TCP 侧的事务标识符已经对不上了，上位机收到的是上一个请求的响应，数据就跳变了。后来把网关的重试策略改成"CRC 错误直接返回异常码 0x03"，上位机就能正确识别并重新发起请求，问题消失。

5. 实操调试：从抓包到定位的完整流程

5.1 RTU 侧调试：先确认物理层再谈协议

RTU 出问题，我的排查顺序永远是：物理层 → 参数 → 协议。

物理层检查项：

• A/B 线有没有接反。RS-485 的 A 接 A、B 接 B，接反了完全收不到数据，但用万用表量电压可能看起来正常。
• 终端电阻有没有加。长距离或高波特率时，总线两端各加 120 欧姆终端电阻，中间设备不加。
• 屏蔽层有没有单端接地。两端都接地会形成地环流，引入干扰。
• 共地问题。不同设备地电位差过大时，要加隔离器。

参数检查项：

• 波特率、数据位、停止位、校验位，主从必须完全一致。9600-8-N-1 是最常见的组合。
• 从站地址有没有冲突。总线上两个设备地址相同，会同时响应，信号冲突。

协议检查项：

• 抓包看请求帧的 CRC 是否正确。
• 看从站有没有回异常码。异常码最高位为 1，比如 0x83 表示功能码 03 的异常，后面跟异常码 01（非法功能）、02（非法地址）、03（非法数据值）等。

5.2 TCP 侧调试：连接、端口、事务标识符

TCP 侧排查顺序：连接 → 端口 → 报文。

连接检查：

• 用telnet或nc测试 502 端口是否可达。nc -zv 192.168.1.100 502，通了说明 TCP 层没问题。
• 如果连不上，检查防火墙、服务器是否监听、IP 是否正确。

端口检查：

• Modbus TCP 标准端口是 502，但很多设备允许改。确认实际端口。
• 有些云平台用非标端口，比如 1502、8502，别想当然。

报文检查：

• 抓包看 MBAP 头。协议标识符必须是 0，不是 0 说明不是标准 Modbus TCP。
• 事务标识符请求和响应是否一致。不一致说明响应错位。
• 长度字段是否正确。

5.3 一个真实的排查案例

回到开头那条包装线。排查过程是这样的：

1. 上位机侧抓包，发现读到的数据偶尔是上一次请求的值。事务标识符对不上。
2. 怀疑网关。在网关的 RTU 侧串口抓包，发现特定时段 CRC 错误率升高。
3. 查物理层，发现 485 线经过变频器柜，走线没有屏蔽，变频器启停时干扰串口。
4. 临时把 485 线改道，远离变频器，CRC 错误率下降。
5. 同时把网关重试策略改为返回异常码，上位机侧加了异常处理，数据跳变消失。

根因是物理层干扰，但表现是应用层数据错乱。如果只盯着协议层看，永远找不到问题。

5.4 常见问题速查表

注意：502 Bad Gateway 是 HTTP 状态码，和 Modbus TCP 的 502 端口完全是两回事。搜索热词里出现的 502 错误多半是 Web 服务问题，别和 Modbus 端口混淆。

6. 选型与工程实践：什么时候用哪个

6.1 RTU 的适用场景

• 现场设备只支持串口，比如老式仪表、变频器、温控器（E5CC 这类）。
• 布线距离远，超过以太网 100 米限制，RS-485 可以拉到上千米。
• 设备数量少、数据量小、实时性要求不高。
• 成本敏感，串口模块比以太网模块便宜。

6.2 TCP 的适用场景

• 上位机是 PC、服务器、云平台，天然走以太网。
• 需要多客户端并发访问。
• 跨网段、跨区域，需要路由。
• 数据量大、实时性要求高。

6.3 混合架构的实践建议

大多数项目是混合的：现场 RTU，汇聚到网关，网关转 TCP 上云。这种架构下有几个经验点：

• 网关选型看轮询能力。从站多、寄存器多时，网关的轮询周期要算清楚，别让上位机等太久。
• 单元标识符规划好。一个网关后面挂多个 RTU 从站时，单元标识符和从站地址的映射要提前规划，别到现场再改。
• 异常处理要统一。RTU 侧的 CRC 错误、超时，网关怎么翻译成 TCP 侧的响应，要有明确策略。建议直接返回 Modbus 异常码，让上位机感知。
• 留调试接口。网关最好支持抓包或者日志，出问题时能看到 RTU 侧和 TCP 侧的原始报文。

6.4 关于 ADPRW 指令和梯形图

三菱 FX3U 加 485ADP-MB 模块做 RTU 主站时，常用 ADPRW 指令。这条指令封装了 Modbus 请求的发送和响应接收，参数包括从站地址、功能码、起始地址、数量、数据存储区。

用 ADPRW 时要注意：

• 指令是异步的，发送后要等完成标志位，不能连续发。
• 多条 ADPRW 指令之间要有间隔，或者用完成标志位串起来。
• 超时设置要合理，太短会误判从站故障，太长会拖慢轮询。
• 485ADP-MB 模块的通信参数要和从站一致，在模块的缓冲存储器里设置。

梯形图编程时，建议把每条 ADPRW 的完成标志位和错误标志位都接出来，方便排查。错误标志位置位时，读模块的错误代码，能快速定位是超时、CRC 错误还是异常响应。

7. 几个容易混淆的概念澄清

7.1 Modbus TCP 的 502 端口和 HTTP 的 502 错误

这两个 502 没有任何关系。Modbus TCP 的 502 是 IANA 分配的端口号，HTTP 的 502 Bad Gateway 是状态码。搜索热词里大量出现 502 错误，绝大多数是 Web 服务问题，和 Modbus 无关。做 Modbus 调试时看到 502，先确认是端口连不上还是 HTTP 报错。

7.2 CRC 错误和 CRC 校验码计算

CRC 错误是接收方算出来的 CRC 和帧里的 CRC 不一致，说明传输过程中数据变了。CRC 校验码计算是发送方生成 CRC 的过程。两者是同一机制的两端。调试时如果频繁 CRC 错误，问题在传输过程，不在计算算法。

7.3 RTU over TCP 和 Modbus TCP

有些设备支持"RTU over TCP"，就是把完整的 RTU 帧（含 CRC）封装在 TCP 里传输。这和标准 Modbus TCP 不同：标准 Modbus TCP 用 MBAP 头，没有 CRC；RTU over TCP 保留 CRC，没有 MBAP 头。两者不兼容，配置时别选错。

7.4 单元标识符和从站地址

在纯 TCP 场景下，单元标识符通常填 1 或者 0xFF，具体看服务器要求。在网关场景下，单元标识符用来区分后端 RTU 从站。别把这两个概念混为一谈。

8. 写在最后：分层思维是排查通讯问题的钥匙

搞通讯调试这些年，我最大的体会是：大部分"协议问题"其实不是协议问题，而是分层没理清。数据错了，先问是哪一层错的；连不上，先问是哪一层断的。RTU 和 TCP 的差异，本质就是可靠性责任的分工不同——RTU 自己扛，TCP 甩给下层。

实际项目里，我习惯在方案设计阶段就把分层图画出来：物理层用什么、链路层谁负责校验、应用层功能码怎么映射、网关在哪一层做转换。图画清楚了，后面出问题按层排查，效率高很多。

最后分享一个小技巧：调试 Modbus 时，手边常备一个能同时抓串口和网口的工具。RTU 侧看原始字节和 CRC，TCP 侧看 MBAP 头和事务标识符，两边对照着看，网关到底改了什么、哪里对不上，一目了然。比单纯看上位机的错误提示有用得多。