Modbus protocol基本原理-Modbus通信プロトコル要点第2部分

freeFree Technical Resource

This content is free to read, suitable for basic learning and search traffic.

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分

1、 Modbus简介

Modbus 是由 Modicon(现为シュナイダー电气公司的一1つのブランド)在 1979 年发明的,是全球第一个真正 用于工业现场的バス协议。ModBus 网络是一个工业通信系统,由带智能终端的可プログラミング序コントローラーは和計算机経由公用线路或局部专 用线路连接而成。其系统構造既包括硬件、亦包括软件。它可应用于各种データの収集和过程モニタリング。为更好地普及和推动 Modbus 在基于イーサネット(イーサネット)上的分布式应用,目前シュナイダー公司已将 Modbus protocol的 すべての权移交给 IDA(Interface for Distributed Automation,分布式自動化接口)组织,并成立了 Modbus-IDA 组织,为 Modbus 今后的发展奠定了基础。

在中国,Modbus 已经成为国家標準,并有专业的仕様書,感兴趣的可以去查阅相关的文件,詳細如下:標準编号为:GB/T19582-2008文件名称:《基于 Modbus protocol的工业自動化网络规范》

主要有三部分的内容,分别如下:

《GB/T 19582.1-2008 No. 1 部分:Modbus 应用协议》

《GB/T 19582.2-2008 No. 2 部分:Modbus protocol在串行链路上的実装ガイド》

《GB/T 19582.3-2008 No. 3 部分: Modbus protocol在 TCP/IP 上的実装ガイド》

2、Modbusプロトコル概述

Modbus是一个主-モデルから。的通信プロトコル,属于データ链路层上的协议,协议本身不涉及具体的硬件要求。常见的应用Modbusプロトコル的物理接口有RS-485、RS232、USART等的通信链路中。Modbusプロトコル中,一个时刻内只允许有一个マスター连接于バス,多个スレーブ连接于バス上,通信都是只能由マスター发起,スレーブ进行レスポンス。不能从スレーブ主动发起通信。

3、Modbus 主スレーブ通信モード

マスター和スレーブ之间的通信,可以用2つのモデル进行:广播通知モード、单播点对点モード。

3.1、单播点对点モード

マスター按照スレーブ的明确アドレスアクセス相应的スレーブ,スレーブ接到来自マスター的リクエスト并処理完リクエスト后,スレーブ会向マスター戻る一个应答,完成一个通信。在这种モード,一个 Modbus トランザクション処理包含 2 个报文:一个来自マスター的リクエスト,一个来自スレーブ的应答。在バス上,每个スレーブ都必须有唯一的スレーブアドレス (1 to 247),这样才能区别于其它节点被独立的寻址。

3.2、广播通知モード

マスター向所バス経由广播命令を送る。リクエスト,すべての的スレーブ都要受信来自マスター的广播信息。对于マスター广播的リクエスト,スレーブ是ない应答戻る的。すべての的スレーブ必须要接受マスター的广播模写功能。注意:address 0 是专门用于マスター向各个スレーブ广播データ的。

4、Modbus アドレスルール

Modbus 寻址空间有 256 个不同アドレス。如下图所示:

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト

address 0 ブロードキャストアドレス。すべての的スレーブ必须识别放送アドレス。Modbus マスター本身是ないアドレス的,只有スレーブ必须要有一アドレスはこちら。。该アドレス必须在 Modbus 串行バス上唯一。248~255作为预留使用的アドレス。

5、Modbus 的フレーム形式

Modbus的フレーム形式按照選択的モード不同フレーム形式也是有所区别的。

5.1、RTUモード

RTU モード下的フレーム形式如下图:

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト1

Modbus RTU フレーム总長さ最大为 256 byte。RTU モード每バイト単位。 ( 11 位 ) 的格式为 :8–位二进制,报文中每个 8 位バイト含有2つ 4 位十六进制文字(0–9, A–F)バイトあたりのバイト的 bit 流:1 スタート地点。8 data bit, 首先送信最低有效位1 位作为パリティ検査1 stop bitダブルチェック是要求的, 其它モード ( odd parity, 検証なし。 ) 也可以使用。为了保证与其它产品的最大兼容性, 同时サポート検証なし。モード是建议的。デフォルトチェックモードモード 必须为ダブルチェック。注 : 使用検証なし。要求 2 个ストップ·ビット。RTU时,每个文字或バイト均由此顺序送信(从左到右):

最低有效位 (LSB) . . . 最高有效位 (MSB)

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト2
Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト3

5.1.1、RTUモード下的フレーム通信

由送信デバイス将 Modbus 报文构造为带有已知起始和结束标记的フレーム。这使デバイス可以在报文的开始受信 新フレーム,并且知道何时报文结束。不完全的报文必须能够被检测到而エラーフラグ必须作为结果被設定。在 RTU モード,报文フレーム由时长至少为 3.5 个文字の時間的空闲間隔区分。

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト4

整个报文フレーム必须以连续的文字流送信。もし2つ文字之间的空闲間隔大于 1.5 个文字の時間,则报文フレーム被认为不完全应该被受信节点丢弃。

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト5

注意 :RTU モード下受信データ时,由于 t1.5 和 t3.5 的时間隔要求的存在,一般在高通信速率下,会导致 CPU 负担加重。因此,在通信速率等于或低于 19200 bps 时,这2つ定时必须严格遵守;对于ボーレート大于 19200 bps 的情形,应该使用 2 个定时的固定值:建议的文字间タイムアウト時間(t1.5)为 750µs,フレーム间的タイムアウト時間 (t1.5) 为 1.750ms。下图表示了对 RTU 传输モードステータス图的説明。"主节点" 和 "子节点" 的不同角度均在相同的图中表示:

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト6

上面ステータス图的一些解释:

1)从 "初始" 态到 “空闲” 态转换需要 t3.5 定时タイムアウト: 这保证フレーム间延迟

2)“空闲” 态是ない送信和受信报文要処理的正常ステータス。

3)在 RTU モード, 当ない活动的传输的時間の間隔达 3.5 个文字长时,通信链路被认为在 “空闲” 态。

4)当链路暇なとき, 在链路上检测到的任何传输的文字被识别为フレーム起始。链路变为 "活动" status。然后当链路上ない文字传输的时间间个达到 t3.5 后,被识别为フレーム结束。

5)检测到フレーム结束后,Complete CRC calculation和检验。然后,分析アドレス域以确定フレーム是否发往此デバイス,もしではない, 则丢弃此フレーム。为了减少受信処理时间,アドレス域可以在一接到就分析,而必要なし。等到整个フレーム结束。这 样,CRC calculation只需要在フレーム寻址到该节点 (包括广播フレーム) 时进行。

5.1.2、RTUモード的CRC check

在 RTU モード包含一个对すべて报文内容执行的,基于循环冗余チェック (CRC - Cyclical Redundancy Checking) 算法的エラー检验域。CRC 域检验整个报文的内容。不管报文有パリティなし,均执行此检验。CRC 包含由2つ 8 位バイト组成的一个 16 位值。CRC 域作为报文的最后的域附加在报文之后。計算后,首先附加低バイト数,然后是ハイバイト。CRC high字 节为报文送信的最后一个子节。附加在报文后面的 CRC 的值由送信デバイス計算。受信デバイス在受信报文时重新計算 CRC 的值,并将计 算结果于实际受信到的 CRC 值相比较。もし2つ值不相等,则为エラー。CRC 的計算, 开始对一个 16 位レジスタ预装全 1。然后将报文中的连续的 8 位子节对其进行后续的计 算。只有文字中的 8 个データ·ビット参与生成 CRC 的运算,スタート地点。,ストップ·ビット和チェックビット不参与 CRC calculation。CRC 的生成过程中, 每个 8–位文字与レジスタ中的值异或。然后结果向最低有效位(LSB)方向移動 (Shift) 1 位,而最高有效位(MSB)位置充零。然后提取并チェック LSB:もし LSB 为 1, 则レジスタ中的值与 一个固定的预置值异或;もし LSB 为 0, 则不进行异或操作。这个过程将重复直到执行完 8 次移位。完成最后一次(No. 8 次)移位及相关操作后,下一个 8 位バイト 与レジスタ的当前值异或,然后又同上面説明过的一样重复 8 次。当すべての报文中子节都运算之后得到的寄存 器的最终值,就是 CRC。

5.2、ASCII传输モード

当 Modbus 串行链路的デバイス被設定为使用 ASCIIモード通信时,报文中的每个 8 位バイト以2つ ASCII 文字送信。一般在通信链路或者デバイス无法 符合 RTU モード的定时管理使用するとき该モード。ASCII的フレーム形式如下:

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト7

比如 : byte 0X5B 会被编码为2つ文字 : 0x35 和 0x42 ( ASCII Coding 0x35 ="5", 0x42 ="B" )。注 : 由于一个子节需要2つ文字,此モード比 RTU 效率低。

ASCII モード每バイト単位。 ( 10 位 ) 的格式为 :hexadecimal,ASCII characters 0-9, A-F。1 スタート地点。7 data bit, 首先送信最低有效位1 位作为パリティ検査1 stop bitダブルチェック是要求的, 其它モード ( odd parity, 検証なし。 ) 也可以使用。为了保证与其它产品的最大兼容性, 同时サポート検証なし。モード是建议的。デフォルトチェックモードモード 必须为ダブルチェック。注 : 使用検証なし。要求 2 个ストップ·ビット。文字是如何串行传送的:每个文字或バイト均由此顺序送信(从左到右):

最低有效位 (LSB) . . . 最高有效位 (MSB)

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト8
Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト9

5.2.1、ASCII的报文フレーム

在 ASCII モード, 报文用特殊的文字区分フレーム起始和フレーム结束。一个报文必须以一个‘冒号’ ( : ) (ASCII hexadecimal 3A )start,以 ‘回车-换行’ (CR LF) 对 (ASCII hexadecimal 0D 和 0A) End。注 : LF 文字可以経由特定的 Modbus 应用命令 (参见 Modbus 应用プロトコルの仕様) 改变。对于すべての的域,允许传送的文字为十六进制 0–9, A–F (ASCII Coding)。デバイス连续的监视バス上的 ‘冒 No.’ characters。当收到这个文字后,每个デバイス解码后续的文字一直到フレーム结束。报文中文字间的時間の間隔可以达一秒。もし有更大的間隔,则接受デバイス认为发生了エラー。特别注意:每个文字子节需要用2つ文字编码。因此,为了确保 ASCII モード 和 RTU モード在 Modbus 应 用级兼容,ASCII データ域最大データ長さ为 (2x252) 是 RTU Anti-counterfeiting verification (252) 的两倍。必然的, Modbus ASCII フレーム的最大尺寸为 513 个文字。ASCII 报文フレーム的要求在下面的ステータス图中综合。"主节点" 和 "子节点" 的不同角度均在相同的图中表示:

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト10

上面ステータス图的一些解释:1)“空闲” 态是ない送信和受信报文要処理的正常ステータス。2)每次受信到 ":" 文字表示新的报文的开始。もし在一个报文的受信过程中收到该文字,则当前地报文 被认为不完全并被丢弃。而一个新的受信バッファ。被重新分配。3)检测到フレーム结束后,Complete LRC 計算和检验。然后,分析アドレス域以确定フレーム是否发往此デバイス,もしではない, 则丢弃此フレーム。为了减少受信処理时间,アドレス域可以在一接到就分析,而必要なし。等到整个フレーム结束。

5.2.2、ASCII的LRC verification

在 ASCII モード,包含一个对すべて报文内容执行的,基于纵向冗余チェック (LRC - Longitudinal Redundancy Checking) 算法的エラー检验域。LRC 域检验不包括起始“冒号”和结尾 CRLF 对的整个报 文的内容。不管报文有パリティなし,均执行此检验。LRC 域为一个子节,包含一个 8 位二进制值。LRC 值由送信デバイス計算,然后将 LRC 附在报文后面。受信デバイス在受信报文时重新計算 LRC 的值,并将計算结果于实际受信到的 LRC 值相比较。もし2つ值不 相等,则为エラー。LRC 的計算, 对报文中的すべての的连续 8 位バイト相加,忽略任何进位,然后求出其二进制补码。执行检 验针对不包括起始“冒号”和结尾 CRLF 对的整个 ASCII 报文域的内容。在 ASCII モード,LRC 的结果 被 ASCII 编码为两バイト単位。并放置于 ASCII モード报文フレーム的结尾,CRLF 之前。

6、Modbus的異常コード。

MODBUS トランザクション処理的一般処理过程:

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト11

一旦サーバー·サーバー処理リクエスト,使用合适的 MODBUS サーバー·サーバートランザクション建立 MODBUS Response。根据結果の処理,可以建立两种タイプレスポンス:

1) 一个正确的 MODBUS Response:レスポンス機能コード = リクエスト機能コード

2) 一个 MODBUS Exception Response

3)用来为客户机提供処理过程中与被发现的差错相关的信息;

4)レスポンス機能コード = リクエスト機能コード + 0x80;

5)提供一个異常コード。来指示差错原因。

7、Modbus的機能コード

7.1、機能コード的类别

目前Modbus的功能中可以分为三类:パブリック機能コード、用户定义機能コード、保留機能コード。

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト12

パブリック機能コード :是已经被定义的機能コード。

用户定义機能コード :有2つ可以由用户定义機能コード。範囲为:65 to 72 和十进制 100 to 110。

保留機能コード :特殊情况下使用的,并且对公共使用是无效的機能コード。

7.2、パブリック機能コード

Modbus中パブリック機能コード的定义如下:

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト13

7.2.1、コイル操作機能コード(bit位的操作)

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト14

比如我要リードコイル中的内容。スレーブアドレス为 11H,コイルレジスタ的開始アドレス为 0013H,结束アドレス为 0037H。需要查询总共 37 1つのコイルレジスタ,マスター送信的RTUフレーム如下:

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト15

スレーブレスポンス的データフレーム如下:

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト16

Parse:コイル 0013H 到コイル 001AH 的ステータス为 CDH,二进制值为 11001101,该バイト的最ハイバイト为コイル 001AH , 最 低 字 节 为 线 圈 0013H 。各コイルの状態与データ内容每位相对应。1 代表 ON,0 代表 OFF。线 圈 001AH to 线 圈 0013H 的 ステータス分别为:

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト17

7.2.2、レジスタを保持する。操作機能コード

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト18

(1)複数書き込みレジスタを保持する。

複数書き込みレジスタを保持する。使用機能コード10H。比如:スレーブアドレス为 11H。レジスタを保持する。的其实アドレス为 0001H,レジスタ的结束アドレス为 0002H。总共アクセス 21つのレジスタ。レジスタを保持する。 0001H 的内容为 000AH,レジスタを保持する。 0002H 的内容为 0102H。

マスターリクエスト的RTUフレームデータ如下:

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト19
Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト20

スレーブ戻る的レスポンス为:

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト21

(2)read holding registers

リードホールドレジスタ使用03Hfunction code。比如:スレーブアドレス为 11H。レジスタを保持する。的開始アドレス为 006BH,结束アドレス为 006DH。

マスター送信的RTUリクエストフレーム如下:

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト22
Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト23

スレーブ的应答如下:

Modbus protocol基本原理-Modbus通信プロトコル要点第2部分イラスト24
Put this resource to use in a real project?

Go to the Tool Center for message parsing, CRC verification and device debugging, or submit your requirements for selection and integration advice.

Engineer Membership

Turn this article into actionable debugging resources

After activation, you can use advanced message parsing, resource pack downloads, code examples, engineering cases and priority technical support, suitable for real project delivery.

Unlimited Advanced Tools
Resource & Code Packs
Complete Engineering Case Library
Priority Technical Support

Leave a Reply

Your email address will not be published. Required fields are marked *.