3. Modbus协议详解（下）：Modbus TCP/IP与RTU差异、多从机轮询策略、超时与重试机制

好，咱们接着聊Modbus。上一章我们把RTU的报文格式、CRC校验这些基础打牢了。这一章，我重点聊聊实际工程里最让人头疼的几个问题：TCP和RTU到底怎么选？挂了一堆从机怎么轮询才不卡？还有那个该死的超时重试，到底设多少才合适？

这些问题，说白了就是协议落地时的「最后一公里」。理论大家都懂，但现场跑起来就是另一回事了。我踩过的坑不少，今天全抖出来给你。

3.1 Modbus TCP/IP 与 RTU：同宗不同路

先看个最直观的对比。Modbus RTU走串口（RS-232/485），Modbus TCP走以太网。它们的数据模型、功能码完全一样，但封装方式天差地别。

对比项	Modbus RTU	Modbus TCP/IP
物理层	RS-232 / RS-485	以太网 (RJ45)
传输距离	RS-485 可达1200米	100米（交换机可扩展）
从机数量	最多247个（实际通常32个）	理论无限制（IP地址决定）
报文头	无，直接地址+功能码+数据+CRC	MBAP头（7字节）
校验方式	CRC-16（必须）	无（依赖TCP/IP协议栈）
通信方式	半双工，主从问答	全双工，主从问答
典型场景	分布式、远距离、低成本	高速、大数据量、本地局域网

这里有个关键点：TCP没有CRC校验。为什么？因为TCP/IP协议栈底层已经做了校验和（Checksum），再算CRC就是重复劳动。但RTU不行，串口通信太脆弱了，一个字节错位整个报文就废了，CRC是最后的防线。

3.2 多从机轮询策略：别让总线闲着

储能系统里，一个主机（比如EMS控制器）要轮询几十台从机（BMS、PCS、电表、温控）。怎么轮才高效？我见过最蠢的做法是「挨个问，问完一圈再从头来」。你想想看，如果某个从机挂了，主机傻等3秒超时，整个周期就被拖垮了。

这里我分享三种实战策略：

策略一：顺序轮询 + 动态超时

最基础的做法。主机按地址顺序发请求，每个从机给一个固定的超时时间。但我会加一个「动态调整」：如果某个从机连续3次超时，我把它标记为「离线」，然后跳过它继续轮询。等整圈轮完，再单独补问一次离线设备。

// 伪代码示意
for (addr = 1; addr <= MAX_SLAVES; addr++) {
    if (slave[addr].offline_count > 3) {
        // 跳过，等补问阶段
        continue;
    }
    send_request(addr);
    wait_response(timeout_ms);
    if (timeout) {
        slave[addr].offline_count++;
    } else {
        slave[addr].offline_count = 0;
        process_data();
    }
}
// 补问离线设备
for (addr = 1; addr <= MAX_SLAVES; addr++) {
    if (slave[addr].offline_count > 3) {
        send_request(addr);
        // 只给一次机会
    }
}

策略二：优先级轮询

储能系统里，有些数据是「命根子」——比如总电压、总电流、绝缘电阻。这些必须高频读取。而温度、历史数据可以慢点。我会把从机分成两组：

• 高优先级组：每100ms轮一次
• 低优先级组：每1000ms轮一次

高优先级组轮完一轮，再插空轮低优先级。这样既保证关键数据实时性，又不浪费总线带宽。

策略三：广播与组播

Modbus支持广播地址（0x00），所有从机同时接收但不回复。这个在储能里很有用——比如同时下发「启动均衡」指令。但注意：广播没有应答，你无法确认从机是否收到。所以我只在「非关键控制」场景用广播，关键指令还是逐个发。

3.3 超时与重试机制：设错了全盘皆输

超时时间设多少？这是新手最容易翻车的地方。设短了，正常响应被误判为超时；设长了，整个轮询周期被拖死。

我一般按这个公式算：

超时时间 = 从机处理时间 + 报文传输时间 × 2 + 安全余量

举个例子：

• 从机处理时间：一般BMS处理一个读请求需要10-50ms（看CPU性能）
• 报文传输时间：9600波特率下，一个字节约1ms，读10个寄存器报文约20字节，传输约20ms
• 安全余量：我习惯加50ms

算下来：50ms + 20ms×2 + 50ms = 140ms。我一般取整设150ms或200ms。

重试策略：指数退避 vs 固定间隔

超时后要不要重试？当然要。但怎么重试有讲究。

• 固定间隔重试：每次等200ms再重试，最多3次。简单粗暴，但容易在总线拥堵时雪上加霜。
• 指数退避：第一次等200ms，第二次等400ms，第三次等800ms。给总线喘息的机会。我强烈推荐这个。

// 指数退避示例
int retry_count = 0;
int base_timeout = 200; // ms
while (retry_count < 3) {
    send_request(addr);
    if (wait_response(base_timeout * (1 << retry_count))) {
        // 成功，处理数据
        break;
    }
    retry_count++;
    // 这里可以加日志：从机X第Y次超时
}

嗯，这里要注意：重试次数不是越多越好。3次是黄金数字。超过3次还没响应，大概率是从机掉线了，再重试也是浪费带宽。

3.4 知识体系总览

说了这么多，我画张图帮你理清思路。这张图涵盖了本章的核心逻辑：从协议差异到轮询策略，再到超时重试，环环相扣。

这张图把三个核心模块串起来了。你从左往右看：先搞清楚用TCP还是RTU，然后根据从机数量和重要性选轮询策略，最后用合理的超时重试机制兜底。三者缺一不可。