多台 Modbus RTU 设备共用 RS485 总线，轮询周期和超时怎样设计？

在工业数据采集系统中，经常需要通过一条 RS485 总线连接多台仪表、传感器或控制设备，再由工控机或嵌入式主控统一读取数据。

设备数量较少时，简单的串口轮询通常就能满足要求。但随着接入设备增加，系统可能逐渐出现一些问题：

• 某台设备响应变慢，导致其他设备的数据更新也受到影响。

• 一台设备掉线后，上位机长时间等待，整轮采集周期明显变长。

• 通信程序不断重试，任务队列积压，界面显示的数据越来越滞后。

• 实际轮询周期与最初设定的采集周期不一致，无法满足现场的数据刷新要求。

这些问题并不一定是 RS485 通信速率不足造成的。很多时候，真正需要调整的是轮询任务的组织方式、响应超时策略和异常设备处理机制。

设计多设备 Modbus RTU 采集系统时，首先要明确一件事：RS485 总线上的通信是按顺序完成的，系统的实际采集周期取决于每次请求、设备响应、帧间隔以及异常处理所消耗的总时间。

一、先区分单设备轮询间隔和整轮采集周期

在讨论轮询参数之前，需要先明确几个容易混淆的概念。

单设备轮询间隔，是同一台设备两次收到有效读取请求之间的时间。

整轮采集耗时，是上位机从发出第一台设备的请求，到收到最后一台设备的有效响应，完成一轮设备读取所需要的时间。

连续轮询周期，则是相邻两轮轮询开始时刻之间的时间间隔。

数据新鲜度，是当前时刻与数据最近一次产生或被成功获取的时间之间的差值。

这几个指标并不相同。

例如，一条 RS485 总线上连接了 10 台设备，上位机依次读取每台设备的数据。如果每台设备平均需要 80ms 才能完成一次请求和响应，那么不考虑其他开销，一轮读取就需要约 800ms。

这意味着，即使程序设置了每 100ms 执行一次轮询，也不代表 10 台设备都能每 100ms 更新一次数据。

如果任务执行时间已经超过设定周期，后续轮询任务就可能出现延迟、排队甚至重复执行。

因此，项目需求不能只写一个笼统的“采集周期100ms”，而应该明确：

• 每台设备要求的数据更新频率。

• 所有设备完成一轮采集允许的最长时间。

• 不同测点是否允许采用不同的更新周期。

• 单台设备异常时，其他设备是否仍需正常采集。

还需要注意数据时间戳的含义。如果设备没有提供源端采样时间戳，主站通常只能记录最近一次成功读取的时间。这个时间代表数据被主站成功获取的时刻，不一定等于设备内部测量值实际产生的时刻。

因此，数据模型中最好分别保留设备采样时间（如果设备提供）和主站接收时间，避免将两者混为一谈。

二、为什么同一条 RS485 总线不能简单并行轮询？

Modbus RTU 串行通信采用主从式请求与响应机制。

在一条标准 Modbus 串行总线上，通常由一个主站发起请求，从站收到针对自身地址的请求后再返回响应。各从站不会主动向主站发送数据，也不会相互通信。

主站在上一笔事务完成之前，不能再发起另一笔并行事务。

例如总线上有三台设备：

• 设备01：温度采集仪。

• 设备02：压力变送器。

• 设备03：流量计。

正常的通信过程是：

上位机向设备01发送请求，等待响应并完成校验；然后向设备02发送请求；收到响应以后，再读取设备03。

不能因为上位机有多核CPU，就同时向三个从站发送请求，期待它们并行返回数据。

如果多个线程同时操作同一个串口，可能出现请求交叉、响应错配、收发方向控制冲突等问题。

对于同一条 RS485 总线，更合理的做法是：

由一个统一的通信调度器管理发送顺序，每次只允许一笔事务处于等待响应状态。

如果设备分别连接到不同的独立串口或独立总线，则可以为每条总线配置独立的通信任务，实现不同总线之间的并行采集。

这里还需要区分 Modbus 地址数量和 RS485 电气负载能力。

Modbus 串行地址中，1～247用于单独寻址。但这不意味着一条普通 RS485 总线就可以直接连接247台设备。

Modbus Serial Line V1.02 指南规定，无中继器的 RS485-MODBUS 系统允许接入32台设备。采用较低 Unit Load 的收发器时，部分系统可以支持超过32台，但需要根据设备厂商明确给出的接入能力、总线偏置和线路负载情况重新核算，不能直接按照 Modbus 地址数量推算物理总线容量。

三、轮询周期应该怎样计算？

轮询周期不是简单的“设备数量乘以一个固定延迟”。

每台设备的一次完整通信至少涉及：

1. 主站发送请求报文。

2. 从站接收并处理请求。

3. 从站返回响应报文。

4. 主站接收并完成帧校验。

5. 按照协议要求等待必要的帧间静默时间。

6. 通信程序完成任务调度和数据处理。

因此，需要区分理想估算模型和实际测量模型。

1. 理想情况下的轮询时间估算

假设：

• N：设备数量。

• T_req：请求帧传输时间。

• T_resp：响应帧传输时间。

• t3.5：相邻 RTU 帧之间的最小静默时间。

• T_dispatch：额外的主站程序调度开销。

对于 N 台设备，每台设备一次请求和响应，一共需要传输 2N 个 RTU 帧。

从第一帧开始到最后一帧结束，相邻帧之间共有 2N-1 个间隔。

因此，在假设所有相邻帧间隔都恰好满足 t3.5、没有额外从站处理等待的情况下：

理想整轮采集耗时：

T_round ≈ Σ(T_req,i + T_resp,i) + (2N-1) × t3.5 + T_dispatch

这个公式用于估算正常响应情况下的理论时间下限。

设备超时、重试和异常恢复时间，应按照实际发生的事件单独计算，不能作为每轮必然发生的固定时间。

2. 先计算报文实际传输时间

假设通信参数为：

• 波特率：9600bps。

• 数据格式：8E1。

• 通信方式：Modbus RTU。

• 每台设备读取10个保持寄存器。

• 设备数量：20台。

采用 Modbus 功能码03读取连续的10个保持寄存器。

主站请求报文包含：

• 从站地址：1字节。

• 功能码：1字节。

• 起始地址：2字节。

• 寄存器数量：2字节。

• CRC校验：2字节。

请求报文总计8字节。

从站响应报文包含：

• 从站地址：1字节。

• 功能码：1字节。

• 数据字节数：1字节。

• 10个寄存器的数据：20字节。

• CRC校验：2字节。

响应报文总计25字节。

因此，一次完整请求和响应共传输33字节。

在8E1格式下，一个字符通常占11个传输位，即：

1个起始位 + 8个数据位 + 1个校验位 + 1个停止位。

单次请求与响应的传输时间约为：

T_wire = 33 × 11 ÷ 9600 ≈ 37.81ms

20台设备的报文传输时间为：

T_wire_total = 20 × 37.81 ≈ 756.25ms

这还没有计算从站内部处理时间和帧间隔。

3. 不能忽略 Modbus RTU 帧间隔

Modbus RTU 使用静默时间区分报文边界。

根据 Modbus Serial Line Specification V1.02：

• t1.5：帧内相邻字符之间允许的最大静默间隔。

• t3.5：两个 RTU 帧之间要求的最小静默间隔。

在波特率不高于19200bps时，应按照字符时间严格处理这两个间隔。

对于高于19200bps的通信，规范建议采用固定值：

• t1.5：750μs。

• t3.5：1.750ms。

以9600bps、11位字符计算：

t3.5 = 3.5 × 11 ÷ 9600 ≈ 4.01ms

20台设备依次读取，每台设备包含一个请求帧和一个响应帧，共40个帧。

如果所有帧之间都只保留最小静默时间，则共有39个帧间隔。

因此：

39 × 4.01ms ≈ 156.41ms

加上前面的报文传输时间：

756.25ms + 156.41ms ≈ 912.66ms

也就是说，在不考虑额外从站处理时间、驱动延迟和操作系统调度开销的情况下，完成20台设备的一轮读取，理论上已经需要约0.913秒。

4. 从站处理时间不能与实际等待时间重复计算

这里还需要特别注意一个容易出现的计算错误。

从站接收请求后，需要一定时间进行处理并准备响应。这个时间可能已经包含了 RTU 要求的最小帧间静默时间。

假设通过实际测量发现：

从请求帧结束，到响应帧开始发送，平均等待10ms。

那么这10ms已经是请求结束到响应开始的实际总等待时间，其中已经包含至少4.01ms的协议静默要求。

此时不能再额外加一次4.01ms。

对于20台设备，实际计算应为：

• 请求和响应报文传输：756.25ms。

• 20次请求结束到响应开始的实际等待：20 × 10ms = 200ms。

• 19次设备之间的切换间隔：19 × 4.01ms ≈ 76.20ms。

合计：

756.25 + 200 + 76.20 ≈ 1032.45ms。

即约1.032秒。

这里的10ms是假设的实际测量等待时间，不代表所有仪表的标准响应时间。

如果10ms表示的是从站内部处理时间，且不包含协议要求的t3.5，那么就需要另外计算帧间静默时间。此时，整轮采集耗时约为1.113秒。

两种计算结果不同，关键在于10ms究竟代表实际请求到响应的总等待时间，还是不包含协议静默时间的额外处理时间。

工程计算时必须统一时间口径，不能将已经包含在实际等待时间内的t3.5重复累加。

5. 整轮采集耗时与连续轮询周期还需要区分

前面的1.032秒，定义为从第一台设备请求开始，到最后一台设备响应结束的整轮采集耗时。

如果系统需要连续执行下一轮轮询，还需要考虑最后一台设备响应结束，到下一轮第一条请求发送之间的帧间隔及调度时间。

因此，连续两轮开始时刻之间的时间，可能略大于单轮采集耗时。

如果实际一轮采集需要1.032秒，而程序要求每1秒启动一轮，那么这个采集要求在当前通信条件下就无法满足。

这时应重新评估：

• 是否可以合并连续寄存器读取。

• 是否有部分数据可以降低采集频率。

• 是否需要提高波特率。

• 是否需要增加独立串口或划分多条RS485总线。

• 是否可以采用不同优先级的轮询任务。

不能只修改定时器参数，就认为实际采集周期已经满足要求。

四、怎样设计更合理的多设备轮询调度？

在确认总线能够满足基本通信需求后，还需要根据业务要求组织轮询任务。

1. 按数据更新要求划分轮询频率

并不是每台设备、每个寄存器都需要采用相同的采集周期。

例如：

• 设备运行状态：需要较快更新。

• 温度、压力等常规测量值：可以采用相对稳定的周期。

• 设备配置、累计量和诊断信息：通常不需要高频读取。

如果所有数据都按照最快的频率轮询，会占用大量总线时间。

更合理的方式是把数据分为不同优先级，分别安排读取周期。

例如，可以将设备状态、常规测量和低频诊断信息设置为不同的轮询任务。

具体周期需要根据现场业务的实时性要求、设备数量和计算出的总线负载确定，不能直接把示例参数当作通用标准。

2. 合并连续寄存器读取，减少事务数量

如果同一台设备需要读取多个连续寄存器，可以优先考虑一次请求读取一段连续地址，而不是每个寄存器单独发起一次请求。

例如：

原本需要分别读取：

• 40001～40002

• 40003～40004

• 40005～40006

如果设备寄存器映射允许连续读取，可以考虑合并为一次请求。

这样可以减少请求报文、响应报文及帧间隔带来的额外开销。

Modbus功能码03的标准定义允许一次读取最多125个连续寄存器，但具体设备可能有更严格的限制，还需要确认：

• 设备是否支持该功能码。

• 连续地址是否都可以读取。

• 是否存在保留地址或不允许跨越的寄存器区域。

• 单次读取长度是否受到设备固件限制。

不能为了减少通信次数，就把不连续或语义不同的寄存器强行合并。

3. 采用轮询队列，而不是多个任务直接操作串口

对于多设备系统，建议将每次读取操作封装成独立的通信任务。

任务中至少包含：

设备地址、功能码、寄存器起始地址、读取长度、超时时间、优先级、重试策略及任务标识。

通信调度器按照既定规则取出任务，发送请求，等待对应设备响应，完成CRC校验和数据解析后，再执行下一笔事务。

这种设计可以避免多个业务模块直接操作串口造成的资源竞争。

如果某些设备需要更高的采集优先级，也应由统一调度器管理，而不是允许高优先级任务绕过总线互斥规则。

同时需要考虑公平性，避免低优先级设备长期得不到轮询机会。

4. 防止定时轮询任务不断积压

实际项目中，还需要特别注意定时任务的执行方式。

例如：

• 设置整轮轮询周期为1秒。

• 实际一轮采集需要1.2秒。

• 下一轮定时任务已经触发。

• 如果程序仍然不断创建新一轮任务，就会逐渐积压。

对同一条RS485总线，应限制同时运行的轮询轮次。

当上一轮尚未完成时，下一次定时触发不应无条件再创建一整轮任务。

可以根据业务要求采用：

• 跳过策略： 上一轮未完成时，跳过本次触发，避免任务积压。

• 合并策略： 将重复的读取请求合并，优先保留最新的数据采集需求。

• 延后策略： 上一轮完成后再启动下一轮，允许实际轮询周期随通信耗时变化。

具体采用哪种方式，需要根据实时性和数据完整性要求确定。

对于实时监测系统，通常应优先保证任务队列有界、数据更新及时，而不是机械地执行所有历史定时触发。

五、设备超时、重试和离线处理怎样设计？

多设备系统最容易出现的性能问题之一，就是某台设备掉线后，其他设备也跟着变慢。

例如，一条总线上有20台设备，其中第8台突然断电。

如果程序给每台设备都配置了很长的固定超时时间，而且超时后无限重试，那么第8台设备就可能持续占用大量通信时间。

因此，超时和重试策略需要单独设计。

1. 响应超时不能直接等同于帧间隔

这里要区分两个概念：

帧间静默时间，是 Modbus RTU 协议用于识别报文边界的时间要求。

响应超时时间，是主站发出请求后，等待从站返回有效响应的最大时间。

两者用途不同。

响应超时应根据设备实际处理能力和通信环境确定。

Modbus Serial Line V1.02 指南明确指出，单播响应超时由应用决定，必须足以覆盖从站处理请求并返回响应的时间。该指南给出了9600bps下通常为1秒至数秒的典型参考范围。

这并不是要求所有设备都必须等待1秒，更不是适用于所有现代设备的固定参数。

实际项目中，应该采集正常通信时的响应时间分布，再结合最慢设备的响应能力、系统允许的数据延迟和总线轮询预算确定超时值。

对于响应速度较快、协议和硬件条件明确的设备，可以采用更短的超时；对于内部处理时间较长的仪表，则需要适当增加等待时间。

另外，广播请求不等待从站响应，使用的是单独的 Turnaround Delay（处理转换等待时间），不能与单播响应超时混淆。

2. 不同设备可以采用不同超时策略

多台设备共用一条总线时，不建议所有设备都采用完全相同的超时参数。

例如：

• 快速响应设备：依据实测响应时间设置较短超时。

• 响应较慢设备：根据设备规格单独设置超时。

• 连续超时设备：减少轮询频率，避免反复占用总线。

• 普通测量读取：有限重试，必要时推迟到下一轮。

• 控制及参数写入：额外确认重复执行的安全性。

例如20台设备中有一台掉线，如果该设备每轮都等待1秒并重试一次，仅这台设备就可能额外占用约2秒。

因此，超时和重试次数必须纳入整轮采集时间预算，而不能只考虑正常通信情况。

3. 区分超时、CRC错误和Modbus异常响应

这三种情况不应该统一记为设备离线。

Modbus异常响应通常通过将原请求功能码的最高位置1来表示，并在响应中携带异常代码。

例如：

• 01：非法功能。

• 02：非法数据地址。

• 03：非法数据值。

• 04：从站设备故障。

这类响应本身说明主站已经收到了从站返回的有效协议数据，只是请求执行出现了异常。

因此，应将通信链路错误与设备业务处理错误分别记录。

4. 重试次数应该有限制

通信出现异常后，不建议无条件连续重试。

可以根据业务重要程度区分处理：

• 普通测量数据：允许有限次数的重试，超过限制后记录本次采集失败。

• 重要运行状态：根据数据时效要求设置恢复探测策略。

• 参数写入和控制命令：必须先明确重复执行是否安全，不能因为响应丢失就默认再次发送。

特别需要注意，写入请求已经被设备执行，但响应报文在传输过程中丢失时，上位机可能误认为写入失败。

如果此时直接重复执行，可能产生重复动作。

因此，涉及启动、复位、计数器清零等具有实际副作用的操作，必须单独设计命令确认和幂等处理机制。

5. 对异常设备进行逻辑隔离

当某台设备连续出现超时、CRC错误或无效响应时，可以将其标记为通信异常状态。

例如：

正常通信 → 首次超时 → 有限重试 → 标记异常 → 降低探测频率 → 恢复后重新加入正常轮询。

这里的隔离是软件层面的逻辑隔离和降频探测，并不是物理断开RS485设备。

可以为每台设备维护：

• 最近一次成功通信时间。

• 连续失败次数。

• 最近一次错误类型。

• 当前通信状态。

• 下一次探测时间。

设备恢复后，应通过有效响应确认其重新在线，而不是仅仅因为串口重新打开就把设备状态改成正常。

这种机制能够降低单台设备异常对整条采集链路的影响。

六、上位机软件架构应该怎样组织？

轮询策略最终还需要落实到上位机软件结构中。

对于常见的工业上位机，可以将通信部分划分为几个相对独立的模块：

第一层：通信调度层

负责设备轮询顺序、任务队列、优先级、超时和重试。

第二层：串口收发层

负责串口打开、参数配置、发送数据、接收缓存以及RS485收发方向控制。

第三层：协议解析层

负责识别从站地址、功能码、数据长度、CRC校验和异常响应，并将原始数据转换为统一的数据结构。

第四层：业务数据层

负责数据有效性判断、工程单位转换、状态更新和数据保存。

第五层：界面展示层

负责实时数据显示、曲线刷新、设备状态展示和通信异常提示。

这些模块之间应该通过明确的接口传递数据。

尤其不能让界面线程直接执行阻塞式串口读取，否则某台设备超时就可能造成整个界面卡顿。

通信线程负责完成收发和解析，业务层接收有效数据，界面层按照适当的刷新频率更新显示。

对于数据量较大的系统，还需要考虑队列容量和数据处理速度，防止通信已经完成，但数据处理或数据库写入速度跟不上，最终造成缓存积压。

如果项目还涉及硬件、固件和上位机之间的责任划分，可以参考《数据采集设备定制开发中，硬件、固件、上位机分别负责什么？》。

七、系统调试时应该验证哪些指标？

通信程序能够正常读取数据，只能证明基本通信链路已经建立，不能说明多设备轮询已经满足项目要求。

建议在系统联调阶段，至少验证以下几类情况。

除了软件日志，必要时还应使用串口分析工具或逻辑分析仪观察实际总线信号。

尤其需要检查：

• 主站请求与从站响应是否正确对应。

• RS485发送和接收方向切换是否正常。

• 是否出现多个驱动器同时发送造成的总线冲突。

• RTU帧间静默时间是否满足要求。

• 是否存在异常长的等待时间或重复请求。

建议记录每台设备的平均响应时间、P95响应时间、最大响应时间、超时次数、CRC错误次数和最近一次成功通信时间。

其中，P95响应时间能够帮助识别那些平时正常、偶尔明显变慢的设备。

最终验收不能只检查程序设置了多少毫秒的轮询周期，而应该验证实际设备在正常和异常工况下，能否满足约定的数据更新时效。

八、项目实施前需要明确哪些参数？

在正式开发多设备采集系统之前，建议先确定以下信息：

这些参数共同决定了系统能够接入多少设备、以多快的速度完成数据采集，以及出现异常时能否继续稳定运行。

如果设备数量增加以后，单条总线已经无法满足数据更新要求，还可以进一步评估提高波特率、增加独立通信接口、划分多个RS485总线或通过网关进行分组采集。

但需要注意，提高波特率并不一定能解决所有问题。如果现场布线、终端匹配、设备响应时间和软件调度存在问题，单纯提高通信速率可能无法获得预期效果。

在RS485总线布线方面，还应注意主干与支线的拓扑关系。按照Modbus Serial Line V1.02指南，主干总线两端应设置终端匹配，短支线上不应额外安装终端匹配，避免产生过多负载和信号反射。具体终端阻值、偏置电阻及布线方式，还需要结合设备接口和现场线路条件确定。

九、北京心玥科技的工业设备通信与软件开发

北京心玥科技有限公司可根据项目需求，参与工业数据采集设备、嵌入式控制设备及相关软件系统的研发。

在涉及多设备通信的项目中，可以根据实际需求开展RS485等通信接口设计、设备协议适配、嵌入式软件、上位机通信调度、数据解析与存储，以及相关管理软件开发。

对于已有设备或已有通信协议的项目，也可以结合现有硬件接口、寄存器定义、设备数量和现场通信条件，评估现有系统的适配与改造范围。

具体采用单总线轮询、多总线分组还是网关汇聚，需要结合设备数量、实时性要求、现场布线及系统扩展需求确定。

工业通信系统真正需要解决的，不只是设备能否连接和读取数据，而是当设备数量增加、个别设备异常或运行时间延长时，整个系统仍然能够按照约定的时间和规则稳定工作。

技术参考资料

1. Modbus Serial Line Protocol and Implementation Guide V1.02（Modbus官方规范）

2. Modbus Application Protocol Specification V1.1b3（Modbus官方规范）

3. Modbus Organization 官方规范入口