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

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

大的用處是讓我了解了什么是模式狀態機，當然了，肯定也只是PACKML的一部分內容。我不了解PACLML，只是從一些資料知道PACKML其實是涵蓋了整個項目結構的內容，不光是模式狀態機了。

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

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

容易實現的是狀態轉移了，我就做了容易的部分。

并且實現后發現其實是完全可以適用于很多離散行業場景的。這里記住，PACKML是包裝行業的規范，它定義的狀態并不適用于其他行業。其他行業有各自的狀態定義，這個自己來。

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

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

當調試好后，診斷塊都可以在項目中刪除不用。

先記到這，有時間再寫具體實現。

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

2024.01.23

本來已經意興闌珊了，可偏偏是個精，都還沒開始呢。

好吧，只能繼續了。

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

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

放張圖：

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

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

1、有一個全集，包括了所有的狀態。

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

3、模式1向模式2轉移需要的條件：模式2里面存在當前模式1的當前狀態A.

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

state change.

6、......

如何設計：

仔細觀察Excute狀態：

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

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

3、數組的單元是個結構：狀態本體、出口。

4、狀態是個整數，表示狀態標識，出口也是個整數（后來改用word)。

看級別，把級別也看做狀態，則和普通狀態沒有區別。

只是級別做成單獨的數組，單元類型和普通狀態是同一個類型。

如果這樣，如何表示從一個級別的狀態轉移到另一個級別的狀態呢？

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

范圍是不是夠呢？一個字節表示256種狀態，應該夠了吧。特別是級別。

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

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

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

工作量大的是診斷工作。

如何定義呢？我也是邊實現邊定義，沒有事先定義。現在還沒有機會整理診斷編碼。

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

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

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

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

配置表：

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

2、模式狀態機配置表

3、狀態或級別配置表內容：

上圖以級別表為例，狀態表類似。

當處于某個狀態時，需要和配置表中SCCode一致的SC才能使狀態發生轉移，不符合則會被拒絕。

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

初始化后根據傳入的SCCode先在級別表里面檢查是否有合適當前級別的SC，從別開始到當前級別終止檢查。如果有則直接轉入Next狀態，沒有則繼續在當前State里面檢查。

都沒有則拒絕執行轉移。

代碼簡單就不放了。

現在的重點是如何設計好的狀態收集、如何處理才能使SCCode不會被錯誤覆蓋造成狀態不能轉移。

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

后記：

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

我的做法是把狀態機集成到模塊中，不是單獨模塊。配置表也集成到模塊中，全局常量變成了局部常量了，UDT也變成匿名結構。