一文搞懂 Modbus RTU 协议

发布人：xiaomaidashu 时间：2024-05-15 来源：工程师

加入技术交流群
- 扫码加入
  和技术大咖面对面交流
  海量资料库查询

发布文章

大家好，我是麦鸽，以前写过一篇文章是关于modbus协议的，只是简单地做了一下介绍，这次对于modbus RTU协议进行了深入的学习。

背景

介绍modbus rtu之前，我们可以了解到，Modbus是施耐德电气公司，于1979年发明的，是全球第一个真正用于工业现场的总线协议。四十多年过去了，现在仍然被广泛使用在各个工业控制领域。除了这个协议很稳定的原因之外：

免费；
方便部署和维护；
对供应商来说，修改移动本地的比特或字节没有很多限制；

modbus 是OSI模型第七层上的应用层报文传输协议，OSI定义了开放系统的层次结构、层次之间的相互关系以及各层所包括的可能的任务，作为一个框架来协调和组织各层所提供的服务。

OSI参考模型并没有提供一个可以实现的方法，而是描述了一些概念，用来协调进程间通信标准的制定。即OSI参考模型并不是一个标准，而是一个在制定标准时所使用的概念性框架。

modbus在OSI模型中，可以描述为下图；

modbus osi模型中的位置

EIA485/TIA485就是RS485，随着技术不断发展，485标准目前是电信行业协会（TIA）维护，所以名称为TIA-485，当然工程师及应用指南仍继续用RS-485来称呼也是没问题的；

下面我们来介绍一些串行链路协议。

Modbus 串行链路协议

Modbus串行链路协议是一个主从模式（主机和从机），半双工的数据传输协议，485标准通常需要两条线，在某一个确定时刻，有一个主机和从机进行通讯。

主从模式：通常总线上有一个主机和多个从机，每个从机有唯一的ID，主机通过ID进行寻址从机，然后进行数据传输；
半双工传输：相对应半双工的是全双工，全双工运行发送数据和接收数据同时发生，所以半双工就不难理解了，同一时刻只能进行发送数据，或者只能接收数据；

整体的结构图如下所示；

一个485总线的主从模式

这里我们还要明确几点：

从机无法主动向从机发送数据，只有在主机发送数据给从机（发送请求），然后从机接收到主机发送的数据之后，再回传数据给主机；具体如下所示；

主从模式

正如前面所提到的，modbus是半双工传输的，即主机发送数据的时候，是不能接收数据的，所以这里总共分为两步来进行。

主机发送数据的方式有两种，一个是 1对1，一个是1对多，也就是我们常说的广播形式，所有从机都可以收到主机发送的数据；
1对1 只需要发送数据给特定地址的从机即可，广播只需要把发送地址设置为0即可，所以广播地址为0；

这里我们已经大致了解了主机和从机之间的数据传输的情况，下面我们就再来介绍一下数据传输的具体格式；

传输模式

先来说说Modbus有两种传输模式，RTU传输模式和ASCII传输模式；

RTU传输：Remote Terminal Unit模式在Modbus中消息由十六进制组成，数据密度高，吞吐率高；
ASCII传输：消息由ASCII 字符发送效率不及RTU模式，无法使用RTU模式的定时管理时，使用ASCII模式；
比如：0x12会被整合成两个字符发送：0x31和0x32发送，
因为 0x31等于字符1；0x32等于字符2

下面我们会主要介绍modbus RTU。

帧格式

在讲帧格式之前，首先我们想象一下，人与人之间的对话，最基本单元是汉字，然后相互交流就用汉字组成的句子，比如下面的对话；

老板问：中午吃什么？
小樟说：吃饭吧！

所以机器之间的通信也是类似的，我们可以把字节当作最基本的数据单元，然后由字节组成句子，也就是通信帧；

但是现在情况出现了变化，对话的人里，除了小樟，还有一个小红，这时候，为了明确和谁说话，就需要在对话前面加上名字：

老板：小樟，中午吃面吗？
小樟：老板，吃饭去吧。
小红，没有叫他，语言柚子；

所以我们继续回到modbus的数据帧格式，这里的协议定义了一个基础通信层的简单协议数据单元（PDU），具体如下图所示；

所以这里基本分为四个部分，地址域，功能码，数据，差错校验（CRC/LRC），统称为ADU (Application Data Unit)，基本上进行传输的数据都要满足这个格式，作为一个完整的帧，对照前面老板的对话内容，我们这里可以简单的理解一下：

地址域：可以理解成 具体和谁说话；
功能码：可以理解成 具体动作，比如去做，来拿，去吃等等；
数据：可以理解成 具体内容，比如面，饭等等，也可以是其他，这里配合上下文，所以是吃的东西；
差错校验：可以理解成，说出来的话必须可以让人理解，不然别人听不懂啊；实际上在协议中通常使用CRC或LRC保证传输的数据没有错误；

下面我们再深入分析一下；

PDU

Modbus PDU(protocol data unit)格式被定义为一个功能代码，后面跟着一组关联的数据。

该数据的大小和内容由功能代码定义，整个PDU（功能代码和数据）的大小不能超过253个字节。

每个功能代码都有一个特定的行为，从设备可以根据所需的应用程序行为灵活地实现这些行为。

PDU规范定义了数据访问和操作的核心概念；但是，从设备可能会以规范中未明确定义的方式处理数据。

地址域

地址域占用一个字节，所以一般来说寻址范围是0~255，一般在系统中用1~147，其他地址暂时保留，另外，同一个总线上的从机，每个地址必须唯一。

其中0是广播地址；

下面是Freemodbus的一个从机初始化代码，0x02就是这个从机的地址，

eMBInit(MB_RTU, 0x02, 3, 115200, MB_PAR_NONE);

功能码

功能码占一个字节，所以范围是 0~255，协议中规定了功能码分为三类：公共功能码，用户自定义功能码，保留功能码。整体如下所示；

image-20211224223246059

公共功能码必须保证它的唯一性，这是由Modbus组织已经规定好，并且具有一致性测试的功能码，所以在一定程度上，它保证了协议的可复用性。

由上表可知，公共功能码分为四种，分别是：

离散量输入：只读类型，单位：bit；
线圈：读写类型，单位：bit；
输入寄存器：只读类型，单位：字节；
保持寄存器：读写类型，单位：字节；

下面是移植Freemodbus协议，从机上需要对这四个公共功能码处理的回调函数：

//输入寄存器量
eMBErrorCode eMBRegInputCB( UCHAR * pucRegBuffer, USHORT usAddress, USHORT usNRegs )
{
  eMBErrorCode    eStatus = MB_ENOERR;
  return eStatus;
}
//保持寄存器量
eMBErrorCode
eMBRegHoldingCB( UCHAR * pucRegBuffer, USHORT usAddress, USHORT usNRegs,
                 eMBRegisterMode eMode )
{
    eMBErrorCode    eStatus = MB_ENOERR;
    return eStatus;
}

//线圈数量 
eMBErrorCode
eMBRegCoilsCB( UCHAR * pucRegBuffer, USHORT usAddress, USHORT usNCoils,
               eMBRegisterMode eMode )
{
    eMBErrorCode    eStatus = MB_ENOERR;
    return eStatus;
}

//离散输入数量 
eMBErrorCode
eMBRegDiscreteCB( UCHAR * pucRegBuffer, USHORT usAddress, USHORT usNDiscrete )
{
    eMBErrorCode    eStatus = MB_ENOERR;
    return eStatus;
}