前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >modbus rtu协议_modbus协议和电总协议的初步认知

modbus rtu协议_modbus协议和电总协议的初步认知

作者头像
Java架构师必看
发布2021-08-23 10:45:35
1.3K0
发布2021-08-23 10:45:35
举报
文章被收录于专栏:Java架构师必看Java架构师必看
a59377ca1ed1069b49bc11b1014c3c54.png
a59377ca1ed1069b49bc11b1014c3c54.png

modbus协议和电总协议的初步认知

在如今计算机网络高速发展,通讯、控制技术逐步成熟的大背景下,如何高效实现智能设备从现场到控制、管理各个阶层是具有重大意义的,为了更加便捷和统一的对基于现场总线的智能设备进行控制(如基于RS232总线和RS485总线),工业领域制订了通用协议。

在本文中,主要讲述一下个人关于在工业控制领域中的部分电子控制器的通用语言(即协议)的理解。目前我们经常使用到的两类通用协议是modbus协议和电总协议,下面分别就两种协议各自的特点进行相关研究,包括各种校验以及数据包格式等,在此并未讲述关于数据格式,如字节等知识,只是单纯的协议描述;

无论是电总协议还是modbus协议,都必须基于智能设备和上位机之间通信建立的条件下才能够进行数据流的传送。通信连接采用的方式有多种,比如zigbee,串行通信(RS232和RS485),TCP,UDP,RTU等;

RS232和RS485

RS232通信接口能实现全双工通信,所谓全双工通信就是在同一时间既能进行数据的发送也能进行数据的接收;RS232接线原理如下图所示

6fc2b6111db68a4c88ccc9b0fae49b70.png
6fc2b6111db68a4c88ccc9b0fae49b70.png
024b0cfa72b70972239341bb301f4b40.png
024b0cfa72b70972239341bb301f4b40.png

RS232串口接线图

如图所示:9针串口中,2为接收数据线;3为发送数据线;5为接地线;

在连接的时候智能设备端的接收数据线连接PC上位机端的发送数据线;智能设备端的发送数据线连接PC上位机端的接收数据线;智能设备端的接地线连接PC上位机端的接地线;接地线两端不变,收发数据线交换。

RS485为半双工通信方式;顾名思义半双工通信就是在同一时刻智能设备端发送数据,那么PC端就只能接收数据,而不能发送数据;只有一次收发结束之后,才能够再次进行收发数据;

接线方式为:现场设备的TXD接上位机的TXD,现场设备的RXD接上位机的RXD。

  1. modbus协议

Modbus 协议是应用于电子控制器上的一种通用语言。通过此协议,控制器相互之间、控制器经由网络(例如以太网)和其它设备之间可以通信。它已经成为一通用工业标准。有了它,不同厂商生产的控制设备可以连成工业网络,进行集中监控。

标准的MOSBUS协议是采用RS-232C兼容串行接口,定义传输的波特率,奇偶校验位等。控制器通信采用主从技术,即由一主机初始化查询,其他从机根据主机的发送做出相应的反应。比较常见的主设备有主机和可编程仪表。常见的从设备有可编程控制器。主设备和从设备之间既可以进行单播通讯,也可进行广播通讯。当进行单播通讯的时候,针对主设备的消息,从设备回返回一消息进行应答,如果是广播,则从设备不返回信息。控制器能设置的传输模式主要分为两种:ASCII模式和RTU模式;

MODBUS消息帧

c077a8eadeceba54c5ec998b49b4150c.png
c077a8eadeceba54c5ec998b49b4150c.png

MODBUS 消息帧

上图中展示的是主机和从机之间根据从机设备地址一一对应进行消息的查询模式。具体实现这一过程主要分为五部分:

对应主机来说

①:从机地址;②:功能码;③:起始地址;④:读取个数;⑤:(CRC/LRC)校验码;

对应从机来说

①:从机地址;②:功能码;③:数据个数;④:数据段;⑤:(CRC/LRC)校验;

下图展示的是从机回应模式:

ASCII模式

a315393966f6cbd565d6e20f5569be5b.png
a315393966f6cbd565d6e20f5569be5b.png

使用 ASCII 模式,消息以冒号(:)字符(ASCII 码 3AH)开始,以回车换行符结束(ASCII 码 0DH,0AH)。

其它域可以使用的传输字符是十六进制的 0...9,A...F。网络上的设备不断侦测“:”字符,当有一个冒号接收到时,每个设备都解码下个域(地址域)来判断是否发给自己的

消息中字符间发送的时间间隔最长不能超过 1 秒,否则接收的设备将认为传输错误,消息帧如下图所示:

e95c77602aa32b1b595982ffaca9aa6a.png
e95c77602aa32b1b595982ffaca9aa6a.png

ASCII消息帧

RTU模式:

9dd215905030e405fd75afb0472ae1cd.png
9dd215905030e405fd75afb0472ae1cd.png

使用 RTU 模式,消息发送至少要以 3.5 个字符时间的停顿间隔开始。在网络波特率下多样的字符时间,这是最容易实现的(如下图的 T1-T2-T3-T4 所示)。传输的第一个域是设备地址。可以使用的传输字符是十六进制的 0...9,A...F。网络设备不断侦测网络总线,包括停顿间隔时间内。当第一个域(地址域)接收到,每个设备都进行解码以判断是否发往自己的。在最后一个传输字符之后,一个至少 3.5 个字符时间的停顿标定了消息的结束。一个新的消息可在此停顿后开始。

整个消息帧必须作为一连续的流转输。如果在帧完成之前有超过 1.5 个字符时间的停顿时间,接收设备将刷新不完整的消息并假定下一字节是一个新消息的地址域。同样地,如果一个新消息在小于 3.5 个字符时间内接着前个消息开始,接收的设备将认为它是前一消息的延续。这将导致一个错误,因为在最后的CRC 域的值不可能是正确的。典型的消息帧如下所示:

a64dff6154490c385faff1c50f2470af.png
a64dff6154490c385faff1c50f2470af.png

RTU消息帧

地址域

消息帧的地址域包含两个字符(ASCII)或 8Bit(RTU)。可能的从设备地址是 0...247 (十进制)。单个设备的地址范围是 1...247。主设备通过将要联络的从设备的地址放入消息中的地址域来选通从设备。当从设备发送回应消息时,它把自己的地址放入回应的地址域中,以便主设备知道是哪一个设备作出回应。地址 0 是用作广播地址,以使所有的从设备都能认识。

错误检测域

标准的 Modbus 网络有两种错误检测方法。错误检测域的内容视所选的检测方法而定。

ASCII模式检验方式

当选用 ASCII 模式作字符帧,错误检测域包含两个 ASCII 字符。这是使用 LRC(纵向冗长检测)方法对消息内容计算得出的,不包括开始的冒号符及回车换行符。LRC 字符附加在回车换行符前面。

RTU模式检验方式

当选用 RTU 模式作字符帧,错误检测域包含一 16Bits 值(用两个 8 位的字符来实现)。错误检测域的内容是通过对消息内容进行循环冗长检测方法得出的。CRC 域附加在消息的最后,添加时先是低字节然后是高字节。故 CRC 的高位字节是发送消息的最后一个字节。

字符的连续传输

当消息在标准的Modbus系列网络传输时,每个字符或字节按照以下方式传送,从左到右依次为最低有效位…最高有效位

2f2f4653f47008e413396784554170d5.png
2f2f4653f47008e413396784554170d5.png

使用ASCII字符帧时,位的序列

ba7407e7a1352ff17900bf6896d61407.png
ba7407e7a1352ff17900bf6896d61407.png

使用RTU字符帧时,位的序列

  1. 、奇偶校验

用户可以配置控制器是奇或偶校验,或无校验。这将决定了每个字符中的奇偶校验位是如何设置的。如果指定了奇或偶校验,“1”的位数将算到每个字符的位数中(ASCII 模式 7 个数据位,RTU 中 8 个数据位)。例如 RTU 字符帧中包含以下 8 个数据位:

11000101

整个“1”的数目是 4 个。如果便用了偶校验,帧的奇偶校验位将是 0,便得整个“1”的个数仍是 4个。如果便用了奇校验,帧的奇偶校验位将是 1,便得整个“1”的个数是 5 个。

如果没有指定奇偶校验位,传输时就没有校验位,也不进行校验检测。代替一附加的停止位填充至要传输的字符帧中。

  1. 、LRC检测

使用 ASCII 模式,消息包括了一基于 LRC 方法的错误检测域。LRC 域检测了消息域中除开始的冒号及结束的回车换行号外的内容。

LRC 域是一个包含一个 8 位二进制值的字节。LRC 值由传输设备来计算并放到消息帧中,接收设备在接收消息的过程中计算 LRC,并将它和接收到消息中 LRC 域中的值比较,如果两值不等,说明有错误。

LRC 方法是将消息中的 8Bit 的字节连续累加,丢弃了进位;

LRC的C语言实现方式如下:

代码语言:javascript
复制
static 
  1. 、CRC检测

使用 RTU 模式,消息包括了一基于 CRC 方法的错误检测域。CRC 域检测了整个消息的内容。CRC 域是两个字节,包含一 16 位的二进制值。它由传输设备计算后加入到消息中。接收设备重新计算收到消息的 CRC,并与接收到的 CRC 域中的值比较,如果两值不同,则有误。

CRC 是先调入一值是全“1”的 16 位寄存器,然后调用一过程将消息中连续的 8 位字节各当前寄存器中的值进行处理。仅每个字符中的 8Bit 数据对 CRC 有效,起始位和停止位以及奇偶校验位均无效。

CRC 产生过程中,每个 8 位字符都单独和寄存器内容相或(OR),结果向最低有效位方向移动,最高有效位以 0 填充。LSB 被提取出来检测,如果 LSB 为 1,寄存器单独和预置的值或一下,如果 LSB 为 0,则不进行。整个过程要重复 8 次。在最后一位(第 8 位)完成后,下一个 8 位字节又单独和寄存器的当前值相或。最终寄存器中的值,是消息中所有的字节都执行之后的 CRC 值。CRC 添加到消息中时,低字节先加入,然后高字节。

CRC校验C语言实现简单方式如下:

代码语言:javascript
复制
static unsigned int CRC16(unsigned char *puchMsg, unsigned int usDataLen)
{
  unsigned char uchCRCHi = 0xFF ; /* 高CRC字节初始化 */
  unsigned char uchCRCLo = 0xFF ; /* 低CRC 字节初始化 */
  unsigned long uIndex ; /* CRC循环中的索引 */
  while (usDataLen--) /* 传输消息缓冲区 */
  {
    uIndex = uchCRCHi ^ *puchMsg++ ; /* 计算CRC */
    uchCRCHi = uchCRCLo ^ auchCRCHi_METER[uIndex] ;
    uchCRCLo = auchCRCLo_METER[uIndex] ;
  }
  return (uchCRCHi << 8 | uchCRCLo) ;
}

/* CRC 高位字节值表 */
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
} ;
/* CRC 低位字节值表*/
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
};

MODBUS功能码:

b9924f05801955f0e25c001954992e8a.png
b9924f05801955f0e25c001954992e8a.png
f9e2402940820c8b9a3e722f842c9285.png
f9e2402940820c8b9a3e722f842c9285.png

Modbus功能码和数据类型之间的对应关系如下:

670f61a4ec533acc9da20cb991e8babc.png
670f61a4ec533acc9da20cb991e8babc.png

最后,以目前接入设备常用的模式RTU来举一个读取整数数据的例子:

1fdb020a323d1ec40b7bfde98636dcc3.png
1fdb020a323d1ec40b7bfde98636dcc3.png
  1. 电总协议

电总协议的监控系统为分布式结构,监控单元(SU)与监控模块(SM)的通信方式为主从方式,监控单元为上位机,监控模块为下位机。

通信过程为:SU呼叫SM并下发命令,SM收到命令后返回响应信息。在超时时间500ms内SU接收不到SM的响应信息或响应信息错误的时候,则本次通信失败;

  1. 信息类型和信息结构

信息类型:

——由SU发出到SM的信息为命令信息;

——由SM返回到SU的信息为响应信息;

信息结构如下图所示:

c22a01a81dc51de973652d3df4ac84ea.png
c22a01a81dc51de973652d3df4ac84ea.png
06408eafc69c2da45f6a6520c702842f.png
06408eafc69c2da45f6a6520c702842f.png

信息结构

信息结构格式详解

其中在返回的数据中,可根据RTN的值来判断返回数据是否正确,同样也可通过RTN来判断错误类型:

30736dc12bb84ed2009ced9b1bff0f1c.png
30736dc12bb84ed2009ced9b1bff0f1c.png

示例:

SU -> SM:7E 32 31 30 31 36 30 34 32 30 30 30 30 46 44 42 30 0D

在这条命令中:

  • 7E为起始位,
  • (32 31)为协议版本2.1;
  • (30 31)为设备地址01;
  • (36 30)为CID1为60,代表设备类型分散空调;
  • (34 32)为CID2控制码为42,获取模拟量量化数据-定点数
  • (30 30 30 30 )为LENGTH的长度,因为INFO为空,经过LENGTH的计算方法,得到值为0000;
  • (46 44 42 30)为校验和码CHKSUM;
  • (0D)为结束码

LENGTH 数据的格式及计算方式:

0690ae90de678a3f7cebe8224a83b581.png
0690ae90de678a3f7cebe8224a83b581.png

LENGTH工2个字节,由LENID和LCHKSUM组成,LENID表示INFO的ASCII码字节数,当LENID=0时,INFO为空,即无该项。LENGTH拆分4个ASCII码传送,先传高字节,后传低字节。校验码的计算:D11D10D9D8+D7D6D5D4+D3D2D1D0,求和后模16余数取反加1;

示例如下:

INFO的ASCII字节数为18,即LENID=0000 0001 0010B

D11D10D9D8+D7D6D5D4+D3D2D1D0=0011B,模16余数为0011B,0011B取反加1为1101B,即 LENCHKSUM为1101B 所以 LENGTH为1101 0000 0001 0010B,即 D012H。

LENGTH的C语言实现方式如下:

代码语言:javascript
复制
 static unsigned short EnCheckSum(unsigned char *check_buf,unsigned char len)//校验和计算
  {
   unsigned char i;
   unsigned short sum=0;
   for(i=0;i<len;i++)
   {
    sum +=*(check_buf+i);
   }
   sum=~sum%0x10000+1;
   *(check_buf+len)=(sum&0xf000)>>12;
   *(check_buf+len+1)=(sum&0x0f00)>>8;
   *(check_buf+len+2)=(sum&0x00f0)>>4;
   *(check_buf+len+3)=sum&0x000f;
   HexToAsc(check_buf+len,4);
   return len+4;
  }

CHKSUM校验和计算

CHKSUM的计算是除SOI,EOI,CHKSUM外,其他字符按照ASCII码值累加求和,所得结果模65536余数取反加1.CHKSUM 拆分4个ASCII码传送,先高字节,后低字节。

示例如下:

其中的一条收发数据为~20014043E00200FD3BCR(~为SOI-7E,CR为EOI-0D),即FD3B的计算方式为:

‘2’+‘0’+‘0’+……+‘E’+‘0’+‘0’+‘2’+‘0’+‘0’=32H+30H+30H+……+45H+30H+30H+32H+30H+30H= 02C5H

02C5H取反加1为FD3BH

CHKSUM的C语言实现方式如下所示:

代码语言:javascript
复制
 //计算校验和
 static unsigned char CheckSum(unsigned char *check_buf,int len)
 {
  int i;
  unsigned short sum=0;
  unsigned char check_hex[4];
  unsigned char check_result=1;
  for(i=0;i<len-4;i++)
  {
   sum +=*(check_buf+i);
  }
  sum=~sum%0x10000+1;//从buf[0]+……+buf[len-4],模65536取反加1,求得校验和
  check_hex[0]=(sum&0xf000)>>12;//分别将得到的校验和分为两个字节,分别有高位和低位---高位
  check_hex[1]=(sum&0x0f00)>>8;//低位
  check_hex[2]=(sum&0x00f0)>>4;//第二个字节---高位
  check_hex[3]=sum&0x000f;//低位
  HexToAsc(check_hex,4);//将十六进制数转化为ASCII码
  if((check_hex[0]==*(check_buf+len-4))&&(check_hex[1]==*(check_buf+len-3))&&(check_hex[2]==*(check_buf+len-2))&&(check_hex[3]==*(check_buf+len-1)))
    check_result=0;
  else
  {
    for(i=0;i<4;i++)
    {
     if(check_hex[i]>0x39)
     check_hex[i] += 0x20;
    }
    if((check_hex[0]==*(check_buf+len-4))&&(check_hex[1]==*(check_buf+len-3))&&(check_hex[2]==*(check_buf+len-2))&&(check_hex[3]==*(check_buf+len-1)))
      check_result=0;
  }

  return check_result;
 }

以下所列的是设备类型的编码表即命令中的CID1的取值依据:

dc2caea72804aa1ef076887c8b46a7ca.png
dc2caea72804aa1ef076887c8b46a7ca.png
2f017a12f49b959da4bb2831770dc022.png
2f017a12f49b959da4bb2831770dc022.png

命令控制信息编码CID2如下图所示:

4cd4b622fd5782a3645b7eaa82a4f70e.png
4cd4b622fd5782a3645b7eaa82a4f70e.png
  1. 、通讯实例:

以下数据为一空调遥控开机的收发数据

fc09ea5719786502b699e371a0c2e3ae.png
fc09ea5719786502b699e371a0c2e3ae.png
d62614d36179503d896369617c944355.png
d62614d36179503d896369617c944355.png

根据上述协议:

发送:获取系统参数(定点数)

7E 32 31 30 33 36 30 34 37 30 30 30 30 46 44 41 39 0D

接收:

7E 32 31 30 33 36 30 30 30 44 30 33 30 30 30 44 32 30 31 46

34 30 30 31 34 30 30 33 32 30 30 30 30 30 30 30 30 30 31 32

43 30 30 39 36 30 33 32 30 30 30 43 38 30 30 45 36 30 30 37

38 46 33 46 33 0D

总结

不论是MODBUS协议还是电总协议,其本质是上位机与监控设备之间的通信建立,二者之间有许多的共同之处。比如通信建立方式,设备为上一层之间大部分都是通过RS485/RS232来建立的,当然也有的是通过网卡协议来通信。

二者之间的区别在于,电总协议针对某一类型的数据信息,只需发送一条命令,即可拿到所有信息,如上述描述中的电总协议最后的示例,可以拿到此CID2下本空调设备所支持的所有系统参数信息(回风温度设定点——送风温度设定点);但是对于MODBUS来说,可以由上位机自主决定,需要从何处取,取多少个等。但是最终实现的功能还是一样的。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档