工业通信基石：Modbus TCP协议解析与实战开发指南-育师

1. 项目概述：为什么Modbus TCP依然是工业通信的基石

干了十几年自动化，从现场接线到上位机开发，通信协议这块算是踩坑无数。今天想聊的Modbus TCP，乍一看是个老掉牙的话题，网上资料一抓一大把。但有意思的是，每次新项目上马，或者带新人调试，总能在最基础的Modbus TCP通信上遇到新问题。这恰恰说明，基础不牢，地动山摇。Modbus TCP协议本身不复杂，但把它用稳、用透，尤其是在复杂的工业现场网络环境下，里面的门道可不少。

简单来说，Modbus TCP就是在经典的Modbus协议家族里，给RTU（串口）和ASCII这两位“老大哥”找了个新搭档——以太网。它把Modbus的应用数据单元（ADU）直接装进了TCP/IP协议栈的数据包里，让原本只能在串口线上跑的工控数据，能通过网线、交换机在更远的距离、更复杂的网络拓扑里穿梭。对于做系统集成、设备联网或者上位机软件开发的工程师来说，掌握Modbus TCP意味着你能让PLC、DCS、智能仪表、变频器这些五花八门的设备，用同一种“语言”在以太网上对话，这是实现车间级甚至工厂级数据采集和控制的入门钥匙。

这篇文章，我会结合自己这些年调试西门子、三菱、欧姆龙PLC以及各类国产仪表网关的实际经验，把Modbus TCP从协议帧解析、功能码使用，到网络编程中的坑和实战调试技巧，掰开揉碎了讲清楚。目标是让你看完后，不仅能自己写个通信测试工具，更能具备独立排查和解决现场大部分Modbus TCP通信故障的能力。

2. 协议本质：剥开Modbus TCP的数据包

要玩转Modbus TCP，第一步不是急着写代码，而是得看清楚它到底长什么样。很多人一上来就找现成的库，结果出了问题连数据包都看不懂，只能干瞪眼。

2.1 协议栈与报文结构：从应用层到网络层

Modbus TCP的协议栈非常清晰，它自己只定义了应用层报文，下面的传输层和网络层完全交给标准的TCP/IP。你可以把它理解成：Modbus TCP = Modbus PDU + MBAP报文头。

先看最核心的MBAP报文头（Modbus Application Protocol Header），一共7个字节，固定结构：

字节偏移	字段名	长度（字节）	说明
0-1	事务元标识符	2	由客户端生成，用于请求和响应的配对。比如你发了请求是0x0001，服务器回的响应也应该是0x0001。在多线程并发请求时，这个字段至关重要。
2-3	协议标识符	2	固定为0x0000，表示这是Modbus协议。
4-5	长度字段	2	表示后面跟随的字节数，从单元标识符开始算起。
6	单元标识符	1	可以理解为从站地址或设备ID。在串口转以太网的网关场景下，这个字段常用来区分网关后面挂的不同串口设备。在纯TCP设备上，有时固定为0xFF或某个特定值。

MBAP头后面，紧跟着的就是Modbus PDU（协议数据单元），这部分和Modbus RTU是一模一样的，包括1个字节的功能码和可变长度的数据域。

一个完整的读取保持寄存器（功能码0x03）的请求报文例子：00 01 00 00 00 06 01 03 00 6B 00 03我们来拆解一下：

00 01: 事务元ID，表示这是第一个请求。
00 00: 协议ID，固定。
00 06: 长度，后面跟了6个字节（01 03 00 6B 00 03）。
01: 单元标识符，假设设备地址是1。
03: 功能码，表示读保持寄存器。
00 6B: 起始地址，这里是107（十进制），注意Modbus地址常用偏移量表示，有时需要+1。
00 03: 要读取的寄存器数量，这里是3个。

服务器的成功响应会是：00 01 00 00 00 09 01 03 06 00 0A 00 14 00 1E

事务元ID和单元标识符原样返回。
00 09: 长度，后面有9个字节。
03: 功能码。
06: 后面数据字节数，3个寄存器（每个2字节）共6字节。
00 0A 00 14 00 1E: 三个寄存器的值，分别是10，20，30。

注意：这里的“起始地址”00 6B是协议内部的地址偏移量。不同厂家、不同编程软件对Modbus地址的标注方式可能不同，比如有的标为400101（表示4区，地址101），对应协议里就是00 64。这是初期调试最容易混乱的地方，务必对照设备手册确认。

2.2 核心功能码详解与选用场景

Modbus功能码是通信的“动词”，决定了你要对设备做什么。TCP和RTU在功能码上完全通用。最常用的几个必须烂熟于心：

1. 读操作（客户端→服务器）

0x01 (Read Coils): 读线圈（离散输出）状态。每个线圈1位，可读多个。常用于读取继电器的输出状态。
0x02 (Read Discrete Inputs): 读离散输入状态。每个输入1位。常用于读取按钮、传感器的开关量输入。
0x03 (Read Holding Registers):最常用，读保持寄存器。每个寄存器16位（2字节）。用于读取设备参数、实时数据（如温度、压力、速度）。
0x04 (Read Input Registers): 读输入寄存器。同样是16位，通常用于读取只读的模拟量输入值（如AD采样值）。

2. 写操作（客户端→服务器）

0x05 (Write Single Coil): 写单个线圈。强制一个线圈为ON(0xFF00)或OFF(0x0000)。
0x06 (Write Single Register): 写单个寄存器。修改一个保持寄存器的值。
0x0F (Write Multiple Coils): 写多个线圈。效率高于多次调用0x05。
0x10 (Write Multiple Registers):最常用，写多个寄存器。批量修改参数或下发控制命令时使用。

3. 封装接口访问（部分设备支持）

0x2B (Read Device Identification): 读设备标识。用于识别设备厂商、型号、版本号，在设备发现和资产管理中很有用。

实操心得：功能码的“潜规则”
地址对齐：虽然协议没强制要求，但很多设备在处理多寄存器读写（0x03, 0x10）时，要求起始地址和数量满足某种对齐（如2的倍数）。不遵守可能导致错误码0x02（非法数据地址）。
数量限制：协议规定单次读写有上限（如线圈/寄存器数量不超过125个）。但实际设备可能有更小的限制，比如一次最多读50个寄存器，写20个。超出限制会返回错误码0x03（非法数据值）。这个值一定要查设备手册。
0x10写寄存器的数据组织：请求报文中，在起始地址和数量之后，会有一个“字节数”字段，表示后面实际数据占用的字节数（寄存器数量*2）。这是新手编程时容易算错的地方。

2.3 TCP与RTU的核心差异与连接管理

理解了报文，再看TCP和RTU的核心差异，就不仅仅是“一个走网线一个走串口”那么简单了。

1. 物理与链路层巨变

RTU: 依赖串口的物理特性（波特率、数据位、停止位、校验位）。通信是严格的“主从问答式”，靠时间间隔（3.5个字符时间）来判定一帧的结束。一旦线上有一个字节错误或干扰，整帧都可能报废。
TCP: 建立在TCP连接之上。TCP本身提供了可靠的、面向连接的、基于字节流的服务。这意味着Modbus TCP报文不需要校验码（CRC），因为TCP层保证了数据的正确性和顺序。通信模式可以是一问一答，也可以是客户端保持长连接，连续发送多个请求。

2. 连接管理与并发性这是最大的不同和最容易出问题的地方。

RTU是“一主多从”总线：一条串口线上挂多个从站，主站轮询。从站不能主动发言，严格按地址区分。
TCP是“点对点”连接：每个客户端（主站）和服务器（从站）之间建立独立的Socket连接。一个服务器可以同时接受多个客户端的连接。这里的“单元标识符”在单纯TCP设备上有时意义不大，但在**串口服务器（网关）**场景下至关重要。网关后面的每个串口设备才对应一个有效的单元标识符。

3. 网络带来的新问题

心跳与保活：TCP连接可能因为网络中断、设备重启而断开。稳定的工业软件需要实现心跳机制（定期发送一个空请求或特定功能码）来检测连接健康度，并具备自动重连逻辑。
超时设置：串口超时是固定的字符间隔超时。TCP超时则复杂得多，包括连接超时、发送超时、接收超时。在网络状况不佳的现场，需要合理设置这些超时（如连接超时5秒，读写超时3秒），太短容易误判，太长则程序会“卡死”。
防火墙与端口：Modbus TCP默认使用502端口。在工控机或服务器上部署时，必须确保操作系统防火墙和任何硬件防火墙放行了该端口的入站连接。这是现场调试时“通信不通”的常见原因之一。

3. 实战开发：从零构建一个健壮的Modbus TCP客户端

懂了协议，我们来动手。我会用一个Python示例（因其清晰易懂）来展示核心流程，但其中的思路和坑点适用于C#、Java、C++等任何语言。

3.1 环境准备与Socket编程基础

Python标准库socket就足够我们实现一个基础的Modbus TCP客户端。当然，生产环境更推荐使用成熟的库如pymodbus（功能全面）或minimalmodbus（针对串口），但自己实现一遍对理解协议有不可替代的好处。

import socket import struct import time class SimpleModbusTCPClient: def __init__(self, host, port=502, timeout=5.0): self.host = host self.port = port self.timeout = timeout self.transaction_id = 0 # 事务ID计数器 self.sock = None def connect(self): """建立TCP连接""" try: self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.settimeout(self.timeout) self.sock.connect((self.host, self.port)) print(f"Connected to {self.host}:{self.port}") return True except socket.error as e: print(f"Connection failed: {e}") return False

这里有几个关键点：

socket.AF_INET表示使用IPv4。如果设备是IPv6，需要改为AF_INET6，但工业场景99%是IPv4。
socket.SOCK_STREAM表示TCP流。
立即设置sock.settimeout非常重要，它影响后续所有sock.recv操作的阻塞时间，避免程序无响应。

3.2 报文组装与发送接收的完整流程

我们实现最核心的读保持寄存器功能。

def _build_mbap_header(self, pdu_length): """构建MBAP头：事务ID(2) + 协议ID(2) + 长度(2) + 单元ID(1)""" self.transaction_id = (self.transaction_id + 1) % 65536 protocol_id = 0 length = pdu_length + 1 # +1 是单元标识符占的1字节 unit_id = 1 # 假设设备地址为1，根据实际情况修改 # '>HHHB' 表示大端字节序，两个无符号短整型，一个无符号短整型，一个无符号字节 header = struct.pack('>HHHB', self.transaction_id, protocol_id, length, unit_id) return header def read_holding_registers(self, start_address, quantity): """读取保持寄存器 (功能码 0x03)""" if not self.sock: raise ConnectionError("Not connected to server.") # 1. 构建PDU：功能码(1) + 起始地址(2) + 数量(2) function_code = 0x03 pdu = struct.pack('>BHH', function_code, start_address, quantity) # 2. 构建完整报文：MBAP头 + PDU mbap_header = self._build_mbap_header(len(pdu)) request_message = mbap_header + pdu # 3. 发送请求 try: self.sock.sendall(request_message) except socket.error as e: print(f"Send failed: {e}") return None # 4. 接收响应 # 先接收MBAP头（7字节） try: mbap_header_resp = self.sock.recv(7) if len(mbap_header_resp) < 7: print("Incomplete MBAP header received.") return None # 解析长度字段，确定后续还要收多少字节 resp_trans_id, resp_prot_id, resp_length, resp_unit_id = struct.unpack('>HHHB', mbap_header_resp) pdu_length_to_read = resp_length - 1 # 长度字段包含单元ID，所以PDU长度要减1 # 接收PDU部分 pdu_resp = self.sock.recv(pdu_length_to_read) if len(pdu_resp) < pdu_length_to_read: print("Incomplete PDU received.") return None except socket.timeout: print("Receive timeout.") return None except socket.error as e: print(f"Receive error: {e}") return None # 5. 解析响应PDU resp_function_code = pdu_resp[0] if resp_function_code != function_code: # 如果最高位为1，表示异常响应 if resp_function_code & 0x80: error_code = pdu_resp[1] print(f"Modbus exception occurred. Error code: {error_code}") return None else: print(f"Unexpected function code in response: {resp_function_code}") return None # 正常响应：功能码(1) + 字节数(1) + 寄存器值(N*2字节) byte_count = pdu_resp[1] data_bytes = pdu_resp[2:] # 将字节数据转换为整数列表（每2字节一个寄存器） registers = [] for i in range(0, byte_count, 2): # 注意：Modbus协议传输是大端字节序 reg_value = struct.unpack_from('>H', data_bytes, i)[0] registers.append(reg_value) return registers

使用示例：

if __name__ == "__main__": client = SimpleModbusTCPClient('192.168.1.100') # 假设设备IP if client.connect(): # 读取从地址107开始的3个保持寄存器 values = client.read_holding_registers(107, 3) if values: print(f"Read values: {values}") # 期望输出类似 [10, 20, 30] client.sock.close()

注意事项与心得：
字节序（Endianness）是头号大敌：struct.pack('>BHH', ...)里的>表示大端（网络字节序）。这是Modbus标准规定的。但有些非标设备可能用小端序传输寄存器内的高低位字节（即一个寄存器内的两个字节顺序相反），这就需要在解析时额外处理。遇到读出来的值完全对不上时，首先怀疑字节序。
事务ID的管理：这个简单的例子用了自增计数器。在多线程或异步环境下，你必须确保每个请求的事务ID是唯一的，并且能将响应正确匹配回对应的请求。通常用一个字典或队列来管理。
粘包处理：TCP是流式协议，没有“报文”边界。recv(7)可能一次收不到完整的7字节头，也可能一次收到多于7字节（包含了部分PDU）。上面的代码做了两次recv，是一种简化。更健壮的做法是使用缓冲区，持续读取直到收够MBAP头，解析出长度后，再持续读取直到收够完整的PDU。
超时与重试：工业网络不稳定，一次收发失败很常见。必须在业务逻辑外层封装重试机制（例如失败后重试2次，每次间隔1秒）。

3.3 多功能码集成与数据解析进阶

读寄存器只是开始，一个完整的客户端还需要写寄存器、读写线圈等功能。代码结构类似，主要是PDU构建和响应解析不同。

写单个寄存器（0x06）示例：

def write_single_register(self, address, value): """写单个寄存器 (功能码 0x06)""" function_code = 0x06 pdu = struct.pack('>BHH', function_code, address, value) mbap_header = self._build_mbap_header(len(pdu)) request = mbap_header + pdu # ... 发送和接收逻辑与读操作类似 ... # 正常响应应原样回传请求的PDU

写多个寄存器（0x10）示例（更复杂）：

def write_multiple_registers(self, start_address, values_list): """写多个寄存器 (功能码 0x10)""" function_code = 0x10 quantity = len(values_list) byte_count = quantity * 2 # PDU结构：功能码(1) + 起始地址(2) + 数量(2) + 字节数(1) + 值(N*2) pdu = struct.pack('>BHHB', function_code, start_address, quantity, byte_count) # 逐个打包寄存器值（大端序） for val in values_list: pdu += struct.pack('>H', val) # ... 发送和接收 ... # 正常响应应回传：功能码(1) + 起始地址(2) + 数量(2)

数据解析的坑：读回来的寄存器值是16位无符号整数。但实际数据可能是：

有符号整数：值大于32767时，可能是负数（补码表示）。需要判断if val > 32767: val -= 65536。
32位浮点数：占用两个连续的寄存器。你需要将这两个寄存器的4个字节按正确的顺序（可能是ABCD，也可能是CDAB，甚至是BADC！）组合起来，再用struct.unpack('>f', bytes)解析。顺序必须严格参照设备手册。
长整数（32/64位）：同样涉及多个寄存器的拼接和字节序问题。

4. 工业现场调试与排错全记录

协议懂了，代码也能跑了，但到了现场，通信还是不通，或者时好时坏。这才是真正考验工程师功力的地方。下面是我总结的排查流程和常见问题。

4.1 系统性排查流程：从物理层到应用层

遇到通信问题，一定要按层次，从下往上排查，切忌一上来就抓包看数据。

第一步：物理与网络层检查

网线/交换机：网线是否插好？交换机对应端口的指示灯是否正常闪烁？尝试更换网线或交换机端口。工业现场网线容易被拉断、压坏。
IP地址与子网掩码：确认客户端和服务器设备是否在同一个网段。ping命令是最直接的测试工具。如果ping不通，检查设备IP配置、电脑防火墙（临时关闭防火墙测试）、以及是否有IP冲突。
端口可达性：使用telnet [设备IP] 502命令测试502端口是否开放。如果连接被拒绝，说明设备Modbus TCP服务未开启或端口被屏蔽；如果连接超时，可能是网络不通或防火墙拦截。

第二步：协议与交互层检查如果网络通了，但数据不对，就需要用工具抓包分析了。

使用Modbus Poll/Simulator：这是最常用的调试软件。在客户端电脑上运行Modbus Poll，配置好设备IP、端口、从站地址、功能码、寄存器地址。如果这里能正常读写，说明问题在你的程序；如果不能，说明问题在设备或网络配置。
使用Wireshark抓包：这是终极武器。在客户端电脑上抓取所有与设备IP的通信。
- 过滤器：tcp.port == 502
- 看什么：
  - 三次握手：有没有完整的SYN -> SYN-ACK -> ACK？没有则连接建立失败。
  - 你的请求：数据包是否发出？报文格式是否正确（MBAP头、功能码、地址）？
  - 设备的响应：设备有没有回包？回的是正常响应还是异常响应（功能码最高位为1）？
  - 异常码：如果设备返回异常码（如0x83后面跟错误码），根据错误码判断：
    - 0x01：非法功能码（设备不支持此功能）
    - 0x02：非法数据地址（地址不存在或不可访问）
    - 0x03：非法数据值（写入的值超出范围或数量非法）
    - 0x04：从站设备故障（设备内部错误）

第三步：程序与配置层检查

地址映射问题：这是最高频的错误来源。确认你程序中使用的“起始地址”是协议地址（从0开始），还是设备厂商定义的地址（如4x1001）。两者通常相差1。例如，设备手册说“温度参数地址为40100”，那么协议地址通常是40100 - 40001 = 99 (0x0063)。
字节序问题：对于32位或64位数据，检查设备要求的字节顺序和字顺序。用Wireshark对比你发出的数据，和设备手册示例的数据，一个字节一个字节地核对。
连接管理：你的程序是短连接（每次读写都新建连接）还是长连接？短连接在频繁读写时效率低，且可能耗尽服务器端的连接资源。长连接需要处理断线重连和心跳。

4.2 常见疑难杂症与解决方案速查表

现象	可能原因	排查步骤与解决方案
连接超时/失败	1. IP地址错误或不在同一网段。 2. 设备未上电或网络服务未启动。 3. 电脑或设备防火墙拦截502端口。 4. 网线、交换机故障。	1. 检查IP、子网掩码、网关。 2. Ping测试。检查设备状态指示灯。 3. 关闭防火墙测试（生产环境需谨慎）。 4. 更换网线，观察交换机端口灯。
能连接，但读回全是0或65535	1. 从站地址（单元标识符）错误。 2. 寄存器地址映射错误（最常见）。 3. 功能码错误（如用0x03读了输入寄存器区）。	1. 确认设备Modbus从站地址，在MBAP头中正确设置单元ID。 2. 仔细核对设备手册的地址说明，尝试地址+1或-1。 3. 确认要读的数据属于哪个区（4区保持寄存器，3区输入寄存器）。
读回的数据值完全不对	1. 字节序错误（大端/小端）。 2. 数据格式理解错误（如浮点数、有符号数）。 3. 寄存器数量或顺序错误。	1. 用Wireshark抓包，与手册示例对比字节顺序。 2. 确认数据格式，编写对应的解析代码进行转换。 3. 确认读取的起始地址和数量是否准确覆盖了目标数据。
写操作不生效	1. 寄存器只读。 2. 写入的值超出设备允许范围。 3. 需要特定的“使能”位或操作序列。	1. 检查手册，确认该地址是否可写。 2. 检查值域范围，是否需先写入特定命令字。 3. 有些设备写参数需要先发“解锁”命令，或写入后需要重启。
通信间歇性失败，时好时坏	1. 网络干扰或负载过大。 2. 设备处理能力不足，响应慢。 3. 程序未处理粘包/半包，解析混乱。 4. 连接数过多，服务器资源耗尽。	1. 检查网络负载，隔离干扰源（如大功率变频器）。 2. 增加超时时间，降低轮询频率。 3. 完善程序的数据接收缓冲区和报文完整性判断逻辑。 4. 优化程序，使用连接池，及时释放无用连接。
返回异常码0x02（非法地址）	请求的地址超出了设备支持的地址范围。	核对设备手册的地址表，确认地址是否有效。注意有些设备的地址区不是连续的。
返回异常码0x03（非法数据值）	请求中“数量”字段的值超出了设备单次处理的能力。	查阅手册，找到设备单次读写数量的上限，将请求拆分。

4.3 性能优化与稳定性保障心得

在数据点成百上千、要求实时性的SCADA系统中，Modbus TCP的效率和稳定性至关重要。

连接策略选择：
- 短连接：每次请求新建连接，用完即关。实现简单，但TCP三次握手开销大，频繁操作时延迟高，且可能触发服务器端的连接数限制或TIME_WAIT状态积累。仅适用于极低频操作。
- 长连接（推荐）：建立连接后保持，用于多次请求。必须实现心跳机制（例如每30秒读一个固定寄存器），并监听Socket异常，实现自动重连。这是工业应用的标准做法。
请求合并与优化：
- 避免用多个0x03读命令去读零星分布的寄存器。尽量将地址连续的寄存器合并到一次请求中读取，充分利用单次请求的数量上限。
- 对于写操作，同样优先使用0x10写多个寄存器，而不是多个0x06。
超时与重试策略：
- 设置合理的超时时间（如连接超时3秒，读写超时2秒）。超时后不应立即报错，应有重试机制（如重试2次）。
- 重试间隔最好有指数退避，比如第一次等1秒，第二次等2秒，避免网络恢复瞬间的请求风暴。
资源管理与线程安全：
- 如果有多线程需要访问同一个Modbus设备，不要每个线程创建自己的连接。应该设计一个连接管理类，提供线程安全的请求方法，内部管理一个共享的连接和请求队列，避免连接冲突和资源浪费。

5. 高级应用与生态工具

掌握了基础通信，可以看看更高级的应用场景和周边工具，这些能极大提升开发调试效率。

5.1 串口服务器（网关）的桥接配置

很多现场设备只有RS485/RS232接口，需要通过串口服务器（如MOXA、有人、泓格等品牌）接入以太网。这时，Modbus TCP客户端（你的程序）访问的是串口服务器的IP，而单元标识符（Unit ID）就对应着服务器后面挂的串口设备的从站地址。

配置关键点：

串口参数：在串口服务器Web配置页，设置与下端串口设备完全一致的波特率、数据位、停止位、校验位。
工作模式：选择“TCP Server”模式，并设置监听端口（通常就是502）。
协议转换：大多数串口服务器支持“透明传输”，即把TCP数据包原样转发到串口。这时，你发出的Modbus TCP报文中的单元标识符，就会通过串口发送出去，被对应的从站设备识别。
多设备连接：一个串口服务器可以连接一条RS485总线上的多个设备。你的程序通过同一个IP和端口，但使用不同的单元标识符来访问不同的下端设备。

5.2 使用成熟库（如pymodbus）加速开发

对于生产项目，强烈建议使用成熟的库。以pymodbus为例：

from pymodbus.client import ModbusTcpClient client = ModbusTcpClient('192.168.1.100', port=502) connection = client.connect() if connection: # 读保持寄存器 result = client.read_holding_registers(address=107, count=3, slave=1) if not result.isError(): print(result.registers) # 写多个寄存器 client.write_registers(address=108, values=[100, 200], slave=1) client.close()

优势：

处理了所有底层Socket通信、报文组装、解析、超时、重试。
支持同步、异步等多种客户端。
社区活跃，遇到问题容易找到解决方案。

注意事项：即使使用库，也要清楚底层原理。当库报错时，你才能知道是网络问题、协议问题还是数据问题，并可能需要通过设置调试级别或查看源码来定位。

5.3 模拟测试与持续集成

在开发上位机软件时，不可能总连着真实设备。这时需要Modbus从站模拟器。

Modbus Slave：功能强大的模拟器，可以模拟多个从站，定义寄存器的值（支持常量、随机、增量等多种模式），并记录通信日志。是调试客户端程序的利器。
基于代码的模拟：可以用pymodbus的服务器端库在本地启动一个模拟从站，用于自动化测试。

from pymodbus.server import StartTcpServer from pymodbus.datastore import ModbusSlaveContext, ModbusServerContext from pymodbus.datastore import ModbusSequentialDataBlock # 创建一个数据块，初始化保持寄存器 store = ModbusSlaveContext( hr=ModbusSequentialDataBlock(0, [10]*100) # 从地址0开始，100个寄存器，值都是10 ) context = ModbusServerContext(slaves=store, single=True) # 启动服务器在5020端口 StartTcpServer(context=context, address=("localhost", 5020))

这样，你就可以用客户端连接localhost:5020进行测试，而无需硬件。

最后，关于Modbus TCP，我的体会是，它就像工控领域的“普通话”，简单通用，但各地口音（设备厂商的实现）略有不同。吃透协议标准是基础，而丰富的调试经验则能帮你快速适应各种“口音”。每次调试新设备，准备好手册、Wireshark和一颗耐心，从物理层到应用层一步步排查，问题总能解决。真正稳定的通信程序，代码里一半是业务逻辑，另一半是异常处理和连接状态管理。