上個月剛接觸西門子OMAC的PACLML示例,，我試著做了個程序來驗證,，效果不錯。

先來說說示例的觀感,，個人認為這僅僅是西門子為了實現(xiàn)模式狀態(tài)機的一個小示例,，不算可以直接使用的東西，當然離庫很遠,。示例設計得沒有什么章法,，僅僅實現(xiàn)了而已,，設計細節(jié)沒有多少值得借鑒得地方。

大的用處是讓我了解了什么是模式狀態(tài)機,，當然了,，肯定也只是PACKML的一部分內(nèi)容。我不了解PACLML,，只是從一些資料知道PACKML其實是涵蓋了整個項目結(jié)構(gòu)的內(nèi)容,，不光是模式狀態(tài)機了。

以前也做過狀態(tài)機,，使用Case對不同狀態(tài)進行處理和轉(zhuǎn)移,。大問題是入口case比較難以把握，稍不留神就會錯誤觸發(fā),。狀態(tài)的轉(zhuǎn)移也完全依賴現(xiàn)有狀態(tài)里面的判斷,。具體如何不便不好描述。

說示例沒有多少借鑒的地方其實有點昧良心了,，給我大的啟示是狀態(tài)轉(zhuǎn)移和狀態(tài)處理是分離的,。也許復雜的部分是狀態(tài)的收集和處理，示例沒有這方面的內(nèi)容,。我本人項目中也沒有做專門的工作,，只是使用了原有底層模塊的狀態(tài)簡單處理。

容易實現(xiàn)的是狀態(tài)轉(zhuǎn)移了,，我就做了容易的部分,。

并且實現(xiàn)后發(fā)現(xiàn)其實是完全可以適用于很多離散行業(yè)場景的。這里記住,，PACKML是包裝行業(yè)的規(guī)范,，它定義的狀態(tài)并不適用于其他行業(yè)。其他行業(yè)有各自的狀態(tài)定義,，這個自己來,。

示例對于狀態(tài)的記錄采用字符串，包括命令,、SC,，這個我覺得使用數(shù)值更好，占用空間少,，易于編程,。

至于診斷信息則用于調(diào)試過程，我把診斷和狀態(tài)轉(zhuǎn)移塊分離了,，需要診斷信息可以用單獨的塊接住狀態(tài)機傳出的診斷信息即可,，多少條任意。但狀態(tài)機只傳出當前的信息,，并不保存之前的信息,，并且都是編碼信息,，需要診斷塊自行解碼。

當調(diào)試好后,，診斷塊都可以在項目中刪除不用,。

先記到這，有時間再寫具體實現(xiàn),。

------------------------------------------------------

2024.01.23

本來已經(jīng)意興闌珊了,，可偏偏是個精，都還沒開始呢,。

好吧,，只能繼續(xù)了。

資料里面大量篇幅關(guān)于高層設備如何劃分之類的,，看看就可以了,。有機會從整體來設計當然不一樣了，但很多時候我們都只是一個螺絲釘,，并不注重整體架構(gòu),。有時是形勢逼人，有時覺得自己可以整體把控了,，無奈這個整體又太過渺小。

只記得資料里有句話很有意思,，大意是如果你不能正確劃分設備編號的話,，那就從底層開始編號吧，而不是一開始就從高層來,。對,，正解。

放張圖：

這是西門子1847里面的截圖,，當然我沒有1847,，而是從壺琰棠發(fā)布的視頻解的圖。

具體我就不分析了,，只看我的

1,、有一個全集，包括了所有的狀態(tài),。

2,、全集不一定非得有一個模式對應，可能有也可能沒有,。

3,、模式1向模式2轉(zhuǎn)移需要的條件：模式2里面存在當前模式1的當前狀態(tài)A.

4、狀態(tài)是有等級的,，L05,、命令和SC其實沒有區(qū)別,，我一律稱作SC。資料里面SC叫做狀態(tài)完成state complete,，我叫做狀態(tài)改變

state change.

6,、......

如何設計：

仔細觀察Excute狀態(tài)：

1、有三個出口,、三個入口,。

2、如果用鏈表表示,，則入口可以不用關(guān)心,，只需要出口。博途不支持鏈表（指針......）,，改用數(shù)組,，一樣的道理。

3,、數(shù)組的單元是個結(jié)構(gòu)：狀態(tài)本體,、出口。

4,、狀態(tài)是個整數(shù),，表示狀態(tài)標識，出口也是個整數(shù)（后來改用word),。

看級別,，把級別也看做狀態(tài)，則和普通狀態(tài)沒有區(qū)別,。

只是級別做成單獨的數(shù)組,，單元類型和普通狀態(tài)是同一個類型。

如果這樣,，如何表示從一個級別的狀態(tài)轉(zhuǎn)移到另一個級別的狀態(tài)呢,？

后來設計成處理出口SC編碼，做成Word類型,，高字節(jié)表示級別,，低字節(jié)表示SC標識。

范圍是不是夠呢,？一個字節(jié)表示256種狀態(tài),，應該夠了吧。特別是級別,。

預定義四個出口夠了吧,？做成符號常量不是更方便些。這樣,，模式數(shù)量,、狀態(tài)數(shù)量,、級別數(shù)量、SC數(shù)量等等都如此定義,。

這樣,，答題設計就有了，總體上變成了填表了,。

邏輯設計很簡單,，不需要多少代碼。

工作量大的是診斷工作,。

如何定義呢,？我也是邊實現(xiàn)邊定義，沒有事先定義?，F(xiàn)在還沒有機會整理診斷編碼,。

有一點是肯定的，就是診斷大多是給調(diào)試使用,，給人看的,，大量的文本占用空間，就不集成在模式狀態(tài)機里面了,，模式狀態(tài)機僅輸出診斷信息,，只當前診斷，不存之前的信息,。

如果需要就用單獨的塊接住往診斷緩沖區(qū)放,。

工作流程就是畫出狀態(tài)圖：不同模式的狀態(tài)圖，模式少的話就用一張圖,。填數(shù)字，填表,。需要把SC編碼變成16進制碼,，借助Excel來做容易些。

放張我設計過程中的截圖,，上面的SC編碼沒有級別編碼,，需要轉(zhuǎn)換。

配置表：

1,、診斷文本列表,，可以在PLC，也可以在HMI中處理,，隨便,，其實調(diào)試后可以不用。

2,、模式狀態(tài)機配置表

3,、狀態(tài)或級別配置表內(nèi)容：

上圖以級別表為例,，狀態(tài)表類似。

當處于某個狀態(tài)時,，需要和配置表中SCCode一致的SC才能使狀態(tài)發(fā)生轉(zhuǎn)移,，不符合則會被拒絕。

邏輯處理部分,，初始化檢查表內(nèi)容是否適合,，我只設計了檢查SCCode和Next是否配套，接著生成模式Pattern,，也即各個模式下存在全集狀態(tài)的一個記錄,，是個位域，DWord,。對了,，我都忘了我設計的項目狀態(tài)超過32個了，這個咋整,？

初始化后根據(jù)傳入的SCCode先在級別表里面檢查是否有合適當前級別的SC,，從別開始到當前級別終止檢查。如果有則直接轉(zhuǎn)入Next狀態(tài),，沒有則繼續(xù)在當前State里面檢查,。

都沒有則拒絕執(zhí)行轉(zhuǎn)移。

代碼簡單就不放了,。

現(xiàn)在的重點是如何設計好的狀態(tài)收集,、如何處理才能使SCCode不會被錯誤覆蓋造成狀態(tài)不能轉(zhuǎn)移。

------------------------

后記：

如果一個項目里有多個狀態(tài)機,，使用全局UDT和全局常量就不合適了,。比如說一個狀態(tài)機比較小，就需要和大的狀態(tài)機一樣大的配置表,，比較占空間,。

我的做法是把狀態(tài)機集成到模塊中，不是單獨模塊,。配置表也集成到模塊中,，全局常量變成了局部常量了，UDT也變成匿名結(jié)構(gòu),。