<dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><small id="yhprb"></small><dfn id="yhprb"></dfn><small id="yhprb"><delect id="yhprb"></delect></small><small id="yhprb"></small><small id="yhprb"></small> <delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"></dfn><dfn id="yhprb"></dfn><s id="yhprb"><noframes id="yhprb"><small id="yhprb"><dfn id="yhprb"></dfn></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><small id="yhprb"></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn> <small id="yhprb"></small><delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn>

新聞中心

EEPW首頁(yè) > 嵌入式系統 > 設計應用 > 利用MODBUS提高多CPU系統協(xié)同開(kāi)發(fā)的效率

利用MODBUS提高多CPU系統協(xié)同開(kāi)發(fā)的效率

作者: 時(shí)間:2018-09-05 來(lái)源:網(wǎng)絡(luò ) 收藏

摘要:提出利用MODBUS協(xié)議實(shí)現多CPU系統中信息交互的方案,分析了軟硬件通信機制的設計和系統協(xié)同開(kāi)發(fā)的方法,以及各種提高通信效率的措施。

本文引用地址:http://dyxdggzs.com/article/201809/388442.htm

關(guān)鍵詞:MODBUS通信協(xié)議,多CPU系統,通信

在電力系統微機綜合保護和自控裝置以及其它工業(yè)自動(dòng)化控制領(lǐng)域,微控制器的應用越來(lái)越廣泛,其裝置的復雜性也越來(lái)越高。為了解決其開(kāi)發(fā)對象實(shí)時(shí)多任務(wù)性的要求,單CPU、單入開(kāi)發(fā)的模式下在被多個(gè)、多類(lèi)型  CPU和多人協(xié)同開(kāi)發(fā)的模式所代替。在這新的開(kāi)發(fā)模式中,面臨一個(gè)新問(wèn)題——在實(shí)施信息交互的過(guò)程中如何將實(shí)現CPU之間信息交互的軟硬件標準化,這是關(guān)系到該模式能否成功實(shí)施的關(guān)鍵。在眾多的通信方式中,基于UART的RS-485串行通信模式以其連線(xiàn)簡(jiǎn)捷、可靠性高和可帶動(dòng)多CPU、多設備級連的能力而被廣泛采用。在軟件通信協(xié)議的選擇上,MODBUS協(xié)議由于其通用、成熟的第三方標準測試軟件,為用戶(hù)使用提供了諸多優(yōu)勢。因此,在開(kāi)發(fā)新型電動(dòng)機綜合保護裝置TH21-4M的過(guò)程中,采用RS-485串行通信方式和MODBUS通信協(xié)議,實(shí)現了多CPU之間的數據和控制命令的信息交互。為了增強串行通信的高效、協(xié)調性,筆者在通信機制的軟硬件結構上采取了很多措施,并取得了很好的效果。在調試系統通信階段,使用了各CPU模塊先與MODBUS標準測試軟件通信,之后再互相聯(lián)調的方法,大大提高了協(xié)同開(kāi)發(fā)的效率。實(shí)踐證明,該設計思想簡(jiǎn)化了系統的結構,大大提高了裝置的運行效率和可靠性。本文將結合  TH21-4M的設計思路,從硬件設計和軟件規劃兩方面,介紹如何利用MODBUS通信協(xié)議,實(shí)現多CPU結構的協(xié)同開(kāi)發(fā)。

1 TH21-4M電動(dòng)機綜合保護裝置的特點(diǎn)

TH21-4M電動(dòng)機綜合保護裝置綜合保護功能以外,兼有測量、遠動(dòng)和通信的功能;大屏幕的漢字液晶顯示,可以實(shí)現友好的人機界面;利用CAN總線(xiàn),與監控主機進(jìn)行通信,從而構成分級分散式的變電站綜合自動(dòng)化系統的子系統。

在設計上,由于裝置需要實(shí)現多任務(wù),為了優(yōu)化系統功能,采用了多CPU的系統結構。其中一個(gè)CPU負責定時(shí)采樣脈沖發(fā)送;主CPU模塊負責數據處理、電量計算、故障判斷和開(kāi)關(guān)操作;而板模塊上CPU負責人機交互,并實(shí)現與主保護模塊和監控主機的通信任務(wù)。各個(gè)CPU模塊有明確的任務(wù)分工,研制時(shí)也容易實(shí)現多人協(xié)同開(kāi)發(fā)。在整個(gè)構成中,串行通信溝通了主CPU和面板CPU,使人機交互成為可能,因而點(diǎn)有重要的地位。建立合理的通信機制則是串行通信部分的核心的所在,它決定著(zhù)通信的協(xié)調性和系統開(kāi)發(fā)后期調試的效率。

2 通信機制介紹

2.1 通信機制硬件設計原理

本系統通信機制的提出以高效、可靠為目的。RS-485為半雙工結構,現場(chǎng)中比全雙工往往更接近于實(shí)用,在此采用只有2條信號線(xiàn)的最簡(jiǎn)型連接。系統接口電路圖由圖1所示。主保護模塊上的80C196單片機輸出的TTL邏輯電平通過(guò)光電隔離后,由MAX485芯片轉換為RS-495電平,再由面板模塊上的MAX485芯片轉換為T(mén)TL邏輯電平,由80C31單片機讀取;以之亦然。在  80C196單片機一側,使用并行輸入輸出口2(IO_PORT2)的一位P2.7對MAX輸入使能端RE、輸出使能端DE進(jìn)行控制。由圖1可知,當  P2.7輸出高電平時(shí),RE使能,單片機一側接收數據;當P2.7輸出低電平時(shí),DE使能,單片機一側發(fā)送數據。這樣,避免了盲目發(fā)送造成的數據疊加丟失現象,通信質(zhì)量高,通信速度也能得到保證。

2.2 通信協(xié)議介紹

為了保證保護裝置中兩個(gè)模塊之間能夠正確地傳遞數據,必須有一套關(guān)于信息傳輸的模式、數據格式和內容等的規定,即規約[1]或通信協(xié)議。雖然保護裝置內部的通信相對簡(jiǎn)單,兩具模塊之間傳遞的數據也不是很多,但是自定義內部通信協(xié)議的弊端是很明顯的。首先,自定義通信協(xié)議很難在時(shí)序、任務(wù)的協(xié)調上配合得很好,數據傳送的可靠性也難以保證;首次,由于沒(méi)有現成的較成熟的調試軟件,主  CPU模塊基本是黑匣子,系統聯(lián)調時(shí)的困難較多且難以克服。因此,采用了當前流行的MODBUS通信協(xié)議,并結合本裝置的特點(diǎn)加以簡(jiǎn)化,從而實(shí)現了模塊間的通信,事實(shí)證明效果很好。

MODBUS的通信方式為主從方式[2]。主方首先向從方發(fā)送通信請求指令,從方根據請求指令中的功能碼向主方發(fā)回數據。每個(gè)從方都有自己獨立的地址。主方所發(fā)的請求幀和從方所發(fā)的應答幀都是以從方地址開(kāi)頭的。從方只讀發(fā)給自己的指令,對以其他從方地址開(kāi)頭的報文不作應答。這種一問(wèn)一答的通信模式,大大提高了通信的正確率。但對于微機保護來(lái)說(shuō),該主從方式也存在著(zhù)弊端,即當保護主模塊進(jìn)行保護動(dòng)作后,無(wú)法立刻向上位機傳送故障信息,只能由上位機不斷向保護主模塊詢(xún)問(wèn)保護是否動(dòng)作,若有,則再進(jìn)一步要求具體故障信息。

MODBUS有RTU(Remote Terminal  Unit)和ASCII兩種傳送方式。為了保證較高的通信速度,采用了RTU方式,數據字節無(wú)奇偶校驗位,加上起始、終止位后字節長(cháng)度為10bit,數據間隔在24bit以?xún)?,采用循環(huán)冗余檢驗方式對報文進(jìn)行校驗。

MODBUS典型的報文格式如下:

主方發(fā)報文:

從方正常時(shí)回答:

一個(gè)通信報文的具體內容取決于該指令字符串的功能碼,MODBUS中定義的標準功能碼如表1所示。

表1 MODBUS協(xié)議中的標準功能碼

由功能碼的定義可以看出,傳送的報文對象主要分為模擬量和數字量?jì)深?lèi),由報文頭的功能碼來(lái)確定報文的內容。在實(shí)際應用中,主要使用02、04、05和06這四種功能碼,完成對數字量和模擬量的讀取及設置。

數據起始地址和數據量是報文的主要內容。MODBUS規定的數據量是從通信對象的器件中讀取的數據或是往通對象的器件中寫(xiě)入的數據。每個(gè)通信對象器件都有自己的地址。在保護裝置的內部通信中,指定各通信對象器件為主機板的RAM中保存的數字量和模擬量,以及EEPROM中設定的保護配置和定值。在處理通信報文時(shí),由報文的數據起始地址和對應的數據量長(cháng)度進(jìn)行讀取或發(fā)送任務(wù)。當傳送數字量時(shí),不同地址的數據值用報文中數據量不同的位來(lái)表示,這樣就能傳送更多的數據信息,從而高效地利用通信報文。由于每幀數據不定長(cháng),方便靈活,因而避免了固定幀長(cháng)造成的對CPU時(shí)間和內存空間的浪費。另外,MODBUS通信協(xié)議規定在通信字符串中的地址比實(shí)際地址小“1”,這對數組進(jìn)行操作時(shí)是一個(gè)方便之處。

報文末的兩個(gè)字節為校驗字節。RTU方式通信采用CRC-16位循環(huán)碼冗余校驗,即將整個(gè)字符串(不包括最后兩個(gè)字節)按規定的方式進(jìn)行位移并進(jìn)行異或計算,計算結果存在字符串的最后兩個(gè)字節內,并由接收方按同樣的計算方法進(jìn)行校驗是否一致。這種校驗方法對隨機或突發(fā)差錯造成的幀破壞有很好的校驗效果。

3 提高通信效率的措施

在確立硬件平臺和通信協(xié)議后的軟件設計過(guò)程中,筆者采用了很多方法提高通信的效率和可靠性。

3.1 將通信分為接收和發(fā)送兩個(gè)獨立的任務(wù)

80C196單片機可以使用查詢(xún)和中斷兩種方法通過(guò)串行口發(fā)送和接收數據。對于中斷方式,80C196單片機提供了兩種串口中斷方式:第一種方式為一個(gè)單獨的串口中斷,由中斷屏蔽寄存器INT_MASK的D6位控制,對應中斷向量  200CH,串行口狀態(tài)寄存器SP_STAT(11H)的D5(發(fā)送完標志TI)和D6(接收完標志RI)置位都將觸發(fā)該中斷;第二種方式為接收、發(fā)送分別設置了中斷號,使用INT_MASK1的D0位對應發(fā)送中斷,中斷向量2030H,TI置位觸發(fā)該中斷;INT_MASK1的D1位對應收中斷,中斷向量2032H,RI置位觸發(fā)該中斷。筆者采用了第二種通信方式。這樣每接收完或發(fā)送完一個(gè)字節后就觸發(fā)相應的中斷,直接進(jìn)行下一輪的接收、發(fā)送任務(wù),而不必判斷串口控制/狀態(tài)寄存器SP_CON/SP_STAT(11H),使得中斷子程序更為簡(jiǎn)練、高效。

3.2 盡量縮短中斷時(shí)間

由于設計軟件結構時(shí)使用了多個(gè)中斷,為了保證程序的可靠運行,減少不同不斷間互沖突的機率,在編制軟件時(shí)盡可能簡(jiǎn)練各種中斷的任務(wù),縮短中斷執行時(shí)間。在通信中斷子程序中,進(jìn)入中斷后執行必要的任務(wù),如:清串行口狀態(tài)寄存器  SP_STAT中相應的狀態(tài)位,將剛接收到的字符或需要發(fā)送的字符從緩沖區內讀出或寫(xiě)入緩沖區,已接收或發(fā)送字符數增1等,之后便立即退出中斷。其它任務(wù)如判斷幀的有效性、對接收幀命令(遙測、遙控命令)的應答,準備發(fā)送幀等,都放在主程序中完成。

3.3 可靠地判斷幀結束,防止通信停滯

利用單獨的軟件定時(shí)器,來(lái)判斷一幀接收報文結束,可以防止若報文接收不完整,該幀通信任務(wù)無(wú)法結束而影響下一幀的接收。

由于一幀報文中字節與字節之間的時(shí)間間隔和幀與幀之間的時(shí)間間隔相比要小得多,因此每當接收一個(gè)新字節,就啟動(dòng)軟件定時(shí)器開(kāi)始計時(shí),定時(shí)器的時(shí)間設定為幀與幀的最小時(shí)間間隔。波特率不同,該時(shí)間間隔也不同。若不到預定的時(shí)間內又接收到下一個(gè)字節,則說(shuō)明一幀報文未結束,定時(shí)器重新計時(shí);若定時(shí)器順利計數到預定時(shí)間,就會(huì )觸發(fā)相應的中斷號,在該定時(shí)器中斷子程序中設定幀結束標志字節,表明一幀報文接收完畢。當主程序內檢測到一幀報文接收完畢后,會(huì )通過(guò)核查從方地址及循環(huán)冗余校驗字節是否正確來(lái)判斷該幀的有效性。若確定接收到的是一幀發(fā)送給已方的正確報文,則會(huì )根據報文內的功能碼對該幀命令進(jìn)行相應的處理,并準備發(fā)送幀。

MODBUS協(xié)議還規定了從方接收報文不正確時(shí)發(fā)回的出錯幀??紤]到裝置內部通信的過(guò)程不很復雜,在實(shí)際應用中如果從方收到的報文校驗不正確,采取不作應答的方式。主方若在規定時(shí)間內未收到從方的應答報文時(shí),將重發(fā)請求報文;若多次未收到從方應答報文,則報通訊故障。

3.4 通信速率的確定

由于所開(kāi)的裝置都在同一機箱內,模塊與模塊之間的間距很短,而MODBUS是基于RS485的長(cháng)距離通信,可以不考慮距離對通信波特率的影響,并且由于采用主從式通信模式,不會(huì )出現線(xiàn)路堵塞現象。因此,僅從通信效率來(lái)看,只要不超過(guò)模塊所使用芯片對最高波特率的限制,則設定的波特率越高,信息交互越快,通信效率也越高。但是,對于實(shí)時(shí)多任務(wù)系統,必須注意各任務(wù)的協(xié)調。MODBUS  通信協(xié)議中只對各種通信報文格式作了規定,對通信波特率和奇偶校驗等不作硬性規定。當一幀報文的長(cháng)度較長(cháng),而波特率又很高,會(huì )導致CPU忙于處理通信而可能丟失其它實(shí)時(shí)性任務(wù),如實(shí)時(shí)采樣等。因此,選擇通信波特率時(shí)必須注意與其它任務(wù)相協(xié)調,而不是越高越好。在實(shí)際應用中,將波將率設置到  19200bps,系統調調運作。由于設定通信雙方波特率完全一致,可以使接收端對每一個(gè)數據位的采樣都發(fā)生在位周期的中點(diǎn),實(shí)現可靠通信。另外,在字符傳送時(shí)不使用奇偶校驗位,以此相對提高了有效字節傳遞的速率。

3.5 合理的調試方法

在開(kāi)發(fā)初期,使用仿真器等工具只能對單一CPU模塊進(jìn)行實(shí)時(shí)監測,而無(wú)法同時(shí)監測串行通信雙方,難以確定問(wèn)題所在,使調試效率受到很大影響。因此先將各CPU模塊分別通過(guò)  RS485/RS232數據轉換模塊與微機進(jìn)行通信測試,成功后再進(jìn)行模塊間聯(lián)調,大大提高了聯(lián)調的效率。在調試各模塊與微機通信的過(guò)程中,微機使用  MODBUS調試軟件,模仿主方的通信過(guò)程,主動(dòng)向從方(各CPU模塊)索要信息。整個(gè)接收、發(fā)送過(guò)程都是透明、清晰的,使得模塊中存在的絕大多數問(wèn)題都能在與微機通信的過(guò)程發(fā)現并及時(shí)解決。CPU模塊間聯(lián)調時(shí),可以利用總線(xiàn)監控軟件,觀(guān)察雙方發(fā)送的數據。當遇到通信問(wèn)題的時(shí)候,就能比較容易地確定是哪一個(gè)模塊發(fā)送數據不正確,從而確定問(wèn)題所在。采用這樣的調試方法,大大增強了不同開(kāi)發(fā)人員、不同CPU之間的協(xié)調性,提高了裝置研發(fā)的效率和進(jìn)度。



關(guān)鍵詞:

評論


相關(guān)推薦

技術(shù)專(zhuān)區

關(guān)閉
国产精品自在自线亚洲|国产精品无圣光一区二区|国产日产欧洲无码视频|久久久一本精品99久久K精品66|欧美人与动牲交片免费播放
<dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><small id="yhprb"></small><dfn id="yhprb"></dfn><small id="yhprb"><delect id="yhprb"></delect></small><small id="yhprb"></small><small id="yhprb"></small> <delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"></dfn><dfn id="yhprb"></dfn><s id="yhprb"><noframes id="yhprb"><small id="yhprb"><dfn id="yhprb"></dfn></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><small id="yhprb"></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn> <small id="yhprb"></small><delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn>