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

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

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

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

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

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

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

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

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

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

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

所以， 假設(shè)系統(tǒng)中有2個CM是完全相同的， 比如EM01-CM02與EM02-CM03是完全相同的設(shè)備邏輯。那么按照面向?qū)ο蟮睦碚?，我們原本?yīng)該把它們的邏輯部分設(shè)計為一個類比如FB: CM-TYPEA，然后分別實(shí)例化為2個實(shí)例，分別對應(yīng)了使用的工位EM01-CM02與EM02-CM03。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這相當(dāng)有難度。

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

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

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

審核編輯：劉清