精辟,16张图说透Modbus-RTU协议
[导读] 大家好,今天来总结一下Modbus-RTU协议,原本想把实现思路也一起发出来,但是感觉太长了,就拆开了。
前世今生
照例简单说下这个协议的历时,Modicon公司于1979年制定了Modbus协议标准,并用在其PLC产品上。后来Modicon公司被施耐德收购。已成为一种事实标准协议,同时也被IEC-61158工业通信总线规范收录于type 15子集。所谓一流的企业做标准,二流的企业做品牌,三流的企业做产品。这些标准国人都基本是使用者,而非缔造者,所以使用一下,产品上印个标志,做做相关的测试认证都要给老外交钱。这里只是顺带牢骚几句,与本文想说的无关。打住!
Modbus的应用除了常见的过程控制系统,在其他很多领域都有其身影,比如一些楼宇控制,消防控制等等都有大量的产品采用Modbus协议,因为这个协议实现简单,工作可靠,还是标准化的协议!
Modbus分很多实现版本,总的来说是一种应用层协议。从OSI七层模型来看,位于第七层应用层。它定义了在不同类型的总线或网络上连接的设备之间提供 ”客户端/服务器“ 通信。对于使用串口的版本,也定义了layer 1 和 layer 2,实现在主站和一个或多个从站之间交换MODBUS 报文。具体有哪些版本呢?其实主要分两种:
Modbus RTU(Remote Terminal Unit 远程终端单元):这种方式常采用RS-485做为物理层,一般利用芯片的串口实现数据报文的收发,报文数据采用二进制数据进行通信。
Modbus ASCII :报文使用 ASCII 字符。ASCII 格式使用纵向冗余校验和。Modbus ASCII 报文由冒号 (":")开始 和换行符 (CR/LF) 结尾构成。
当然其他还根据所使用的物理层不一样,有这么些做法:
Modbus TCP/IP 或 Modbus TCP :这是一种 Modbus 变体版本,使用 TCP/IP 网络进行通信,通过 502 端口进行连接。报文不需要校验和计算,因为以太网底层已经实现了CRC32 数据完整性校验。
Modbus over TCP/IP 或 Modbus over TCP 或 Modbus RTU/IP :这也是一种 Modbus 变体,与 Modbus TCP 的不同之处在于,与 Modbus RTU 一样,校验和包含在报文中。
Modbus UDP:也有在UDP上传输Modbus报文的,不过需要做错误重传机制,这么干的应该不多。
在具体实现之前,先梳理一下基本概念。
Modbu标准
概况
Modbus-串口版本基本定义了物理层、链路层以及应用层:
物理层可以使用485或232, 这里EIA/TIA都是标准协会的简称,也常写成RS-485/RS-232。
RS-485:半双工收发接口,这是最为常用的modbus物理层,信号采用差分电平编码,用一对双绞线现场布线,抗干扰性能也不错
RS-422:全双工收发接口,这种物理层也有比较多的应用,信号采用差分电平编码,需要两对双绞线现场布线,抗干扰性能也不错。与RS-485相比,其优势在于可以实现全双工,通信的效率高些,所需要的代价就是现场布线需要两对双绞线,增加了一定的成本。
RS-232:全双工收发接口,这个基本用在点对点通信场景下,不适合多点拓扑连接,采用共模电平编码,一般需要Rxd/Txd/Gnd三根线连接。
物理层RS-485,前面总结了,直接看看链路层。
链路层
单播与广播
modbus从链路控制的角度属于主(Master)/从(Slave)方式,比较简单。对介质的访问控制相当于时分复用。通讯总是由主站发起,但可分为单播和广播两种方式,单播就是主站向特定的从站发出通讯请求,广播是向总线所有的设备发起通讯请求。看下面两个图就比较清楚了:
单播(unicast): 报文中的地址字段指定所需要访问的设备,该设备收到请求后作出对应的应答。
广播(Broadcast):主站向总线所有设备发出广播报文,所有从设备都不做应答,报文中地址为0则为广播请求:
讲到了单播以及广播,广播地址为0,自然就需要看看modbus寻址方式了:
寻址
modbus-RTU从设备都具有一个单字节地址,其地址分配定义为:
地址0:广播地址,所有的从设备必须处理广播报文。
1-247:从设备地址,主设备是没有地址的,这一点需要注意。
248-255:保留地址
报文结构
前面说过,通信模式是主/从方式,也即主请求、从应答的方式。无论主请求报文,还是从应答报文其结构都是如下图这样的:
地址:取值范围是0-247,如果是0,就是主站广播报文;如果是1-247,则有可能是主站请求或者从站应答。
功能码:也就是报文命令,代表主站对从站的操作,读或者写
数据:数据字段,主请求报文,从应答报文会有所差异。也就是说假设抓取总线报文,如何区分是主站请求还是从站应答,则需要通过数据字段进行区分了。
CRC校验:采样CRC16,16位循环冗余校验。
主站状态机
链路层一个最最重要的职责就是对通讯介质的管理,如果没有介质的管理,就不能成其为总线。Modbus如何进行介质管理呢?
前面介绍了从链路管理的角度来看,总线介质上发送报文的有两种设备,一种是主设备,另一种是从设备。对于主设备来说,它会有两种报文会向总线介质发送:一种是广播报文,另一种是单播报文。那么究竟是怎么控制介质的呢?其实很简单,看看下面这个状态机就很清楚了:
图中的事件的产生,将会触发主设备链路状态机从一个状态迁移到另一个状态,再事件触发后,还伴随动作需要执行。
空闲:主设备处于空闲态。如果此时应用程序需要发送一个从设备请求,就会切换到等待应答状态;如果此时应用需要发送总线广播,此时,主设备就切换到广播延时。
等待应答:在等待应答状态时,主设备将等待来自从设备的应答报文,如果接收到从站的报文,则进入应答处理。如果等待超时则进入错误处理状态机;在等待过程中,状态机不发生迁移。
广播延时:如果主设备需要发送广播报文,则发送完就进入广播延时状态。这里为什么要延时呢?延时的设计目的就是留给从设备一点时间去处理接收到的广播请求。如果主设备没有这个延时,那么如果应用马上在发一个请求,则从设备有可能来不及处理。但是从设备只做接收处理,任何从设备都不可以对广播报文进行应答。
从站状态机
对于从设备来说,只接收主设备请求或者发送应答,因此从设备的状态机就更简单了。
从设备的状态机很简单,系统一上电就进入空闲状态,空闲态一直监听总线报文,当收到一个完整的报文时,首先校验报文的正确性,再检查报文是否是发给该设备的,如果是请求本设备的,则先完成请求的操作,然后准备好应答报文,如果出错则将出错信息发送给主站。如果收到的是主站广播请求,则仅仅处理相应请求,不做任何应答。
字节编码格式
报文以字节为单位,每个字节再物理层又以什么格式出现再总线呢?
其字节编码格式为:1个起始位,8个数据位,1个校验位,1个停止位。校验位可选择奇校验、偶校验、或无校验,有一个地方标准特别说明了一下,如果选择无校验,会采用2个停止位。
介质管理
对于帧的时间管理,其实就是对介质的冲突管理,modbus-RTU对于介质管理规定了2个重要的时间参数,以实现成帧、冲突管理等。来看看下面这几个图:
这个图可以用于断帧,也就时判断是否接收到一个完整的帧,因此只需要使用一个定时器在每次收到一个字节后,就重启一个3.5字节定时器,如果这个3.5字节定时器中断了,就证明收到了一个Modbus报文,至于这个报文是不是正确的报文,可以在进一步根据帧格式进行校验。
另外还规定了报文需要连续发送,字节间隔不得超过1.5字节时间。
上面对于介质管理所规定得时分复用,可以用一个状态机来描述:
当T3.5定时器超时后,对于modbus-RTU来说,帧校验采用CRC-16。
对于CRC-16得实现,标准给出了查表法得实现栗子:
查表法:
static unsigned char auchCRCHi[] = {
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81,
0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,
0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01,
0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81,
0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0,
0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01,
0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81,
0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,
0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01,
0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81,
0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,
0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01,
0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81,
0x40 } ; static char auchCRCLo[] = {
0x00, 0xC0, 0xC1, 0x01, 0xC3, 0x03, 0x02, 0xC2, 0xC6, 0x06, 0x07, 0xC7, 0x05, 0xC5, 0xC4,
0x04, 0xCC, 0x0C, 0x0D, 0xCD, 0x0F, 0xCF, 0xCE, 0x0E, 0x0A, 0xCA, 0xCB, 0x0B, 0xC9, 0x09,
0x08, 0xC8, 0xD8, 0x18, 0x19, 0xD9, 0x1B, 0xDB, 0xDA, 0x1A, 0x1E, 0xDE, 0xDF, 0x1F, 0xDD,
0x1D, 0x1C, 0xDC, 0x14, 0xD4, 0xD5, 0x15, 0xD7, 0x17, 0x16, 0xD6, 0xD2, 0x12, 0x13, 0xD3,
0x11, 0xD1, 0xD0, 0x10, 0xF0, 0x30, 0x31, 0xF1, 0x33, 0xF3, 0xF2, 0x32, 0x36, 0xF6, 0xF7,
0x37, 0xF5, 0x35, 0x34, 0xF4, 0x3C, 0xFC, 0xFD, 0x3D, 0xFF, 0x3F, 0x3E, 0xFE, 0xFA, 0x3A,
0x3B, 0xFB, 0x39, 0xF9, 0xF8, 0x38, 0x28, 0xE8, 0xE9, 0x29, 0xEB, 0x2B, 0x2A, 0xEA, 0xEE,
0x2E, 0x2F, 0xEF, 0x2D, 0xED, 0xEC, 0x2C, 0xE4, 0x24, 0x25, 0xE5, 0x27, 0xE7, 0xE6, 0x26,
0x22, 0xE2, 0xE3, 0x23, 0xE1, 0x21, 0x20, 0xE0, 0xA0, 0x60, 0x61, 0xA1, 0x63, 0xA3, 0xA2,
0x62, 0x66, 0xA6, 0xA7, 0x67, 0xA5, 0x65, 0x64, 0xA4, 0x6C, 0xAC, 0xAD, 0x6D, 0xAF, 0x6F,
0x6E, 0xAE, 0xAA, 0x6A, 0x6B, 0xAB, 0x69, 0xA9, 0xA8, 0x68, 0x78, 0xB8, 0xB9, 0x79, 0xBB,
0x7B, 0x7A, 0xBA, 0xBE, 0x7E, 0x7F, 0xBF, 0x7D, 0xBD, 0xBC, 0x7C, 0xB4, 0x74, 0x75, 0xB5,
0x77, 0xB7, 0xB6, 0x76, 0x72, 0xB2, 0xB3, 0x73, 0xB1, 0x71, 0x70, 0xB0, 0x50, 0x90, 0x91,
0x51, 0x93, 0x53, 0x52, 0x92, 0x96, 0x56, 0x57, 0x97, 0x55, 0x95, 0x94, 0x54, 0x9C, 0x5C,
0x5D, 0x9D, 0x5F, 0x9F, 0x9E, 0x5E, 0x5A, 0x9A, 0x9B, 0x5B, 0x99, 0x59, 0x58, 0x98, 0x88,
0x48, 0x49, 0x89, 0x4B, 0x8B, 0x8A, 0x4A, 0x4E, 0x8E, 0x8F, 0x4F, 0x8D, 0x4D, 0x4C, 0x8C,
0x44, 0x84, 0x85, 0x45, 0x87, 0x47, 0x46, 0x86, 0x82, 0x42, 0x43, 0x83, 0x41, 0x81, 0x80,
0x40 }; unsigned short CRC16 ( unsigned char *puchMsg, unsigned short usDataLen )
{ unsigned char uchCRCHi = 0xFF ; /* 高字节初始化值 */ unsigned char uchCRCLo = 0xFF ; /* 低字节初始化值 */ unsigned uIndex ; while (usDataLen--) { uIndex = uchCRCLo ^ *puchMsg++ ; uchCRCLo = uchCRCHi ^ auchCRCHi[uIndex] ; uchCRCHi = auchCRCLo[uIndex] ; } return (uchCRCHi << 8 | uchCRCLo) ;
}
应用层
Client/Server模型
前面OSI模型说到了,应用层通信可以看成是client/server方式,或许会与前面说得主从模式搅合在一起,导致理解起来费劲。其实这里client/server是从应用得角度描述得,modbus-RTU中,主设备其应用层就是client侧,而slave设备就是应用的server。modbus标准文档有种把简单问题复杂描述之嫌。其实就是这样一个简单的图:
无错误:Client(主站)向从站发出请求,Server(从站)执行命令请求的操作,然后发送应答给Client(主站),这里的操作,有可能是读取参数,设置参数,或者执行某个动作,具体取决于产品怎么设计。
有错误:Client(主站)向从站发出请求,Server(从站)检测到错误,然后发送异常应答给Client(主站)。这里的错误,有可能是读取失败,寄存器地址非法,写失败,执行动作失败等。
数据模型
Modbus将采用大端字节顺序传输报文,什么意思呢?比如一个16位数据0x55AA,先传输高字节0x55,再传输低字节0xAA。
Modbus将数据抽象成四张表:
看到这个表,可能会让人觉得费解,我的设备里哪来什么线圈?
这大概是modbus协议原本是Modicon公司针对其PLC产品开发的协议,与其特殊的工业PLC控制编程有很大的关系。作为使用modbus协议进行应用开发而言,则不必费力研究为什么叫这些名字。
这四个表本质上就是将应用数据规划为离散位开关量,以及寄存器变量,其中线圈与保持寄存器表为可读可写,其他两个表为只读。这个四个表中将应用数据都利用寄存器地址进行索引。地址范围为0x0000-0xFFFF。需要理解的是,这里的地址与芯片的地址空间完全是两个概念,把它简单理解成modbus可以索引0x0000-0xFFFF这么多个用户应用16位数据即可。其中有的可能是开关量,有的可能利用两个连续寄存器对应用户的浮点数,字符串等等,都有可能。
这些地址是modbus请求命令中的一个字段,比如使用的最最频繁的两条命令,就是0x03,0x10两条命令:
下图来自modbus标准中的0x03号命令的请求以及应答定义:
又比如0x10号命令:
这两条命令中的Starting Address就是上面这4个表中寄存器对应的地址。
Modbus命令
modbus-RTU支持的命令或者叫操作码,就如下面这个表:
其中最为常用的命令是0x03,0x04,0x10号命令,一般的应用而言,单个位开关量通信效率不免低下,现在很多产品开发已很少使用。其实对于这样的离散量也完全可以直接放在输入寄存器表以及保持寄存器表中。modbus对于用户应用并没有严格的规定。用户可以自由进行寄存器地址(或叫索引) 映射。
总结一下
modbus-RTU是一种比较简单、可靠的协议,本文梳理了一下标准中一些比较重要的点。下文将分享一下,如何在单片机中实现几条常用命令。
—— The End ——
推荐好文 点击蓝色字体即可跳转
☞ 非常重要!单片机模块化设计让我事半功倍
☞ 推荐一个直接用于项目开发的PID库!很好用,很稳定
☞ 80家MCU国产和国外厂家汇总!
☞ 推荐一款我私藏已久的串口示波神器
欢迎转发、留言、点赞、分享给你的朋友,感谢您的支持!
点击名片关注我
分享 ???? 点赞 ???? 在看 ❤️
以“三连”行动支持优质内容!
精辟,16张图说透Modbus-RTU协议相关推荐
- 基于Modbus RTU协议的开关量控制采集简介
一.什么是开关量控制采集 所谓的开关量控制采集就是通过458/232接口发送控制命令,实现读取开关量输入或者控制开关量输出的通断. 二.开关量输入采集和开关量输出控制 1. 开关量输入采集就是将一个 ...
- 安卓开发板之串口通信,通过modbus Rtu协议控制下位机
安卓开发板之串口通信,通过modbus Rtu协议控制下位机 1.环境准备 2.编写串口操作核心类 3.编写测试类 前言:因为公司最近有个人脸识别门禁的项目,这个项目主要业务是实现远程人脸注册,管理员 ...
- AIRIOT物联网低代码平台如何配置Modbus RTU协议?
MBRTU即MODBUS RTU的简称,MODBUS是OSI模型第7层上的应用层报文传输协议,它在连接至不同类型总线或网络的设备之间提供客户机/服务器通信.平台的MBRTU协议是建立在TCP协议之上的 ...
- ubuntu16.04下使用Modbus RTU协议控制Robotiq
ubuntu16.04下使用Modbus RTU协议控制Robotiq 一.设备配置 二.创建工作空间 三.安装驱动 四.配置串口 五. ROS节点控制夹爪 六.RVIZ显示模型 一.设备配置 操作系 ...
- 关于modbus rtu协议的CRC(循环冗余校验)在线计算
上位机须按照MODBUS协议的命令格式发送数据(包括计算的CRC值),从机才能正确辨识数据.若无CRC值,从机将返回含有错误号的应答包,不会得到正确结果.标准的做法,发送前计算CRC值并一起发送,接收 ...
- 16进制(CRC16)(MODBUS RTU通讯)校验码在线计算器
最近在项目上遇到,用485协议命令控制灯光继电器的开关需要计算16进制(CRC16)(MODBUS RTU通讯)校验码来写控制命令,这种在网上有现成的计算器,我们直接使用即可,以下为我用的一个计算器的 ...
- modbus RTU协议设备使用无线代替有线注意事项
1.设备有线连接 Modbus是由Modicon(现为施耐德电气公司的一个品牌)在1979年发明的,是全球第一个真正用于工业现场的总线协议.ModBus网络是一个工业通信系统,由带智能终端的可编程序控 ...
- 8数据提供什么掩膜产品_工业轨式1-8路RS485数据(MODBUS RTU协议)厂家产品说明...
产品描述 工业级数点对点光猫提供1-8路RS485(MODBUS RTU协议): 在光纤中传输,该产品突破了传统串行接口通讯距离与通讯速率的矛盾,同时,也解决了电磁干扰.地环干扰和雷电破坏的难题,大大 ...
- FDX-B标签RFID读写器CK-LR12-AB之Modbus Rtu协议运用规则
1.1 Modbus Rtu 协议 1.1.1 寄存器定义表 寄存器地址 定义内容 寄存器地址 定义内容 0 从站地址 1 485速率 2 通信校验 3 读卡模式 4 系统状态 5 RSSI 6 Re ...
最新文章
- 提升Kaggle模型的实用小技巧!
- 【Android笔记】Activity的四种启动模式
- MySQL中修改密码及访问限制设置详解
- 量化派基于Hadoop、Spark、Storm的大数据风控架构--转
- Java之File类
- mess组网 中继_取代中继/子母路由 堪称最上乘的Mesh组网方式了解下
- TKinter的常用组件
- 邹伟博士出书啦!——《强化学习》从基础概念、核心原理到应用案例(文末赠书)...
- 内网集群 无法通信_记一次集群内无可用http服务问题排查
- PHP 全局变量global详解
- 《假如编程是魔法之零基础看得懂的Python入门教程 》——(七)我把魔法变成了积木
- windows下揪出java程序占用cpu很高的线程
- linux 配置 mysql_linux下mysql配置文件my.cnf最详细解释
- 双机流水作业调度问题——Johnson算法
- 【STM32+cubemx】0013 HAL库开发:SPI总线访问气压计BMP280/BME280
- 世界四大名柚有哪些?
- 2022年全球光纤机械接头市场前景分析及研究报告
- 设计模式六大原则详解
- stm32f105vct6例程_STM32F105VCT6
- Dell intel i5 1135笔记本 ubuntu18.04无法调节屏幕亮度