上個(gè)月剛接觸西門(mén)子OMAC的PACLML示例，我試著(zhù)做了個(gè)程序來(lái)驗證，效果不錯。

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

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

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

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

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

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

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

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

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

先記到這，有時(shí)間再寫(xiě)具體實(shí)現。

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

2024.01.23

本來(lái)已經(jīng)意興闌珊了，可偏偏是個(gè)精，都還沒(méi)開(kāi)始呢。

好吧，只能繼續了。

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

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

放張圖：

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

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

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

2、全集不一定非得有一個(gè)模式對應，可能有也可能沒(méi)有。

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

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

state change.

6、......

如何設計：

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

1、有三個(gè)出口、三個(gè)入口。

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

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

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

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

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

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

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

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

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

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

邏輯設計很簡(jiǎn)單，不需要多少代碼。

工作量大的是診斷工作。

如何定義呢？我也是邊實(shí)現邊定義，沒(méi)有事先定義。現在還沒(méi)有機會(huì )整理診斷編碼。

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

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

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

放張我設計過(guò)程中的截圖，上面的SC編碼沒(méi)有級別編碼，需要轉換。

配置表：

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

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

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

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

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

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

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

都沒(méi)有則拒絕執行轉移。

代碼簡(jiǎn)單就不放了。

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

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

后記：

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

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