Multi-Masters issue
上一篇提到的 Single Master/Multi-Slaves 通訊模式,有一個明顯的缺點就是只能有一個 Master。這對很多應用來說就很不方便,例如控制設備可能有一個房間那麼大,我們想要在不同的位置做監控,甚至是我們想在不同的樓層或建築觀察設備的運作情形。
碰到這些需求,Single Master/Multi-Slaves 這種模式就很難用了。以筆者所知,解決方法有三種:
- Protocol Gateway(如前篇提到的 Modbus Gateway)
- Master 使用與 Slave 通訊外的通訊埠串接
- 由通訊協議本身支援
2. 在 HMI 上通常稱為 Multi-link(如下圖所示),利用與 Slave 通訊之外的通訊埠串接其他 HMI,不過通常 HMI 與 HMI 間使用該 HMI 的專屬通訊協議,一方面是為了效率,另一方面當然是為了綁住客人。不過筆者當初偷懶實作成開放式 Modbus RTU/TCP,反而意外拉到一些客人。
3. 就是本文要探討的重點,也就是不再需要 Protocol Gateway、HMI Multi-link 這些外部硬體支援,改由 protocol 本身加以突破。這些 protocol 可以粗分為兩種工作模型:
- Multi-Masters/Single-Slave
- Multi-Masters/Multi-Slaves
Multi-Masters/Single-Slave
在 PLC 領域,最廣為人知的大概就是 Simatic S7-300/400/ET-200s MPI 了,MPI 是 Multiple Point Interface 的縮寫,這個 Protocol 有個很有名的親戚 Profibus,不信的話把封包錄下來,您會發現 SD1, SD2, SD4 這些格式如出一轍(不懂沒關係,非本文重點)。
RS485 topology 如下:
重點來了,按照前篇 Modbus 那種 working model,肯定 Master 之間的封包會碰撞打架。這裡 MPI 引入 token 的概念,token 就是一個令牌、一柄權杖,握有這個 token 的 Master 才有資格跟 Slave(PLC) 通訊。
首先(步驟1)可以肯定的是,PLC power on 時沒有任何 Master 持有 token。PLC 內部維護的列表也會把除了自己(Addr:2)外的其他 address 通通標示為 offline。MPI 網路最多允許 32 個節點,有經驗的讀者也許會發現,一般市面上容易購得的 RS485 transceiver 允許的最大節點剛好也是 32。
接著(步驟2),PLC 主動發出 RS485 封包,探測網路上是否有其他節點存在,這些節點(如上圖中的 HMI)一旦收到這些探測封包,而其中的 DA(Destination Address)又是指向自己時,就要趕緊做出回應,取得 token,然後對 PLC 進行 I/O。
做完 I/O 後,Master 的責任有 2(步驟3):
不過各家生產的 MS/TP Master 不可能剛好開機時間都一樣,上圖是一種理想化的模型,現實中還是存在一定碰撞的機率,不過這點可以提供開機延遲設定克服(過去筆者開發 HMI 時也提供類似的功能)。
另外一個困難,恐怕也是最大的困難,就是這些 protocol 很難跟 Modbus 一樣,光看 spec 就寫出正確的程式(事實上連 Modbus 都寫不好的產品也一大堆)。不信的話,可以去下載 BACnet 專家、也是 BACnet 委員之一 Steve Karg 開發的 BACnet Stack 回來看看自己有沒有辦法寫到人家這種程度。如果這麼容易的話他的 BACnet 顧問工作恐怕也要沒生意了。
台大物理高湧泉教授在科學人 No.192 現象學家一文中提到:
...自牛頓以來,物理學的發展緊貼著現象,不輕易臆測經驗之外的東西。牛頓自己就說過:「我不做假設。」畢竟自然的奧秘很難光憑猜想加上邏輯推演就可以破解。
所以,啃 spec 不搭配「現象」一起觀察研究,肯定是事倍功半,所以 Steve Karg 寫了可以錄製 MS/TP 封包的軟體、讓錄下的封包可以用 Wireshark 觀察。odva(EtherNet/IP 官方機構)在 EtherNet/IP Quick Start for Vendors Handbook(這裡 EtherNet/IP 中的 IP 指的是 Industrial Protocol)裡也建議開發 EtherNet/IP 產品的公司最好也買一台 EtherNet/IP scanner/adapter 以供參考研究。
甚至如果有 open source 可以參考,那找來讀一讀也沒什麼可恥的,還可以加深對 spec 的理解,講難聽一點,就算你重新發明輪子搞不好也沒人家的圓。不過筆者到是碰過堅持只能從讀文件了解 spec 的仁兄(堅持到把 code 鎖起來,還好沒把 Google 也順便封鎖),如果我是委員會負責制定 spec 的委員,做文獻回顧、搞批判性思考那一套是真有必要(因為制定規格是創造新東西,而解讀 spec 不是),但台灣大多數公司接觸到這些 spec 往往都是這些 spec 已經問世 n 年了,相關產品、驗證工具、開發套件都早已 ready,做產品也不是搞理論研究(理論研究有門派之爭,spec 錯了也要照做),不用別人的智慧解決自己的問題,算是明智的作法嗎?(不禁讓筆者想起有人說過只用紙筆的研究才是真研究,用電腦模擬是邪門歪道)
ChamberPlus 老前輩曾經跟筆者提過他當年一把年紀學 MFC 是怎麼學的:「碰到瓶頸就趕緊抱著筆電衝到朋友那邊請教(而不是抱著深入淺出 MFC 啃兩遍)」,讓筆者深深感覺到「功夫好不如人緣好」,工程師的傲氣與堅持有時還是要放在一邊才是。
做完 I/O 後,Master 的責任有 2(步驟3):
- 探測其他節點
- 把 token 交出去(至少要交回給 PLC)
如下圖所示:
需要注意的是,當 Master#5 Pass Toke to PLC,PLC 取得 Token 還是會在固定的週期內繼續偵測有無其他節點存在。
不過,這個工作模式似乎與 Single Master/Multi-Slaves 比起來沒有多少創新(感覺就只是倒過來),還變得更複雜?接下來我們來看把 RS485 玩到極限的 Multi-Masters/Multi-Slaves。
Multi-Masters/Multi-Slaves
筆者才疏學淺,這方面只聽過一種 protocol,就是 BACnet MS/TP,BACnet 是 Building Automation and Control (BAC) networks 的縮寫,顧名思義就是用在建築自動化,例如燈光控制,冷凍空調,門禁管理,電梯...
BACnet 由 ASHRAE(美國採暖、製冷與空調工程師學會)制定,他支援很多種 physical layer,其中一種就是 RS485,而用於 RS485 上的 BACnet 就稱為 BACnet MS/TP。
MS/TP 是 Master Slave / Token Passing 的縮寫(您看看 token 又出來了)。與 MPI 不同的地方在於:
- 只有 Master 才能持有 token
- Slave 不能持有 token,只能被動回應 Master 發出的 request(行為如同 Modbus RTU/ASCII slave)
- token 由 Master 產生
看完以上三點應該會存疑,既然是 Multi-Masters,那哪一個 token 負責產生 token?會不會多個 Master 同時產生 token 結果打架呢?
首先,BACnet MS/TP Master 產生 token 的原則是:一開始上電時,會假設 MS/TP 網路上已經有其他節點存在,如果網路上沒有封包活動發生 timeout,才會產生 token。如果有封包活動,則會等待其他 Master 把 token 交給自己。
問題來了,如果數個 Master 同時開機,顯然網路上沒有封包活動,那會不會一起產生 token 來個大塞車?BACnet MS/TP 用了一個巧妙的辦法,就是依據站號的大小,決定 timeout 的時間長短,站號越小 timeout 時間越短,這樣即使數台 Master 同時開機,由於站號較小的會提早 timeout,於是先產生 token。而其他站號較大的 Master 因為 timeout 時間較長,在 timeout 前就感知道網路上有封包活動,也就不會主動產生 token 發生碰撞了。如下圖所示:
實作上的困難
無論是 MPI 還是 BACnet MS/TP,他們共同的特點就是都對 Rx timeout,或是 Tx Delay 做了精準的定義。所以你需要精準的 timer:
- MPI: 微秒(us)級 timer,幾乎只有 hardware timer 才能做到
- BACnet MS/TP: 毫秒(ms)級 timer,通過某些技巧,或是 OS 本身有能力提供毫秒等級 timer 也可以做到。
- 最好採用 RTOS,把 communication task 設定為 high priority,一旦發生 timeout,communication task 就會立刻取得控制權。
(BACnet MS/TP Timing 示意圖,取材自 http://kargs.net/BACnet/BACnet_MSTP.pdf)
以筆者的經驗,MPI 如果是 Linux 就只能在 Kernel mode 實現了,而且 MPI的 baudrate 超過 115200bps 到達了 187500bps(最近更到達了 1 mega bps),user mode app 根本難以在規定的時間內反應。他的親戚 Profibus 更是到達了 12Mbit/sec,基本上就只能靠 ASIC 了,連軟體都很難實作。
BACnet MS/TP 比較簡單,他的 baudrate 官方定義最高到 57600bps,一些廠商作到 115200bps(不像 MPI 187500bps,可能硬體沒辦法提供這種 baudrate),可以忍受 5ms 左右的誤差。
重點就是要有 deterministic 的概念,換句話說,因為 RS485 不像 SPI , I2C 有帶 clock,所以他必須用別的方法模擬出類似的效果。看到這裡,各位會不會秒懂為何要用 Real-Time OS 了?
重點就是要有 deterministic 的概念,換句話說,因為 RS485 不像 SPI , I2C 有帶 clock,所以他必須用別的方法模擬出類似的效果。看到這裡,各位會不會秒懂為何要用 Real-Time OS 了?
另外一個困難,恐怕也是最大的困難,就是這些 protocol 很難跟 Modbus 一樣,光看 spec 就寫出正確的程式(事實上連 Modbus 都寫不好的產品也一大堆)。不信的話,可以去下載 BACnet 專家、也是 BACnet 委員之一 Steve Karg 開發的 BACnet Stack 回來看看自己有沒有辦法寫到人家這種程度。如果這麼容易的話他的 BACnet 顧問工作恐怕也要沒生意了。
台大物理高湧泉教授在科學人 No.192 現象學家一文中提到:
...自牛頓以來,物理學的發展緊貼著現象,不輕易臆測經驗之外的東西。牛頓自己就說過:「我不做假設。」畢竟自然的奧秘很難光憑猜想加上邏輯推演就可以破解。
所以,啃 spec 不搭配「現象」一起觀察研究,肯定是事倍功半,所以 Steve Karg 寫了可以錄製 MS/TP 封包的軟體、讓錄下的封包可以用 Wireshark 觀察。odva(EtherNet/IP 官方機構)在 EtherNet/IP Quick Start for Vendors Handbook(這裡 EtherNet/IP 中的 IP 指的是 Industrial Protocol)裡也建議開發 EtherNet/IP 產品的公司最好也買一台 EtherNet/IP scanner/adapter 以供參考研究。
甚至如果有 open source 可以參考,那找來讀一讀也沒什麼可恥的,還可以加深對 spec 的理解,講難聽一點,就算你重新發明輪子搞不好也沒人家的圓。不過筆者到是碰過堅持只能從讀文件了解 spec 的仁兄(堅持到把 code 鎖起來,還好沒把 Google 也順便封鎖),如果我是委員會負責制定 spec 的委員,做文獻回顧、搞批判性思考那一套是真有必要(因為制定規格是創造新東西,而解讀 spec 不是),但台灣大多數公司接觸到這些 spec 往往都是這些 spec 已經問世 n 年了,相關產品、驗證工具、開發套件都早已 ready,做產品也不是搞理論研究(理論研究有門派之爭,spec 錯了也要照做),不用別人的智慧解決自己的問題,算是明智的作法嗎?(不禁讓筆者想起有人說過只用紙筆的研究才是真研究,用電腦模擬是邪門歪道)
ChamberPlus 老前輩曾經跟筆者提過他當年一把年紀學 MFC 是怎麼學的:「碰到瓶頸就趕緊抱著筆電衝到朋友那邊請教(而不是抱著深入淺出 MFC 啃兩遍)」,讓筆者深深感覺到「功夫好不如人緣好」,工程師的傲氣與堅持有時還是要放在一邊才是。
效能上的瓶頸
由上面的論述可以發現,不管是 MPI 還是 BACnet MS/TP 都會浪費一些頻寬在 pass token 或是偵測其他節點上,減緩這個問題(不是解決)有幾個共同的方法:
- 提高 baudrate,如 MPI 拉昇到 187.5kbps
- 將站號編排為連續,如 0,1,2,3...,減少浪費時間在偵測不存在的節點。
- 將最大站號變成可設定,如 MPI 或 BACnet MS/TP Master 都提供方法設定最大站號,如果網路上只有 5 站,將最大站號設定成 4 可以節約頻寬在偵測不存在的節點上。
- RS485 Tx/Rx 切換改用硬體,如 MAX13487
結論
寫到這裡不禁想起以前常常詛咒 RS485 最好早日被 Ethernet 消滅掉,搞得這麼複雜是要整死工程師嗎(光要講到 PM 聽懂就快死人了) ?可是想想有時最後一哩路還是得靠 RS485,尤其是裝置必須以 8bit/16bit MCU 實現的場合,看來這兩條線(D+/D-)還會長相左右好一陣子...-.-
「碰到瓶頸就趕緊抱著筆電衝到朋友那邊請教」當然也不能大哉問啊。
回覆刪除我都嘛事先自己整理一下問題,甚至把問題只收斂到只需人家點一下就可以了。
否則,再好的交情,給你玩大哉問幾次後,看還有誰會理你?
---
另外整篇文章,我看了頭又大。(TOYOTA?)
關於這一種牽涉到主從架構的通訊協定,我後來發現:CAN 真的比較好用,
難怪我那位搞馬達控制的電機博士同學只問我說:你搞不搞OpenCAN ?
已經有很多單晶片都支援CAN 了。如果我的話,我還是比較喜歡專注在
系統發展的價值,至於這些通訊協定,能簡單就簡單...不要把自己搞死了,
也沒有人會比較欣賞你。至少這是我的感想。
這點人情世故小弟還懂,小弟指的是已經抓破頭,火燒屁股...這時候就不用再撐了吧?
刪除看了頭大這很正常,文中的 MPI 在我離開某公司之後他們又改了 n 次,一直到這幾年聽說還是偶爾會出狀況。有次我私下請教一個很資深的同事(另外一間公司的事情),他說當年對 PM 做簡報(好像是 Profibus),也是第一次聽不懂,後來又加開了好幾場...您要我在一篇文章中就講到老嫗能解,這太為難小弟了(不過內行人應該看得出來我把一些關鍵的部份點出來了)
至於這些 protocol 這麼複雜,真的有必要花功夫嗎?小弟認為身處的位子不同,看事情的角度也會不同,如果我是電梯業者,這不是我的核心競爭力,有人做個 Modbus 轉 BACnet 模組,我一看價格合理就用了,幹麻花時間去研究?甚至說,我還可以外包,叫協力廠商簽 NDA 做個專屬轉換模組。其實以前就發生過類似的事,早些年不少門禁讀卡機都是走 RS232,可是要接入出勤系統的話沒網路就很麻煩,那最簡單的方式就是去買個 RS232 轉 Ethernet 嵌入式模組。
但如果今天我是要做這些模組、或者是 protocol gateway,精通這些看了就讓人頭大的 protocol 就是小弟的責任,您說是吧?
不好意思,更正一下:不是OpenCAN;而是 EtherCAN 。
刪除以前我有一陣子是搞DMX512 用的也是 RS485,用起來也沒啥問題。
刪除我記得我的模組還安裝在新北某一雙子星建案的LED 燈條控制。
只是以搞系統角度來看:門檻太低,你說的:隨便找個外包就把你取代了。後來還是賣燈條的水電業者保護著我的機會。
但還是覺得沒啥市場保障...就放棄了。
像以前小弟待的工控不少人也是靠交情跟關係吃飯,技術當然還是要有,但是有時沒那層交情連大門大跨不進去,這到底是好還是壞?
刪除小弟有接觸過的是 EtherCAT, 裡面包的是 CanOpen, 像下面這樣...
http://www.iebmedia.com/images/art_images/ieb31canopen-3.gif
後來前公司也發現這不是小公司玩得起的東西,RTOS算一次錢,EtherCAT stack 算一次錢,Motion 再算一次錢,還要上一堆課程 k 一堆 spec,最後就不了了之
"前公司也發現這不是小公司玩得起的東西..."
刪除然後呢?
所以很多公司只好關起門來自己玩自己的。最後又要找市場,結果
又發現很多規格跟別人不相容,結果又開始找一大堆工程師看能不能
從"逆向工程"搞定相容性..最後真的有省到錢嗎?或是市場Timing?
我真的看過太多不喜歡跟別人合作的工程師或專家了...最後都只是
搞死自己而已。
所以你就懂我所說的:工程師的"傲",就是造成公司進步的最大挑戰。
很多工程師也沒有想搞閉門造車這一套,但公司不肯給資源怎麼辦?然後又要工程師想辦法山寨,工程師也是很無奈的只好照辦,不然開始找新工作嗎?山寨的同時也只好順便催眠自己可以順便學新東西...
刪除之前設備器材還想辦法靠關係去借,相關書籍還是做功德自己掏腰包去買,花自己的假日休閒時間去k,我還有朋友自己掏腰包買筆電上班,傲的工程師恐怕還是少數,苦跟悲的更多吧,大部分人沒有傲的本錢的
哈~哈~
刪除真的一笑以置之。
尤其看到最後一段話,投入許多心血精力及金錢(?) 結果呢...
也無法為自己創造更好的機會,就好像爬山爬得要死,就差一個攻頂
而已。那到底是命?還是運?還是作繭自縛呢?
套句電玩老台詞:「時也,命也,運也,非我能所也」
刪除認真講,這種方式永遠也到不了山頂
電影聖母峰裡面有一個橋段,國外的專業登山隊覺得
台灣登山隊怎麼到了聖母峰連用冰爪的經驗都沒有就敢
來攻頂?
這些複雜的技術,已經不是說叫工程師去山寨碰運氣就能矇上的,就像孫子兵法講的:
夫未戰而廟算勝者,得算多也;未戰而廟算不勝者,得算少也。多算勝,少算不勝,而況無算乎!吾以此觀之,勝負見矣。
真正的行家在玩這場遊戲時,早就一開始就計算過玩這個要投多少資源,跑認證要花多少錢,spec改版時要怎麼因應,被退貨時要怎麼處理
相反的,還用搞游擊隊那套方式,真的到最後就是大家窮忙一場
作者已經移除這則留言。
刪除哈~哈~
刪除真的一笑以置之。
尤其看到最後一段話,投入許多心血精力及金錢(?) 結果呢...
也無法為自己創造更好的機會,就好像爬山爬得要死,就差一個攻頂
而已。那到底是命?還是運?還是作繭自縛呢?
========================================================
看到以上留言真的只能搖頭。認真說,
有CANopen,沒有OpenCAN...
有EtherCAT、EthersCAN,就是沒有EtherCAN...
就現實層面來說,
職場嘴砲往往能為自己創造更好的機會,
相信ChamberPlus Taiwan必然是箇中翹楚。
作者已經移除這則留言。
回覆刪除作者已經移除這則留言。
回覆刪除作者已經移除這則留言。
刪除作者已經移除這則留言。
回覆刪除