1026 【萬泉河】優雅到極致的MODBUS庫函數計劃
在工控行業，無論使用哪一個品牌平臺的PLC， MODBUS都是其中最重頭的通訊協議。 而因為MODBUS通訊協議性質本身，實現通訊有一定的難度。 而且每做一個新項目，通訊程序都還要重新再調試一遍，所以比較頭疼。 這是因為MODBUS的輪尋機制是必須在程序中編程實現。
比如一個COM端口， 一條485總線上面掛了N個MODBUS設備， 那么就需要做循環，對每個設備的每個數據區輪番做READ或者WRITE查詢。而如果設備的類型不同， 還需要每個單獨處理數據區和數據。
這一點在自動化項目時非常令人頭疼。 所以，大家伙在入門之后，就不滿足于僅僅能實現通訊功能了， 紛紛摸索實現模塊化的方法，以期實現MODBUS通訊的優雅實現。
然而，最優雅的MODBUS通訊見過沒？
最理想的優雅到極致的模塊化的實現方式應該是：
比如485網絡上有一臺MODBUS通訊的DANFOSS變頻器，那么只需要一個完全定制封裝好的FB庫函數：
拖到OB1程序來，管腳參數中標明這臺變頻器的MODBUS地址，然后就可以實現以通信方式的控制了。
當然不是指一定要直接在OB1中，而是指在OB1架構下，只需要這一個模塊的一個調用。 除此之外所有類似于初始化，通訊握手等的指令，一概不需要做了。 因為全部在這一個模塊內部實現了。
而如果有多個站，也只不過是再拖入調用多個實例。
而如果485總線上有多個類型的站點， 那么通過設計不同設備類型的FB， 也是同樣拖入，即可實現通訊功能。
這是在面向對象架構，把設備全部都作為對象處理的情況下。 本人專著《PLC標準化編程原理與方法》中P149頁開始的2個節有介紹過。
書中介紹的變頻器是ABB，而本文中發的是DANFOSS。即，其實我們在后期隨著工程應用的需要，已經把這2個品牌型號的變頻器的通訊控制都做成了庫函數。
而在非面向對象的架構下， 比如文章《0905 【萬泉河】80模擬量例子程序升級版V2.0》中介紹的使用MODBUS通訊的遠程IO， 則可以使用低一層的封裝塊：
其中數據區BUFF，指向了一個定義好的全局數據塊：
這樣數據塊中的數組內的數值4X[1]就直接代表了此站點模塊的40001通道的數值，就可以直接在程序中使用了。
注意看到上面的FB的管腳都有一個SUBNET， 含義是如果1個PLC系統內有多條485的總線，也是可以的。 比如需要通信的站點比較多，在一個總線上面輪詢的周期太長， 數據刷新不夠快的情況下，可以通過增加PTP模塊或者MODBUS TCP轉RTU網關的方式，增加到多條總線。
而在設備的參數部分，只需要輸入總線編號和站地址，就可以區分了。
前面的介紹沒有區分MODBUS RTU和TCP， 其實這兩者都是需要輪詢的。 即便是TCP，理論上講可以使用多個端口同時通訊，但在實際操作中，PLC系統分配給TCP通訊的通訊資源是有限制的。 如果要同時通訊， 一個站點的讀和寫就要分別占用了2個端口，資源會快速耗盡。
而在MODBUS TCP的協議定義中，也仍然有站地址的標記，我們現在知道了，是為了TCP/RTU的網關設計的，即當使用網關把485總線轉換為以太網之后，報文中仍然需要有站地址的區分， 以實現一整條485總線上的所有從站的數據，都可以有區分地被主站讀取。
我們設計的SUBNET網絡的定義，在100以下為RTU，而100以上為TCP，由此實現了通用兼容。
這些功能，在書中只是做了介紹，但并沒有直接講解實現的代碼。 因為這些是屬于底層的搭建庫的需要，書中只是介紹方法，具體的設計工作仍然需要工程師各自實現。
甚至對煙臺方法的學員，這部分的庫和代碼也并沒有提供。 煙臺方法提供的只是思想架構方法，并不提供程序代碼，更不承擔代碼正確的責任。 這是煙臺方法和市面上的制作庫函數售賣或者分享的一些個人不同。因為做的是完全不同的事情。
甚至， 我也鼓勵一些學員可以嘗試使用各種各樣的現成的庫函數來做自己公司的標準化項目。那些庫函數，在標準化煙臺方法的眼里，都是基石，可以選擇用來蓋房子的磚頭。 而煙臺方法是幫助工程師搭建房子的順序方法，每個公司各自的企業標準就是所謂的房子。
那么，這套MODBUS的庫函數，本質上也是磚頭。 是用來實現標準化的模塊。當然是有相關功能需求的公司才需要，而沒有用到MODBUS的公司則不需要。
這套庫函數，我已經開發完成將近三年了。 而三年中，我們自己的項目在不斷使用，并打磨，逐漸升級完善。 而對外，則只是一小段時間內做過小范圍的出售。 大部分時間里則是雪藏的。并沒有過多宣傳，也沒有推廣。
最近，有學員和網友來咨詢在西門子之外的PLC平臺實現的方法，加上我自己正在編著《三菱PLC標準化編程煙臺方法》的專著，對MODBUS部分庫的欠缺，也有些焦慮。
所以，有計劃把這套庫函數再次拿出來，以低成本的方式分享給同行。
分享的目的主要是為了擴展。通過擴展，建立一個比較龐大齊全的生態社區。
擴展分兩個維度。
首先是設備的類型，比如支持MODBUS的各種現場設備如變頻器，儀表等等，都需要封裝成專用的庫函數。做好了之后需要的時候， 從目錄中找到對應型號的庫函數，直接拖入使用即可。
這部分的技術難度比較小。 比如從ABB變頻器到DANFOSS變頻器，只不過是各自的參數地址不同， 控制字和狀態字的定義不同，制作時只需要照貓畫虎，在原有的庫函數基礎上改一改，參數部分改好了， 經過實際應用檢驗通過了，就可以反饋加入到列表中，這樣再有人需要的時候，就可以直接使用了。而不需要再去翻手冊找參數，調試實驗通訊。
另一個維度的擴展是不同的PLC品牌和型號，這部分的難度比較大。 我目前已經做了2個系列，分別是SIEMENS S7-1200/1500和S7-200 SMART。 而其它的品牌的PLC， 我雖然大都已經開發了標準化方法，但MODBUS通訊部分， 目前基本空白。 甚至，大部分品牌的基本的MODBUS 通信我都不會，因為沒做過。
當然，主要還是我個人目前為止，這兩個維度上的需求都沒有。 而要擴展到那么多的自動化產品廠家，工作量也是巨大的。
所以，希望的是群策群力，大家一同貢獻， 一同分享的模式。 所有有能力有興趣的同行一起來做這件事，大家一起貢獻，同時又可以都有回報。
這就需要一個比較完善的分享和貢獻回饋機制，而不是簡單一個免費分享能做到的。
具體的分享方法，會在近期整理推出，當然也不會一次性固化，先搞一個基本的架構做起來，以后再持續完善。
在此期間， 也歡迎同行給我私信提供寶貴建議。
我預期的是，將來實現MODBUS通訊的人工調試成本大幅度降低。 比如有人要做某個PLC與某個設備的MODBUS通訊，只需要來我們這里翻一翻庫里的目錄，選擇好，拿去直接使用，一次性使用費用在幾十元以內，如果有多個類型的設備，加起來也不過幾百元。 比起個人摳摳搜搜搭臺子做實驗，要簡便和高效地多。 尤其不需要個人獨立面對通訊失敗的糟糕局面了。 購買之后，有相應的開發者在后臺輔助服務。
我在剛開始做這套庫函數的開發的時候，寫過文章《【萬泉河】MODBUS并行通訊實現》
https://mp.weixin.qq.com/s/PZX-E3PKicYADcA_yzNlIg然后就有看不懂的杠子手來杠我不懂常識， MODBUS跑的物理介質都是485總線是串行的， 并不能并行，指責我怎么可以并行通訊。
廢話， 如果它天生支持并行，就沒我什么事了。 恰恰因為他底層是串行，我們才可以通過自己的努力，在應用層面實現一個貌似的并行，哪怕是偽并行，也是我們能做到的貢獻。
那么，我們以后就為這套庫機制專門起個名字，就叫優雅MODBUS庫好了。 翻譯到英文，我稱其為Grace Modbus Library ，簡稱GML。優雅庫為優雅煙臺方法服務，也可以為未使用煙臺方法的同行服務。
有老外做過一個開源的REXHIP項目，我研究過也分享過。 但我對他的實現方法不滿意。 認為比我現在做到的優雅程度還差許多。所以不贊成加入他們的開源貢獻計劃， 而是搞一套我們中國人自己的庫。
滬公網安備31010802001143號
