SIMATIC CPG(消費品包裝)模板提供了一個基于模塊化設計(ISA-S88 Make2Pack)的清晰和經過測試的項目結構。機器制造商得到了一個易于診斷和易于擴展的項目基礎。終端客戶得到一個統一的機器行為(OMAC PackML)和一個標準化的接口(PackTags)，可以輕松地進行線集成。

最先進的包裝機器和生產線是極其通用的，必須提供最高程度的靈活性的高吞吐量率。降低總擁有成本和投資安全也是關鍵問題。大終端客戶希望來自不同供應商的機器具有相同的可用性和診斷功能。此外，必須保證從上層系統對機器數據的標準化訪問能夠分析產品流程，獲取機器運行時間或計算性能數據。實現這些目標的關鍵是采用國際標準。

這個應用程序模板，稱為SIMATIC CPG模板，可以作為實現OMAC PackML兼容項目的基礎，并為您提供具有明確定義的接口的測試代碼，包括一個HMI模板。

SIMATIC CPG模板結合了用于模式和狀態管理的PackML指南和標準接口(PackTags)，以及sa - s88 Make2Pack模塊化概念和集成的報警概念，為您的OMAC兼容項目提供了一個隨時可用的解決方案。

上面的文字和圖片，我是直接從公眾號《屯蒙閑談》的文章《西門子案例推薦——SIMATIC CPG Template》搬過來的。當然， 他也只是對官方文檔的簡單翻譯，并沒有個性的解讀。所以整體看起來相當規范整齊，也顯得很有模板的范兒。

然而當我們真正拿到這個模板，打開程序來閱讀的時候，卻根本不是那回事了。 或者可以說，跟想象的完全不一樣。

我為了學習理解PACKML， 拿這套資料學習了很久了。也組織了專門的學習群，大家一起探討。然而花費了很長的時間， 仍然暈頭轉向，一頭霧水。相信所有初學PACKML的同行也都和我一樣。我們的學習群里的同行，大多數人的認知也是如此。

這套程序， 如果不冠以模板的名號，任何人拿在手里看來，也就是個普通的自動化工程師為了完成項目任務，所完成的一套控制程序。方法極為普通， 架構也極為普通。并看不到有任何先進之處。

而且，程序也毫無模塊化和封裝性可言。程序中大量使用全局DB塊，所有程序都是在對這些數據塊的訪問中實現。由此也無法實現模塊化。其中的大量模塊，雖然以FB的形式建立，但那些FB都是只使用一次的，并不能被重復調用，甚至這些FB連參數管腳都沒有。就是一個光禿禿的FB調用一次而已。

比如按照ISA88架構所劃分的模塊單元，UN, EM00,EM01,EM02, 以及EM00-CM01, EM00-CM02,EM01-CM01, EM02-CM02, EM02-CM03, 這些所有的模塊都一一對應一個FB，因為每個模塊中需要對應訪問各自模塊對接的數據。比如：

EM01-CM02，這個單元，需要對接的數據有EM01和UN以及全局數據PACKTAG, HMIDATA, PACKML , RECIPE, ALARM以及配置文件各種以cfg標識的DB塊等。

所以， 假設系統中有2個CM是完全相同的， 比如EM01-CM02與EM02-CM03是完全相同的設備邏輯。那么按照面向對象的理論，我們原本應該把它們的邏輯部分設計為一個類比如FB: CM-TYPEA，然后分別實例化為2個實例，分別對應了使用的工位EM01-CM02與EM02-CM03。

然而實際中并不是這樣。由于邏輯中訪問的除了自身設備產生的數據以外，還訪問了全局數據的與各自工位對應的數據工位，與各自類型對應的配置類型的數據值，其中也包含工位信息,工位代號是數據路徑的一部分。

所以，最終，每一個程序模塊的邏輯語法雖然看起來相同，但由于數據的地址千變萬化，就根本做不到封裝，而是只能各自單獨的FB了。以致于我在學習一些視頻講座的時候，有人講到實例化， 實例化的結果竟然是多個FB， 就是所謂的面向對象的實例了。這樣的對面向對象的認知， 太讓我驚掉下巴了。嘿嘿嘿。

我在入手這個程序之后，連續讀了好幾天，都對這一處理不能理解。主要還是對PACKML本身實現的功能和目的不太了解。所以就不免暈頭轉向。跟人探討，也沒有有用的收獲。

直到有一天，慢慢對PACKML的數據結構有些比較深刻的認知后，發現， CPG這個例子，其實它不是在面向對象編程，甚至也不是傳統上的面向工藝編程，而是在面向數據編程！這是我給它做出總結后所獨創的一個詞匯。

PACKML的核心在于設備數據的統一管理，一個系統UN中，有若干個設備EM以及子設備CM， 需要在設備運行過程中對各自的狀態進行收集，指令進行分發傳遞， 報警狀態記錄，以及給定參數的分發，配方管理， 設備運行數據分析OEE等等。

所以，相比較于普通的PLC設備控制程序， PACKML的重頭戲在于這些數據管理的實現方式。而這些數據的規模，比起傳統PLC控制的零星的控制字、狀態字、給定值、運行值等多出來N多倍，甚至，整個CPG程序中，其實只是做了這些數據的處理工作，具體的設備怎么動起來，還完全沒有顧得上涉及。

當然， 這對PLC生產廠家來說是好事。原本一個邏輯，幾K的內存就能完成的控制任務，現在當套上PACKML規范之后，可能就要動輒過M的內存的控制器才能實現了。同樣的設備的控制，可以賣給他更貴的PLC了。

這對PLC工程師也是好事。原本你在PLC程序中只簡單做做起保停，讓電機伺服跑起來，做下數據格式轉換，運行數據顯示，就能完成設備的設計。在電工們看來，這點工作著實簡單，他們也一樣能做到。所以他們覺得完全可以與你是平起平坐的。而在工廠同事和領導看來，你做的事和電工也確實沒多大差別，所以也確實不該比他們的工資高出來好幾倍。

CPG模板的實現過程中，由于以數據為核心， 倒是針對每個模塊嚴格的對應設計了數據，如文章開始的圖片示意，其實每一個六邊形對應的都是一個數據區。然而為了實現對這些數據的管理，所設計的程序塊就只好圍繞著這些數據穿針引線，眼花繚亂。體現在每一個全局數據塊， 被每一個FB/FC塊隨意使用，按需訪問，毫無規律可言。

看到穿針引線的字眼，有沒有想到我有寫過的一篇文章《【萬泉河】PLC程序中的面條代碼》？這些針線和面條代碼什么區別？其實就是面條，一模一樣！

所以，在實現面向數據編程的同時，代價便是通篇程序都是面條代碼，垃圾程序。

我在嘗試將CPG中的這些UN, EM ,CM的模塊進行封裝，以達到程序可以重復使用的模塊化，甚至，我期望的終極目標是，將PACKML的相關功能實現完全封裝，任何一套傳統設計的設備，比如一個完全不懂得PACKML機制原理的工程師設計的設備程序，比如一臺注膠機，或者桁架設備等。現在設備要賣給新興行業，對方的行業規范需要設備提供標準的PACKML接口， 那么只需要加裝一套完全封裝好的庫模板，就可以實現了。

然而目前的CPG模板， 還遠遠不能實現。除了這些程序代碼全部不能復用之外，甚至作為設計核心的數據，也并不是復制過來就能直接使用的。畢竟每一套設備，工藝架構均不同，那么UN/EM/CM的數量也全部各不相同。比如它原始設計的EM01中原本有3個CM， CM01,CM02，CM03，而我們的新設備有6個CM的話，數據結構也需要重新規劃增加CM04, CM05,CM06。當然， 配置文件， 配方文件， 報警數據，全局數據等相關的部分也全部需要再次規劃管理。再加上原本的程序代碼也大都不能復用的，所以基本上來說參考這套CPG模板的結果就是要你消化理解之后，完全從頭另起爐灶。

每個人都要從頭造輪子，絲毫沒有經驗的總結和技術的傳承，這就完全偏離了技術發展的正常軌道了。絕不是我們技術工作所要的樣子。

我們來嘗試對每一個EM/CM做獨立封裝，其模塊的自身數據當然可以作為管腳參數來輸入。但對于配置數據和全局數據，就不適合再用管腳來傳遞數據了。會導致模塊的管腳數量多到天量，模塊調用時難度太高，即違背了低耦合的原理。所以必須在模塊內部實現對全局數據和公用數據的管理。

可以參考高級語言編程中的對注冊表和數據庫的訪問的實現方式。每一個函數功能模塊，在需要的時候，各自分頭對注冊表的對應位置讀取數據，也將模塊產生的數據送到數據庫中。其實PACKML的眾多全局數據塊，起到的就是數據庫的功能。而CFG配置相關的數據塊， 起到的則相當于注冊表的作用。

那么對這些數據的有規律的進行訪問，就成了一個問題。比如同一類數據，在EM00中會是：GLV.EM00.STS， 而對EM01則對應為GLV.EM01.STS。程序塊要想實現邏輯統一，就需要對這個包含有EMxx 的路徑實現動態編程，即在程序邏輯內自動適應地址的變化。

然而對于PLC編程來說，其本質上是基于絕對地址的，EM00, EM01本質上只是符號。即便是PORTAL中實現了符號編程，但要對符號地址再進行動態變化，其實是針對符號的指針的編程。

這相當有難度。

有興趣的讀者可以嘗試找到實現的方法。

把需求歸納一下：做一個FB，一個字符串類型的輸入管腳EM， 一個int輸出OUT。2次調用，當EM=’EM00’ 時，從數據塊GLV.EM00.DATA1中讀取數據送到OUT，而當EM01時則從GLV.EM01.DATA1讀取。數據塊GLV中EM是一個結構體，除了DATA1之外，還有許多其它的值。這里只讀取一個，實現了當然也可以同樣方法處理其它的數值。

不許在FB塊內做枚舉，即不許用CASE語句把可能的EM00，01，02…..的代號全部囊括，因為這些代號其實是設備的名字，并沒有規律可言。而因為模塊要實現復用，做好了之后是需要封裝的。封裝之后密碼保護，就再也不許打開修改了。

審核編輯：劉清