背景
介紹modbus rtu之前,我們可以了解到,Modbus是施耐德電氣公司,于1979年發(fā)明的,是全球第一個真正用于工業(yè)現(xiàn)場的總線協(xié)議。四十多年過去了,現(xiàn)在仍然被廣泛使用在各個工業(yè)控制領(lǐng)域。除了這個協(xié)議很穩(wěn)定的原因之外:
免費;
方便部署和維護;
對供應(yīng)商來說,修改移動本地的比特或字節(jié)沒有很多限制;
modbus 是OSI模型第七層上的應(yīng)用層報文傳輸協(xié)議,OSI定義了開放系統(tǒng)的層次結(jié)構(gòu)、層次之間的相互關(guān)系以及各層所包括的可能的任務(wù),作為一個框架來協(xié)調(diào)和組織各層所提供的服務(wù)。
OSI參考模型并沒有提供一個可以實現(xiàn)的方法,而是描述了一些概念,用來協(xié)調(diào)進程間通信標準的制定。即OSI參考模型并不是一個標準,而是一個在制定標準時所使用的概念性框架。
modbus在OSI模型中,可以描述為下圖;
modbus osi模型中的位置
EIA485/TIA485就是RS485,隨著技術(shù)不斷發(fā)展,485標準目前是電信行業(yè)協(xié)會(TIA)維護,所以名稱為TIA-485,當然工程師及應(yīng)用指南仍繼續(xù)用RS-485來稱呼也是沒問題的;
下面我們來介紹一些串行鏈路協(xié)議。
Modbus 串行鏈路協(xié)議
Modbus串行鏈路協(xié)議是一個主從模式(主機和從機),半雙工的數(shù)據(jù)傳輸協(xié)議,485標準通常需要兩條線,在某一個確定時刻,有一個主機和從機進行通訊。
主從模式:通常總線上有一個主機和多個從機,每個從機有唯一的ID,主機通過ID進行尋址從機,然后進行數(shù)據(jù)傳輸;
半雙工傳輸:相對應(yīng)半雙工的是全雙工,全雙工運行發(fā)送數(shù)據(jù)和接收數(shù)據(jù)同時發(fā)生,所以半雙工就不難理解了,同一時刻只能進行發(fā)送數(shù)據(jù),或者只能接收數(shù)據(jù);
整體的結(jié)構(gòu)圖如下所示;
一個485總線的主從模式
這里我們還要明確幾點:
從機無法主動向從機發(fā)送數(shù)據(jù),只有在主機發(fā)送數(shù)據(jù)給從機(發(fā)送請求),然后從機接收到主機發(fā)送的數(shù)據(jù)之后,再回傳數(shù)據(jù)給主機;具體如下所示;
主從模式
正如前面所提到的,modbus是半雙工傳輸?shù)模粗鳈C發(fā)送數(shù)據(jù)的時候,是不能接收數(shù)據(jù)的,所以這里總共分為兩步來進行。
主機發(fā)送數(shù)據(jù)的方式有兩種,一個是 1對1,一個是1對多,也就是我們常說的廣播形式,所有從機都可以收到主機發(fā)送的數(shù)據(jù);
1對1 只需要發(fā)送數(shù)據(jù)給特定地址的從機即可,廣播只需要把發(fā)送地址設(shè)置為0即可,所以廣播地址為0;
這里我們已經(jīng)大致了解了主機和從機之間的數(shù)據(jù)傳輸?shù)那闆r,下面我們就再來介紹一下數(shù)據(jù)傳輸?shù)木唧w格式;
傳輸模式
先來說說Modbus有兩種傳輸模式,RTU傳輸模式和ASCII傳輸模式;
RTU傳輸:Remote Terminal Unit模式在Modbus中消息由十六進制組成,數(shù)據(jù)密度高,吞吐率高;
ASCII傳輸:消息由ASCII 字符發(fā)送效率不及RTU模式,無法使用RTU模式的定時管理時,使用ASCII模式;
比如:0x12會被整合成兩個字符發(fā)送:0x31和0x32發(fā)送,
因為 0x31等于字符1;0x32等于字符2
下面我們會主要介紹modbus RTU。
幀格式
在講幀格式之前,首先我們想象一下,人與人之間的對話,最基本單元是漢字,然后相互交流就用漢字組成的句子,比如下面的對話;
老板問:中午吃什么?
小樟說:吃飯吧!
所以機器之間的通信也是類似的,我們可以把字節(jié)當作最基本的數(shù)據(jù)單元,然后由字節(jié)組成句子,也就是通信幀;
但是現(xiàn)在情況出現(xiàn)了變化,對話的人里,除了小樟,還有一個小紅,這時候,為了明確和誰說話,就需要在對話前面加上名字:
老板:小樟,中午吃面嗎?
小樟:老板,吃飯去吧。
小紅,沒有叫他,語言柚子;
所以我們繼續(xù)回到modbus的數(shù)據(jù)幀格式,這里的協(xié)議定義了一個基礎(chǔ)通信層的簡單協(xié)議數(shù)據(jù)單元(PDU),具體如下圖所示;
所以這里基本分為四個部分,地址域,功能碼,數(shù)據(jù),差錯校驗(CRC/LRC),統(tǒng)稱為ADU (Application Data Unit),基本上進行傳輸?shù)臄?shù)據(jù)都要滿足這個格式,作為一個完整的幀,對照前面老板的對話內(nèi)容,我們這里可以簡單的理解一下:
地址域:可以理解成 具體和誰說話;
功能碼:可以理解成 具體動作,比如 去做,來拿,去吃 等等;
數(shù)據(jù):可以理解成 具體內(nèi)容,比如 面,飯 等等,也可以是其他,這里配合上下文,所以是吃的東西;
差錯校驗:可以理解成,說出來的話必須可以讓人理解,不然別人聽不懂啊;實際上在協(xié)議中通常使用CRC或LRC保證傳輸?shù)臄?shù)據(jù)沒有錯誤;
下面我們再深入分析一下;
PDU
Modbus PDU(protocol data unit)格式被定義為一個功能代碼,后面跟著一組關(guān)聯(lián)的數(shù)據(jù)。
該數(shù)據(jù)的大小和內(nèi)容由功能代碼定義,整個PDU(功能代碼和數(shù)據(jù))的大小不能超過253個字節(jié)。
每個功能代碼都有一個特定的行為,從設(shè)備可以根據(jù)所需的應(yīng)用程序行為靈活地實現(xiàn)這些行為。
PDU規(guī)范定義了數(shù)據(jù)訪問和操作的核心概念;但是,從設(shè)備可能會以規(guī)范中未明確定義的方式處理數(shù)據(jù)。
地址域
地址域占用一個字節(jié),所以一般來說尋址范圍是0~255,一般在系統(tǒng)中用1~147,其他地址暫時保留,另外,同一個總線上的從機,每個地址必須唯一。
其中0是廣播地址;
下面是Freemodbus的一個從機初始化代碼,0x02就是這個從機的地址,
eMBInit(MB_RTU,0x02,3,115200,MB_PAR_NONE);
功能碼
功能碼占一個字節(jié),所以范圍是 0~255,協(xié)議中規(guī)定了功能碼分為三類:公共功能碼,用戶自定義功能碼,保留功能碼。整體如下所示;
公共功能碼必須保證它的唯一性,這是由Modbus組織已經(jīng)規(guī)定好,并且具有一致性測試的功能碼,所以在一定程度上,它保證了協(xié)議的可復(fù)用性。
由上表可知,公共功能碼分為四種,分別是:
離散量輸入:只讀類型,單位:bit;
線圈:讀寫類型,單位:bit;
輸入寄存器:只讀類型,單位:字節(jié);
保持寄存器:讀寫類型,單位:字節(jié);
下面是移植Freemodbus協(xié)議,從機上需要對這四個公共功能碼處理的回調(diào)函數(shù):
//輸入寄存器量 eMBErrorCodeeMBRegInputCB(UCHAR*pucRegBuffer,USHORTusAddress,USHORTusNRegs) { eMBErrorCodeeStatus=MB_ENOERR; returneStatus; } //保持寄存器量 eMBErrorCode eMBRegHoldingCB(UCHAR*pucRegBuffer,USHORTusAddress,USHORTusNRegs, eMBRegisterModeeMode) { eMBErrorCodeeStatus=MB_ENOERR; returneStatus; } //線圈數(shù)量 eMBErrorCode eMBRegCoilsCB(UCHAR*pucRegBuffer,USHORTusAddress,USHORTusNCoils, eMBRegisterModeeMode) { eMBErrorCodeeStatus=MB_ENOERR; returneStatus; } //離散輸入數(shù)量 eMBErrorCode eMBRegDiscreteCB(UCHAR*pucRegBuffer,USHORTusAddress,USHORTusNDiscrete) { eMBErrorCodeeStatus=MB_ENOERR; returneStatus; }
底層如何傳輸
我們先看一下最底層modbus數(shù)據(jù)是如何發(fā)送的,沒錯,看到RS485和232,那我們自然想到了串口。
所以最根本的數(shù)據(jù)格式可以參考一下串口數(shù)據(jù)的定義,也就是我們說的起始位,數(shù)據(jù)位,校驗位,數(shù)據(jù)位;具體如下所示;
所以這里我們可以規(guī)定一下:
起始位+數(shù)據(jù)位+校驗位(可選)+ 停止位 等于一個字符;因此這里可以通過串口的波特率去計算出單個字符所需要的時間。
然后我們再看一下,modbus幀是如何發(fā)送的?
在RTU模式中,幀之間的間隔至少為3.5個字符的空閑時間間隔,以便于表示幀的開始和幀的結(jié)束,所以如果想自己整一個modbus rtu就需要一個定時器去結(jié)算空閑時間的長度。
3.5字符時間
整個數(shù)據(jù)必須以連續(xù)的字符流進行發(fā)送,如果兩個字符之間的長度等于1.5個字符時間,則認為幀消息不完整,則認為設(shè)備不該接收該消息,具體如下所示;
1.5字符時間
這里需要注意的是RTU需要定時器中斷的參與,所以,1.5字符時間和3.5字符時間的檢測,在串口通訊速率很高的時候,需要高頻率得進入中斷,這就會增加系統(tǒng)開銷。
所以通常在波特率低于19200的時候,可以嚴格遵守1.5和3.5字符時間的規(guī)定。
如果波特率大于19200的時候,需要滿足兩個固定時間即可:
1.5字符時間:750 us;
3.5字符時間:1.75ms;
總結(jié)
本文簡單介紹了modbus rtu協(xié)議,包括串行鏈路通信,幀格式以及硬件鏈路層的消息格式。
審核編輯:劉清
-
寄存器
+關(guān)注
關(guān)注
31文章
5336瀏覽量
120230 -
RS-485
+關(guān)注
關(guān)注
11文章
683瀏覽量
84255 -
ModBus協(xié)議
+關(guān)注
關(guān)注
3文章
177瀏覽量
33416 -
CRC校驗
+關(guān)注
關(guān)注
0文章
84瀏覽量
15207 -
RTU
+關(guān)注
關(guān)注
0文章
412瀏覽量
28668
原文標題:一文搞懂 Modbus RTU 協(xié)議
文章出處:【微信號:knifewheat,微信公眾號:小麥大叔】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論