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

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

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

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

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

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

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

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

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

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

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

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

2024.01.23

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

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

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

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

放張圖：

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

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

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

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

3、模式1向模式2轉移需要的條件：模式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、如果用鏈表表示，則入口可以不用關心，只需要出口。博途不支持鏈表（指針......），改用數(shù)組，一樣的道理。

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

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

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

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

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

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

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

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

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

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

工作量大的是診斷工作。

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

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

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

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

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

配置表：

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

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

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

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

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

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

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

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

代碼簡單就不放了。

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

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

后記：

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

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