干这行时间长了你会养成一个职业病拿到一台设备、一组参数脑子里先估一遍“这一轮采集得多久”而不是等上位机刷新出来了再去拍脑袋。尤其是Modbus RTU挂在RS485总线上做多从站轮询的时候读寄存器到底耗时多少直接决定了你的扫描周期、PLC程序里通信超时设置、上位机刷新率甚至整个系统能不能稳定跑下去。这个话题看着基础但真能算明白、而且知道算完怎么用的人其实不多。我在现场就吃过亏。一套水处理项目上位机要轮询三十几台仪表客户抱怨数据刷新太慢我一查项目配置从站地址1到32每站读10个寄存器波特率9600。当时说不出具体数字只能含糊说“应该还行吧”结果被现场经理盯着改参数。后来我把这套耗时模型完整推了一遍从帧结构到字节时间到从站响应延时全串起来才真正把这个问题吃透。今天就把这套计算方法和工程经验完整写出来帮你在做Modbus RTU RS485方案时不用靠猜直接能算出答案。1. 先拆帧一次读寄存器请求/响应到底多少字节1.1 请求帧固定8字节一个都不能多Modbus RTU读保持寄存器就是功能码030x03这是整个协议族里用得最多的操作。要算耗时第一步就是搞清楚一个请求帧在总线上有多少字节。这个不是背下来的是你得能从帧结构推出来。请求帧构成按发送顺序从站地址1字节范围1到2470是广播248到255是保留。功能码1字节读保持寄存器就是0x03。起始寄存器地址2字节高字节在前16位地址空间对应40001到49999这类映射。寄存器数量2字节表示要连续读多少个寄存器。CRC校验2字节CRC16低字节在前高字节在后。加起来112228字节。这个数字是固定的跟从站地址是多少、读多少个寄存器没有关系只要你用功能码03读寄存器请求帧就是8字节。这里有个细节必须提醒寄存器数量在标准Modbus协议里是有上限的。功能码03一次最多读125个寄存器0x7D原因在协议的数据包大小约束里响应帧携带数据不能超过253字节。很多初学者不知道这个限制配置的时候一次读200个寄存器结果设备直接返回异常码03非法数据值这就是把帧结构搞清楚了就不会犯的错。顺便说一句读保持寄存器是03读输入寄存器是04两者请求帧结构完全一样只是功能码差1。1.2 响应帧随寄存器数量线性增长别把字节计数字段漏了请求帧固定8字节但响应帧不是固定的它跟读取的寄存器数量线性相关。这很好理解从站得把你要的数据塞进帧里返回给你。正常响应帧构成从站地址1字节。功能码0x031字节。字节计数1字节这个字段的值等于“寄存器数量×2”因为每个寄存器占2字节。寄存器数据寄存器数量×2字节按地址顺序排列每个寄存器高字节在前。CRC校验2字节。所以响应帧总长度 1112N2 52N个字节N就是本次读取的寄存器数量。举几个具体数字读取寄存器数量N数据区字节数响应帧总字节数12710202550100105100200205125上限250255注意那个“字节计数”字段这是新手最容易漏算的。有人算响应帧会把寄存器数据直接当2N却忘了还有一个专门报数据长度的字节算出来整帧偏小1字节。1字节在9600波特率下约1.04毫秒单帧看不出来轮询几十台从站累积误差几十毫秒你按错误模型去设置超时就可能在临界状态下触发误判。还有一点读单个寄存器时响应帧只有7字节比请求帧还短这在串口通信里显得有点“不平衡”但协议就是这么设计的。如果你做的是高性能轮询最好心里记住读1个寄存器时总线上跑的数据量是8715字节加上帧间隙实际占线时间并不算短。这也是后面要讲“合并寄存器读取能大幅提升效率”的根源。2. 耗时计算的核心模型位时间、字节时间与帧间隙2.1 8N1还是8E1一个字节的传输时间差多少帧字节数搞清楚之后第二步就是把“字节数”换算成“时间”。串口是逐位传输的一个字节在总线上不是8位而是包含起始位、数据位、校验位、停止位。这个初学者特别容易搞混。标准串口一帧字符的组成起始位1位固定为低电平标志一个字符开始。数据位常为8位Modbus RTU标准要求8位或7位实际几乎都是8位。校验位可无N、奇校验O、偶校验E选一个。停止位1位或2位。所以一个“字符”实际占用的位数是1起始8数据校验位停止位。8N1就是“8数据位、无校验、1停止位”总共10位8E1就是“8数据位、偶校验、1停止位”总共11位。这里插一句很多人会问Modbus RTU到底用8N1还是8E1。标准Modbus RTU推荐的是8E1或者8N1实际工程中两种都在用关键是你主站和从站必须统一否则通信全是乱码。很多国产仪表出厂默认9600 8N1欧美一些设备默认19200 8E1。你接手改造老设备时第一件事就是确认这个参数。位时间 1除以波特率这个不用多说。字节时间 位时间乘以每个字符的总位数。以9600波特率为例8N1字节时间 10/9600 ≈ 1.0417毫秒。8E1字节时间 11/9600 ≈ 1.1458毫秒。两者差了大约0.1毫秒/字节单帧看不出来但一帧读100个寄存器的响应帧205字节8E1就比8N1多花约21毫秒。如果你的系统在波特率较低、数据量大的场景下这个差异已经能影响性能了。我常用的速查表给你列好字节时间单位毫秒波特率8N110位/字节8E1或8O111位/字节96001.04171.1458192000.52080.5729384000.26040.2865576000.17360.19101152000.08680.0955后面所有计算我统一按8N1来如果你现场是8E1把对应数值替换进去就行计算逻辑一模一样。2.2 3.5字符帧间隔Modbus RTU里的“停顿规则”Modbus RTU是帧同步协议没有专用的帧头帧尾怎么区分一帧的起止靠“空闲时间”。协议规定一帧开始前总线上至少要有3.5个字符时间的静默期帧内部两个字节之间的间隔不能超过1.5个字符时间一旦超过接收方就认为帧不完整直接丢弃。这个规则的工程意义很实际它保证了接收方能在字节流里准确切分出每一帧的边界。那3.5个字符时间是多少直接算9600波特率8N13.5×1.0417 ≈ 3.65毫秒。192003.5×0.5208 ≈ 1.82毫秒。1152003.5×0.0868 ≈ 0.30毫秒。这个时间在计算单次读操作耗时的时候必须算进去。一个完整的读操作时间轴大概是这样的主站发送8字节请求帧耗时T_req。请求帧结束从站检测到3.5字符静默期确认一帧完成开始应用层处理。从站处理完成发送响应帧耗时T_res。主站同样需要检测3.5字符静默期确认响应帧结束本轮事务完成。所以在一次事务里至少有两个3.5字符间隔要算进去。我见过很多人算Modbus通信时间只算请求帧和响应帧的字节时间把帧间隔漏了尤其9600波特率下一次事务就少算7.3毫秒左右。乍一看不多但轮询32个从站累积下来就是230多毫秒相当于扫描周期凭空被低估了四分之一秒。还有一个工程细节1.5字符间隔是检测帧内断帧的理论上也要保证但正常通信时帧内字节是连续发送的间隔极小不会触发。只有在主站软件驱动写得比较差、字节间发送间隔超过1.5字符时间的情况下才会导致从站把一帧拆成两帧处理。这个问题不好排查因为不是每次都发生偶尔抽风。后面问题章节我详细讲。2.3 从站处理时间与485半双工切换时间怎么估计理论模型里最容易低估、也是实际偏差最大的就是从站处理时间。所谓处理时间就是从站接收到完整请求帧到开始发送响应帧之间内部的延迟。注意这个时间不是总线上传输的时间而是从站固件“消化”请求、组织数据、发起响应的时间纯开销。这个时间有多少看设备档次快速设备专用通信芯片、实时性好的固件比如一些高端PLC、仪表模块处理时间可以到1到5毫秒。中等设备常规工业仪表、电表、温控器处理时间通常在10到50毫秒之间。有些设备手册会写“响应时间≤50ms”。慢速设备一些老式仪表或者带沉重周期任务的设备处理时间可能到100毫秒以上甚至极端情况存在200到500毫秒的响应延迟。这个参数查设备手册最直接手册里“响应时间”或“通讯响应时间”那一栏写的就是你要的T_handle。查不到你就实测用一个串口监视工具抓请求和响应时间戳两者的间隔就是处理时间帧间隔。这里必须强调从站处理时间是独立于波特率存在的。波特率只影响总线传输部分的时间从站固件处理并不因为波特率从9600升到115200就变快。这就引出一个后面要讲的结论当从站处理时间在总耗时里占比很高时单纯提高波特率的效果是有限的。再加上485是半双工方向切换也需要时间。物理层收发器从接收切换为发送一般几十微秒到几百微秒常规的自动收发电路也就这个量级。但如果你用的是软件控制方向切换比如普通USART芯片靠RTS拉高拉低切方向驱动的切换时间可能到1到2毫秒这个在高速轮询时也是一笔开销。好在多数支持自动收发的485模块已经把这部分时间压得很低了工程计算可以先忽略或用0.5到1毫秒估算但对性能敏感的场合不要完全无视。3. 完整时间测算从单次读操作到整条总线的轮询周期3.1 单帧时间速查表9600到115200全覆盖先把各种波特率下的单帧传输时间给你算好这张表在实际配参、和现场扯皮的时候可以直接拿来用。8N1模式。波特率8字节请求帧耗时7字节响应帧耗时读1个寄存器25字节响应帧耗时读10个寄存器205字节响应帧耗时读100个寄存器96008.33ms7.29ms26.04ms213.54ms192004.17ms3.65ms13.02ms106.77ms384002.08ms1.82ms6.51ms53.39ms576001.39ms1.22ms4.34ms35.59ms1152000.69ms0.61ms2.17ms17.80ms从这张表能读出什么信息第一读1个寄存器时请求帧和响应帧加起来在9600波特率下也只有15.62毫秒单独看很小。但注意这只是“纯传输时间”还没算帧间隔和处理时间。做轮询设计时如果只按这个数算一定会被实测结果打脸。第二读100个寄存器的响应帧在9600下是213.54毫秒这个数已经很大了。对于一个扫描周期要求1秒以内的系统这一个操作就占了约五分之一的总线时间如果从站处理时间再加50毫秒你在9600下根本不可能做到高频刷新。第三波特率提高12倍从9600到115200传输时间大致缩到原来的十二分之一左右。这个收益非常显著前提是总线上所有设备都能稳定运行在115200且线缆质量、终端电阻这些物理层条件过关。3.2 一次读N个寄存器的总耗时计算公式现在把所有时间项汇总给出一个可以直接套用的完整公式。只看一次读操作从主站发请求开始到主站确认响应帧结束为止。T_req 8 × T_byteT_res (5 2N) × T_byte两个3.5字符静默期 2 × 3.5 × T_byte 7 × T_byteT_handle 为从站处理时间T_total T_req T_res 7 × T_byte T_handle整理一下因为T_req是8×T_byteT_res是(52N)×T_byte加上7×T_byte得到T_total (20 2N) × T_byte T_handle这个公式很好记括号里20的组成是8字节请求帧、5字节响应帧固定部分、7字节的帧间隔两个3.5字符都跟N无关。2N就是响应帧里的寄存器数据区。验证一下读10个寄存器、9600、8N1、从站处理时间20毫秒T_total (20 20) × 1.0417 20 ≈ 41.67 20 61.67毫秒跟前面一步步算出来的一致。这里再给一个含处理时间20毫秒的总耗时速查表读10个寄存器的场景波特率总线时间40字节×T_byte从站处理20ms总耗时960041.67ms20ms61.67ms1920020.83ms20ms40.83ms3840010.42ms20ms30.42ms576006.94ms20ms26.94ms1152003.47ms20ms23.47ms注意看最后两行从57600升到115200总耗时只从26.94毫秒降到23.47毫秒省了3.5毫秒。这就是从站处理时间20毫秒占了绝对大头的结果。波特率翻倍总线部分大幅缩水但整个事务时间却只减少了一点点。这是个非常反直觉的结论但你在现场遇到“9600升115200刷新速度没有快多少”的时候往往就是栽在这个上面。3.3 32台从站轮询周期实例差距有多大算单次耗时是基础工程上更关心的是整条总线上轮询一遍所有从站需要多久。这个周期直接决定了数据采集的实时性。假设现场32个从站每站读10个寄存器从站处理时间平均20毫秒主站软件调度等额外开销先忽略。9600波特率单站61.67毫秒32站 ≈ 1973毫秒接近2秒一轮。19200单站40.83毫秒32站 ≈ 1307毫秒约1.3秒。115200单站23.47毫秒32站 ≈ 751毫秒约0.75秒。如果每站读100个寄存器呢重新算一下9600单站249.17毫秒32站 ≈ 7973毫秒接近8秒一轮。19200单站134.58毫秒32站 ≈ 4307毫秒约4.3秒。115200单站39.10毫秒32站 ≈ 1251毫秒约1.25秒。这个对比非常直观同样32个站、数据量都是3200个寄存器9600波特率下接近8秒才能刷完一遍客户那边看到的曲线自然是一格一格跳的完全没法看。拉到115200之后1.25秒一轮体感就完全不一样了。但是还有一个对比更关键如果你用一个“比较懒”的轮询策略每站分10次、每次读10个寄存器而不是一次读100个。再算下9600下的时间单次读10个寄存器需要61.67毫秒每站10次就是616.7毫秒32站就是接近19.7秒。跟一次读100个的8秒相比差了差不多2.5倍。这就是后面要讲的“合并寄存器读取”为什么这么重要。同时也要注意Modbus的125个寄存器上限意味着一次读100个是完全合法且常用的操作很多现场跑得慢不是设备不行而是轮询策略没写好。4. 耗时优化方向与实测心得4.1 为什么只调波特率不一定解决问题上一节的例子已经能说明问题从站处理时间是固定开销它在总耗时里的占比越高调波特率的收益就越小。9600下读10个寄存器从站处理20毫秒占总耗时的约32%115200下同样的从站处理20毫秒占比一下涨到85%。这意味着什么如果你当前是115200但扫描周期还是不够快别再纠结波特率了把注意力放到减少事务次数上。一次事务里即使你把波特率从115200提到230400很多USB转485和高端仪表支持总线部分能省的时间也就1.7毫秒左右但事务次数不减每次省个一两毫秒32个站也就省几十毫秒杯水车薪。另外一个隐蔽的问题是波特率拉高之后总线误码率可能上升尤其在线缆质量一般、没有采用双绞屏蔽线、或者终端电阻没配好的现场。9600都能稳定跑的距离115200可能就开始随机报错了。你要花更多时间处理重试得不偿失。所以在Modbus RTU这类低速现场总线里我一般建议数据量不大、从站数量少优先把波特率拉高数据量大、从站数量多、距离长优先优化读策略别硬上高波特率。4.2 合并寄存器读取是性价比最高的优化手段什么叫合并寄存器读取就是原来每次读1个寄存器、循环10次改成一次读10个连续寄存器。功能码03本来就是支持连续读的这是Modbus协议原生设计不需要从站特殊支持任何标准协议栈都认。收益有多大还是用9600、从站处理20毫秒、每站总共读10个寄存器来算10次单寄存器读取每次读1个寄存器总耗时 10 × [(20 2×1) × 1.0417 20] 10 × [22×1.0417 20] 10 × [22.92 20] 429.2毫秒。1次读10个寄存器 (20 2×10) × 1.0417 20 40×1.0417 20 61.67毫秒。差了快7倍。原因很简单每一次事务都要支付一次请求帧固定开销、两个帧间隔、一次从站处理时间。合并读取相当于把这些固定开销只付了一次。不过合并读取有一个硬约束你读的寄存器必须地址连续。如果你的数据点分散在寄存器映射表的不同区域就只能分段读每段读一个连续区间。此时策略是“尽量用少量事务覆盖所有需要的数据”而不是机械地一个地址一个地址地读。常见的做法是把需要轮询的寄存器做一个地址排序按连续区间分组每组读一次组数越少越好。还要注意一点一次读太多寄存器如果中途某个寄存器地址非法或者超出从站范围从站会返回异常帧整次读取失败。这种情况下反而拆成多个事务更稳。所以合并读取也不是越大越好要考虑从站支持的寄存器映射是否真正连续、有效。4.3 实测校验理论计算和抓包结果差在哪理论算得再漂亮最终要用实测数据说话。我建议每个项目做完通信配置之后不要急着验收先抓一次包把理论计算的每项时间和实测值做个对比偏差大的地方就是要重点排查的地方。实测手段老办法把一条USB转485调试器并联到总线上用串口监视工具抓请求响应帧或者直接用Modbus调试工具里的“报文时间戳”功能。你重点看几个时间点请求帧从第一个字节到最后一个字节的总时间看跟理论传输时间差多少。请求帧结束到响应帧开始之间的间隔这个就是3.5字符静默期从站处理时间。响应帧本身的持续时间。整个事务从开始到结束的总时间。我的实测经验是纯传输部分理论值和实测值基本能对上偏差一般在0.1毫秒以内毕竟就是波特率除以位数的问题。主要偏差集中在“请求结束到响应开始”这一段如果是快设备实测间隔可能就3.5字符1-2毫秒如果是慢设备你就知道这个从站的手册响应时间是不是虚标的或者说这个设备内部是不是有什么周期任务拖慢了通信。还有一个很容易被忽略的开销是主站侧的软件开销。上位机用Modbus库轮询时OS线程调度、API调用、串口缓冲都会产生额外延迟。在Windows上做高频率轮询事务间间隙经常有1到5毫秒的抖动这在计算32站轮询周期时就得算进去。我一般是把主站软件开销按平均2毫秒每次事务估算实测几十轮后取平均如果跟这个估计偏差大就检查是不是驱动、USB转换器或者上位机软件哪里有问题。另外提醒一下用USB转485模块做实验时USB本身有一个帧调度周期通常1毫秒或者125微秒会造成时间戳上肉眼可见的抖动。这不是总线问题是抓包工具所在通道的固有限制别把它当总线故障去查。最后再分享一个我常用的调试习惯遇到通信慢的现场别急着改代码先拿计算器按我这个公式把理论值算一遍然后抓包对照。80%的情况要么是轮询策略不合理事务次数太多要么是从站处理时间超出预期要么是波特率太低导致总线传输占了大头。三者定位清楚再动手改效率极高。这套方法我用了十多年几乎所有Modbus RTU通信性能问题都能在半小时内找到思路。
Modbus RTU读寄存器耗时计算与RS485轮询周期优化实战
干这行时间长了你会养成一个职业病拿到一台设备、一组参数脑子里先估一遍“这一轮采集得多久”而不是等上位机刷新出来了再去拍脑袋。尤其是Modbus RTU挂在RS485总线上做多从站轮询的时候读寄存器到底耗时多少直接决定了你的扫描周期、PLC程序里通信超时设置、上位机刷新率甚至整个系统能不能稳定跑下去。这个话题看着基础但真能算明白、而且知道算完怎么用的人其实不多。我在现场就吃过亏。一套水处理项目上位机要轮询三十几台仪表客户抱怨数据刷新太慢我一查项目配置从站地址1到32每站读10个寄存器波特率9600。当时说不出具体数字只能含糊说“应该还行吧”结果被现场经理盯着改参数。后来我把这套耗时模型完整推了一遍从帧结构到字节时间到从站响应延时全串起来才真正把这个问题吃透。今天就把这套计算方法和工程经验完整写出来帮你在做Modbus RTU RS485方案时不用靠猜直接能算出答案。1. 先拆帧一次读寄存器请求/响应到底多少字节1.1 请求帧固定8字节一个都不能多Modbus RTU读保持寄存器就是功能码030x03这是整个协议族里用得最多的操作。要算耗时第一步就是搞清楚一个请求帧在总线上有多少字节。这个不是背下来的是你得能从帧结构推出来。请求帧构成按发送顺序从站地址1字节范围1到2470是广播248到255是保留。功能码1字节读保持寄存器就是0x03。起始寄存器地址2字节高字节在前16位地址空间对应40001到49999这类映射。寄存器数量2字节表示要连续读多少个寄存器。CRC校验2字节CRC16低字节在前高字节在后。加起来112228字节。这个数字是固定的跟从站地址是多少、读多少个寄存器没有关系只要你用功能码03读寄存器请求帧就是8字节。这里有个细节必须提醒寄存器数量在标准Modbus协议里是有上限的。功能码03一次最多读125个寄存器0x7D原因在协议的数据包大小约束里响应帧携带数据不能超过253字节。很多初学者不知道这个限制配置的时候一次读200个寄存器结果设备直接返回异常码03非法数据值这就是把帧结构搞清楚了就不会犯的错。顺便说一句读保持寄存器是03读输入寄存器是04两者请求帧结构完全一样只是功能码差1。1.2 响应帧随寄存器数量线性增长别把字节计数字段漏了请求帧固定8字节但响应帧不是固定的它跟读取的寄存器数量线性相关。这很好理解从站得把你要的数据塞进帧里返回给你。正常响应帧构成从站地址1字节。功能码0x031字节。字节计数1字节这个字段的值等于“寄存器数量×2”因为每个寄存器占2字节。寄存器数据寄存器数量×2字节按地址顺序排列每个寄存器高字节在前。CRC校验2字节。所以响应帧总长度 1112N2 52N个字节N就是本次读取的寄存器数量。举几个具体数字读取寄存器数量N数据区字节数响应帧总字节数12710202550100105100200205125上限250255注意那个“字节计数”字段这是新手最容易漏算的。有人算响应帧会把寄存器数据直接当2N却忘了还有一个专门报数据长度的字节算出来整帧偏小1字节。1字节在9600波特率下约1.04毫秒单帧看不出来轮询几十台从站累积误差几十毫秒你按错误模型去设置超时就可能在临界状态下触发误判。还有一点读单个寄存器时响应帧只有7字节比请求帧还短这在串口通信里显得有点“不平衡”但协议就是这么设计的。如果你做的是高性能轮询最好心里记住读1个寄存器时总线上跑的数据量是8715字节加上帧间隙实际占线时间并不算短。这也是后面要讲“合并寄存器读取能大幅提升效率”的根源。2. 耗时计算的核心模型位时间、字节时间与帧间隙2.1 8N1还是8E1一个字节的传输时间差多少帧字节数搞清楚之后第二步就是把“字节数”换算成“时间”。串口是逐位传输的一个字节在总线上不是8位而是包含起始位、数据位、校验位、停止位。这个初学者特别容易搞混。标准串口一帧字符的组成起始位1位固定为低电平标志一个字符开始。数据位常为8位Modbus RTU标准要求8位或7位实际几乎都是8位。校验位可无N、奇校验O、偶校验E选一个。停止位1位或2位。所以一个“字符”实际占用的位数是1起始8数据校验位停止位。8N1就是“8数据位、无校验、1停止位”总共10位8E1就是“8数据位、偶校验、1停止位”总共11位。这里插一句很多人会问Modbus RTU到底用8N1还是8E1。标准Modbus RTU推荐的是8E1或者8N1实际工程中两种都在用关键是你主站和从站必须统一否则通信全是乱码。很多国产仪表出厂默认9600 8N1欧美一些设备默认19200 8E1。你接手改造老设备时第一件事就是确认这个参数。位时间 1除以波特率这个不用多说。字节时间 位时间乘以每个字符的总位数。以9600波特率为例8N1字节时间 10/9600 ≈ 1.0417毫秒。8E1字节时间 11/9600 ≈ 1.1458毫秒。两者差了大约0.1毫秒/字节单帧看不出来但一帧读100个寄存器的响应帧205字节8E1就比8N1多花约21毫秒。如果你的系统在波特率较低、数据量大的场景下这个差异已经能影响性能了。我常用的速查表给你列好字节时间单位毫秒波特率8N110位/字节8E1或8O111位/字节96001.04171.1458192000.52080.5729384000.26040.2865576000.17360.19101152000.08680.0955后面所有计算我统一按8N1来如果你现场是8E1把对应数值替换进去就行计算逻辑一模一样。2.2 3.5字符帧间隔Modbus RTU里的“停顿规则”Modbus RTU是帧同步协议没有专用的帧头帧尾怎么区分一帧的起止靠“空闲时间”。协议规定一帧开始前总线上至少要有3.5个字符时间的静默期帧内部两个字节之间的间隔不能超过1.5个字符时间一旦超过接收方就认为帧不完整直接丢弃。这个规则的工程意义很实际它保证了接收方能在字节流里准确切分出每一帧的边界。那3.5个字符时间是多少直接算9600波特率8N13.5×1.0417 ≈ 3.65毫秒。192003.5×0.5208 ≈ 1.82毫秒。1152003.5×0.0868 ≈ 0.30毫秒。这个时间在计算单次读操作耗时的时候必须算进去。一个完整的读操作时间轴大概是这样的主站发送8字节请求帧耗时T_req。请求帧结束从站检测到3.5字符静默期确认一帧完成开始应用层处理。从站处理完成发送响应帧耗时T_res。主站同样需要检测3.5字符静默期确认响应帧结束本轮事务完成。所以在一次事务里至少有两个3.5字符间隔要算进去。我见过很多人算Modbus通信时间只算请求帧和响应帧的字节时间把帧间隔漏了尤其9600波特率下一次事务就少算7.3毫秒左右。乍一看不多但轮询32个从站累积下来就是230多毫秒相当于扫描周期凭空被低估了四分之一秒。还有一个工程细节1.5字符间隔是检测帧内断帧的理论上也要保证但正常通信时帧内字节是连续发送的间隔极小不会触发。只有在主站软件驱动写得比较差、字节间发送间隔超过1.5字符时间的情况下才会导致从站把一帧拆成两帧处理。这个问题不好排查因为不是每次都发生偶尔抽风。后面问题章节我详细讲。2.3 从站处理时间与485半双工切换时间怎么估计理论模型里最容易低估、也是实际偏差最大的就是从站处理时间。所谓处理时间就是从站接收到完整请求帧到开始发送响应帧之间内部的延迟。注意这个时间不是总线上传输的时间而是从站固件“消化”请求、组织数据、发起响应的时间纯开销。这个时间有多少看设备档次快速设备专用通信芯片、实时性好的固件比如一些高端PLC、仪表模块处理时间可以到1到5毫秒。中等设备常规工业仪表、电表、温控器处理时间通常在10到50毫秒之间。有些设备手册会写“响应时间≤50ms”。慢速设备一些老式仪表或者带沉重周期任务的设备处理时间可能到100毫秒以上甚至极端情况存在200到500毫秒的响应延迟。这个参数查设备手册最直接手册里“响应时间”或“通讯响应时间”那一栏写的就是你要的T_handle。查不到你就实测用一个串口监视工具抓请求和响应时间戳两者的间隔就是处理时间帧间隔。这里必须强调从站处理时间是独立于波特率存在的。波特率只影响总线传输部分的时间从站固件处理并不因为波特率从9600升到115200就变快。这就引出一个后面要讲的结论当从站处理时间在总耗时里占比很高时单纯提高波特率的效果是有限的。再加上485是半双工方向切换也需要时间。物理层收发器从接收切换为发送一般几十微秒到几百微秒常规的自动收发电路也就这个量级。但如果你用的是软件控制方向切换比如普通USART芯片靠RTS拉高拉低切方向驱动的切换时间可能到1到2毫秒这个在高速轮询时也是一笔开销。好在多数支持自动收发的485模块已经把这部分时间压得很低了工程计算可以先忽略或用0.5到1毫秒估算但对性能敏感的场合不要完全无视。3. 完整时间测算从单次读操作到整条总线的轮询周期3.1 单帧时间速查表9600到115200全覆盖先把各种波特率下的单帧传输时间给你算好这张表在实际配参、和现场扯皮的时候可以直接拿来用。8N1模式。波特率8字节请求帧耗时7字节响应帧耗时读1个寄存器25字节响应帧耗时读10个寄存器205字节响应帧耗时读100个寄存器96008.33ms7.29ms26.04ms213.54ms192004.17ms3.65ms13.02ms106.77ms384002.08ms1.82ms6.51ms53.39ms576001.39ms1.22ms4.34ms35.59ms1152000.69ms0.61ms2.17ms17.80ms从这张表能读出什么信息第一读1个寄存器时请求帧和响应帧加起来在9600波特率下也只有15.62毫秒单独看很小。但注意这只是“纯传输时间”还没算帧间隔和处理时间。做轮询设计时如果只按这个数算一定会被实测结果打脸。第二读100个寄存器的响应帧在9600下是213.54毫秒这个数已经很大了。对于一个扫描周期要求1秒以内的系统这一个操作就占了约五分之一的总线时间如果从站处理时间再加50毫秒你在9600下根本不可能做到高频刷新。第三波特率提高12倍从9600到115200传输时间大致缩到原来的十二分之一左右。这个收益非常显著前提是总线上所有设备都能稳定运行在115200且线缆质量、终端电阻这些物理层条件过关。3.2 一次读N个寄存器的总耗时计算公式现在把所有时间项汇总给出一个可以直接套用的完整公式。只看一次读操作从主站发请求开始到主站确认响应帧结束为止。T_req 8 × T_byteT_res (5 2N) × T_byte两个3.5字符静默期 2 × 3.5 × T_byte 7 × T_byteT_handle 为从站处理时间T_total T_req T_res 7 × T_byte T_handle整理一下因为T_req是8×T_byteT_res是(52N)×T_byte加上7×T_byte得到T_total (20 2N) × T_byte T_handle这个公式很好记括号里20的组成是8字节请求帧、5字节响应帧固定部分、7字节的帧间隔两个3.5字符都跟N无关。2N就是响应帧里的寄存器数据区。验证一下读10个寄存器、9600、8N1、从站处理时间20毫秒T_total (20 20) × 1.0417 20 ≈ 41.67 20 61.67毫秒跟前面一步步算出来的一致。这里再给一个含处理时间20毫秒的总耗时速查表读10个寄存器的场景波特率总线时间40字节×T_byte从站处理20ms总耗时960041.67ms20ms61.67ms1920020.83ms20ms40.83ms3840010.42ms20ms30.42ms576006.94ms20ms26.94ms1152003.47ms20ms23.47ms注意看最后两行从57600升到115200总耗时只从26.94毫秒降到23.47毫秒省了3.5毫秒。这就是从站处理时间20毫秒占了绝对大头的结果。波特率翻倍总线部分大幅缩水但整个事务时间却只减少了一点点。这是个非常反直觉的结论但你在现场遇到“9600升115200刷新速度没有快多少”的时候往往就是栽在这个上面。3.3 32台从站轮询周期实例差距有多大算单次耗时是基础工程上更关心的是整条总线上轮询一遍所有从站需要多久。这个周期直接决定了数据采集的实时性。假设现场32个从站每站读10个寄存器从站处理时间平均20毫秒主站软件调度等额外开销先忽略。9600波特率单站61.67毫秒32站 ≈ 1973毫秒接近2秒一轮。19200单站40.83毫秒32站 ≈ 1307毫秒约1.3秒。115200单站23.47毫秒32站 ≈ 751毫秒约0.75秒。如果每站读100个寄存器呢重新算一下9600单站249.17毫秒32站 ≈ 7973毫秒接近8秒一轮。19200单站134.58毫秒32站 ≈ 4307毫秒约4.3秒。115200单站39.10毫秒32站 ≈ 1251毫秒约1.25秒。这个对比非常直观同样32个站、数据量都是3200个寄存器9600波特率下接近8秒才能刷完一遍客户那边看到的曲线自然是一格一格跳的完全没法看。拉到115200之后1.25秒一轮体感就完全不一样了。但是还有一个对比更关键如果你用一个“比较懒”的轮询策略每站分10次、每次读10个寄存器而不是一次读100个。再算下9600下的时间单次读10个寄存器需要61.67毫秒每站10次就是616.7毫秒32站就是接近19.7秒。跟一次读100个的8秒相比差了差不多2.5倍。这就是后面要讲的“合并寄存器读取”为什么这么重要。同时也要注意Modbus的125个寄存器上限意味着一次读100个是完全合法且常用的操作很多现场跑得慢不是设备不行而是轮询策略没写好。4. 耗时优化方向与实测心得4.1 为什么只调波特率不一定解决问题上一节的例子已经能说明问题从站处理时间是固定开销它在总耗时里的占比越高调波特率的收益就越小。9600下读10个寄存器从站处理20毫秒占总耗时的约32%115200下同样的从站处理20毫秒占比一下涨到85%。这意味着什么如果你当前是115200但扫描周期还是不够快别再纠结波特率了把注意力放到减少事务次数上。一次事务里即使你把波特率从115200提到230400很多USB转485和高端仪表支持总线部分能省的时间也就1.7毫秒左右但事务次数不减每次省个一两毫秒32个站也就省几十毫秒杯水车薪。另外一个隐蔽的问题是波特率拉高之后总线误码率可能上升尤其在线缆质量一般、没有采用双绞屏蔽线、或者终端电阻没配好的现场。9600都能稳定跑的距离115200可能就开始随机报错了。你要花更多时间处理重试得不偿失。所以在Modbus RTU这类低速现场总线里我一般建议数据量不大、从站数量少优先把波特率拉高数据量大、从站数量多、距离长优先优化读策略别硬上高波特率。4.2 合并寄存器读取是性价比最高的优化手段什么叫合并寄存器读取就是原来每次读1个寄存器、循环10次改成一次读10个连续寄存器。功能码03本来就是支持连续读的这是Modbus协议原生设计不需要从站特殊支持任何标准协议栈都认。收益有多大还是用9600、从站处理20毫秒、每站总共读10个寄存器来算10次单寄存器读取每次读1个寄存器总耗时 10 × [(20 2×1) × 1.0417 20] 10 × [22×1.0417 20] 10 × [22.92 20] 429.2毫秒。1次读10个寄存器 (20 2×10) × 1.0417 20 40×1.0417 20 61.67毫秒。差了快7倍。原因很简单每一次事务都要支付一次请求帧固定开销、两个帧间隔、一次从站处理时间。合并读取相当于把这些固定开销只付了一次。不过合并读取有一个硬约束你读的寄存器必须地址连续。如果你的数据点分散在寄存器映射表的不同区域就只能分段读每段读一个连续区间。此时策略是“尽量用少量事务覆盖所有需要的数据”而不是机械地一个地址一个地址地读。常见的做法是把需要轮询的寄存器做一个地址排序按连续区间分组每组读一次组数越少越好。还要注意一点一次读太多寄存器如果中途某个寄存器地址非法或者超出从站范围从站会返回异常帧整次读取失败。这种情况下反而拆成多个事务更稳。所以合并读取也不是越大越好要考虑从站支持的寄存器映射是否真正连续、有效。4.3 实测校验理论计算和抓包结果差在哪理论算得再漂亮最终要用实测数据说话。我建议每个项目做完通信配置之后不要急着验收先抓一次包把理论计算的每项时间和实测值做个对比偏差大的地方就是要重点排查的地方。实测手段老办法把一条USB转485调试器并联到总线上用串口监视工具抓请求响应帧或者直接用Modbus调试工具里的“报文时间戳”功能。你重点看几个时间点请求帧从第一个字节到最后一个字节的总时间看跟理论传输时间差多少。请求帧结束到响应帧开始之间的间隔这个就是3.5字符静默期从站处理时间。响应帧本身的持续时间。整个事务从开始到结束的总时间。我的实测经验是纯传输部分理论值和实测值基本能对上偏差一般在0.1毫秒以内毕竟就是波特率除以位数的问题。主要偏差集中在“请求结束到响应开始”这一段如果是快设备实测间隔可能就3.5字符1-2毫秒如果是慢设备你就知道这个从站的手册响应时间是不是虚标的或者说这个设备内部是不是有什么周期任务拖慢了通信。还有一个很容易被忽略的开销是主站侧的软件开销。上位机用Modbus库轮询时OS线程调度、API调用、串口缓冲都会产生额外延迟。在Windows上做高频率轮询事务间间隙经常有1到5毫秒的抖动这在计算32站轮询周期时就得算进去。我一般是把主站软件开销按平均2毫秒每次事务估算实测几十轮后取平均如果跟这个估计偏差大就检查是不是驱动、USB转换器或者上位机软件哪里有问题。另外提醒一下用USB转485模块做实验时USB本身有一个帧调度周期通常1毫秒或者125微秒会造成时间戳上肉眼可见的抖动。这不是总线问题是抓包工具所在通道的固有限制别把它当总线故障去查。最后再分享一个我常用的调试习惯遇到通信慢的现场别急着改代码先拿计算器按我这个公式把理论值算一遍然后抓包对照。80%的情况要么是轮询策略不合理事务次数太多要么是从站处理时间超出预期要么是波特率太低导致总线传输占了大头。三者定位清楚再动手改效率极高。这套方法我用了十多年几乎所有Modbus RTU通信性能问题都能在半小时内找到思路。
