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

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

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

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

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

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

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

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

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

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

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

所以， 假設系統(tǒng)中有2個CM是完全相同的， 比如EM01-CM02與EM02-CM03是完全相同的設備邏輯。那么按照面向?qū)ο蟮睦碚摚覀冊緫摪阉鼈兊倪壿嫴糠衷O計為一個類比如FB: CM-TYPEA，然后分別實例化為2個實例，分別對應了使用的工位EM01-CM02與EM02-CM03。

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

所以，最終，每一個程序模塊的邏輯語法雖然看起來相同，但由于數(shù)據(jù)的地址千變?nèi)f化，就根本做不到封裝，而是只能各自單獨的FB了。以致于我在學習一些視頻講座的時候，有人講到實例化， 實例化的結(jié)果竟然是多個FB， 就是所謂的面向?qū)ο蟮膶嵗恕＿@樣的對面向?qū)ο蟮恼J知， 太讓我驚掉下巴了。嘿嘿嘿。

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

直到有一天，慢慢對PACKML的數(shù)據(jù)結(jié)構(gòu)有些比較深刻的認知后，發(fā)現(xiàn)， CPG這個例子，其實它不是在面向?qū)ο?a href="http://www.nxhydt.com/v/tag/1315/" target="_blank">編程，甚至也不是傳統(tǒng)上的面向工藝編程，而是在面向數(shù)據(jù)編程！這是我給它做出總結(jié)后所獨創(chuàng)的一個詞匯。

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

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

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

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

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

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

所以，在實現(xiàn)面向數(shù)據(jù)編程的同時，代價便是通篇程序都是面條代碼，垃圾程序。

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

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

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

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

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

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

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

這相當有難度。

有興趣的讀者可以嘗試找到實現(xiàn)的方法。

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

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

審核編輯：劉清