-
背景
串行总线(RS485)由于其非平衡传输特性的限制,广泛应用主从MODBUS RTU(ASCII)协议。主从协议严格遵循请求应答机制,尤其在主机向总线中各从机查询数据时,需要逐个设备节点、逐片寄存器发起请求。实际应用中称之为MODBUS总线数据轮询,在多设备多数据场景下,无法保证数据实时性。
-
问题分析
产生的数据更新延时主要源于两方面原因:交互次数多和冗余的上报数据。
交互次数与从机个数、MODBUS数据定义个数正相关,同时存在由于MODBUS数据地址不连续,需要增加交互次数的情形。
遍历轮询方式触发从机上报所有请求中包含的数据,必然导致从机响应报文中携带长期未变化的数据,这类数据即为冗余上报数据。
-
前置需求
问题要解决,但解决方案也要有边界。
- 支持半双工(RS485)通信方式;
- 不脱离MODBUS协议规范,包括报文格式、主从应答流程、设备地址、CRC、最大帧长限制等;
- 不改变且复用已有协议数据(寄存器)定义方式;
-
设计方案
总体流程
-
报文格式
相关流程统一采用自定义报文格式(请求、应答),遵循如下定义:
字段 |
长度 |
备注 |
|
设备地址 |
1 Byte |
|
|
功能码 |
1 Byte |
0X65 (自定义区间) |
|
PDU |
子功能码 |
1 Byte |
|
数据长度 |
2 Bytes |
N |
|
数据域 |
N Bytes |
|
|
CRC |
2 Bytes |
|
MODBUS-RTU模式下,单帧最大长度256Bytes。
MODBUS-TCP模式下,单帧最大长度根据MTU规格制定,建议1300Bytes。
PDU中各字段采用大端字节序传输。
异常响应报文与MODBUS协议定义一致:
字段 |
长度 |
备注 |
设备地址 |
1 Byte |
|
功能码 |
1 Byte |
0XE5 |
预留 |
2 Byte |
0 |
CRC |
2 Bytes |
|
-
订阅
从机提供一套默认增量上传的寄存器列表,如果未收到注册请求,在默认寄存器列表范围内进行上报。从机收到注册请求后,本地持久化存储订阅的寄存器信息;主机识别设备通讯重新建链、主机启动后,重新发送订阅信息;订阅流程作为版本兼容性要求的预设流程,主机可暂不支持;寄存器单元的划分:订阅目标数据的地址连续优先放在同一个单元,地址前后独立的数据单独一个单元。订阅请求支持广播方式。
-
请求PDU:
字段 |
长度 |
备注 |
|
子功能码 |
1 Byte |
0X01 |
|
数据长度 |
2 Bytes |
N |
|
上报周期 |
2 Bytes |
单位秒; 0:单播请求,主机请求触发增量上传; > 0:从机主动按周期增量上传,适用于MODBUS-TCP场景; |
|
订阅类型 |
2 Bytes |
0:全量订阅,从机将订阅信息替换已有的寄存器列表; 1:增量订阅1,基于订阅列表增量; 2:增量订阅2,基于默认寄存器列表增量; |
|
预留 |
2 Bytes |
|
|
寄存器单元个数 |
2 Bytes |
≤ 80 0:注销所有订阅信息; |
|
单元1 |
寄存器地址 |
2 Bytes |
|
寄存器个数 |
1 Byte |
|
|
单元… |
寄存器地址 |
2 Bytes |
|
寄存器个数 |
1 Byte |
|
响应PDU:
字段 |
长度 |
备注 |
子功能码 |
1 Byte |
0X01 |
数据长度 |
2 Bytes |
2 |
订阅注册结果 |
2 Bytes |
0:成功; 1:失败; |
-
总召
从机收到总召请求后,被订阅数据要求全部置为变化态,总召响应立即给出数据回复,所以总召响应PDU与增量上传的响应PDU一致;从机接收总召后,帧序号检测重置,以总召中设定的序号开始检测跳包、重发问题。
主机发起总召的场景:
-
主机系统初始化;
-
设备断链过程中;
-
增量请求返回异常;
-
设备升级结束;
-
周期60分钟;
请求PDU:
字段 |
长度 |
备注 |
子功能码 |
1 Byte |
0X02 |
数据长度 |
2 Bytes |
4 |
帧序号 |
2 Bytes |
0 |
总召类型 |
2 Bytes |
0:全部总召 1:(预留) 2:(预留) |
-
增量上传
从机本地识别前后两次增量上传请求之间数据的是否发生变化,就近一次增量上传所填充的内容仅为变化寄存器。从机识别请求帧序号是否出现跳变、重发;跳变后回复异常(0XE5),重发则回复上一帧数据;帧序号由0XFFFF翻转为0时,视为正常递增;从机保证关键数据、逻辑相关联数据优先上报,放在第一帧内回复;寄存器单元拼接时,间隔寄存器个数为1,作为同一个单元上报,间隔寄存器上报当前值或无效值。间隔寄存器个数超过1,则另起新的寄存器单元。从机重启后,可能直接收到增量上传请求,此时根据本地存储的订阅信息,全量上报一次。主机运行过程中,总线上通过单播方式,连续向各从机发起增量上传请求,单个从机回复有其它变化数据时,主机连续向该从机发起请求,直至变化数据请求完毕,连续请求最大次数10。主机对每个从机单独维护帧序号,确保帧序号逐1递增。从机连续3次超时后,主机以总召请求维持链接请求。
请求PDU:
字段 |
长度 |
备注 |
子功能码 |
1 Byte |
0X03 |
数据长度 |
2 Bytes |
2 |
请求帧序号 |
2 Bytes |
延续总召序号,逐1递增; |
响应PDU:
字段 |
长度 |
备注 |
|
子功能码 |
1 Byte |
0X03 |
|
数据长度 |
2 Bytes |
N |
|
回复帧序号 |
2 Bytes |
回填请求帧序号 |
|
预留 |
2 Bytes |
|
|
寄存器单元个数 |
2 Bytes |
最高位置1代表,还有其它变化数据。 无变化数据时,单元个数为0,无其它字节数据。 |
|
单元1 |
寄存器地址 |
2 Bytes |
|
寄存器个数 |
1 Byte |
|
|
数据 |
N Bytes |
|
|
单元… |
寄存器地址 |
2 Bytes |
|
寄存器个数 |
1 Byte |
|
|
数据 |
N Bytes |
|
-
幅值控制
幅值控制策略仅面向采样测点数据,状态量、参数、特征信息不做控制,有变化即上报。幅值控制主要是解决由于采样误差导致的无用数值波动。如下情况不受幅值控制影响:
-
数据归0
-
数据从0跳变为非0
-
正负翻转
-
效果确认
经过实际测试,采用这种增量数据上报方式实现的MODBUS总线轮询方案,数据更新延时明显降低:
-
方案 总线规格 延时 传统轮询方案 30台从机
100个输入寄存器
总线波特率9600bps
> 9秒 增量上报轮询方案 < 3秒