LabVIEW程序設計模式(三)—消息隊列型狀態機模式
加入技術交流群
- 狀態的分類不清晰。
讓我們回到程序，并給程序的狀態設置一些“書立”。如圖 4所示，系統共有9個有效狀態（UI Initial、Data Initial、Instr Initial、Temperature、Power、FFT、JTFA、Data Clean、Exit）。如果把這些狀態混在一起，我們需要找到某一個狀態時會比較困惑和麻煩。如同上面所述，將這些狀態分為4類并設置了4個“書立”（Initial、Acquire、Analyse、System）分隔這些狀態。在實際的狀態控制中，需要確保程序只會進入實際的狀態中運行而不會進入到“書立”分支中，因此對每個“書立”加入了“-------”以示區別。
圖 4 狀態分類
盡管我們只是進行了少量的修改，但是這的確有利于程序狀態的組織和閱讀，尤其是當程序具有很多個狀態的時候。
- 缺乏數據共享和錯誤處理機制。
圖 5 狀態機中的數據傳遞
圖 5使用移位寄存器進行數據共享和傳遞，將所有的數據封裝在一個簇中并對每個數據命名，這樣在使用數據時就可以使用“Unbundle by name”或“bundle by name”。需要說明的是，即使使用一個數據需要共享，仍然希望采用簇的封裝形式，這樣當后續需要增加擴展數據的時候并不會影響現有的數據引用。
- 每一個狀態分支只能夠決定后面的一個狀態，而無法決定一個狀態序列（多個狀態）。
顧名思義，這種模式就像銀行辦理業務時排隊一樣采用隊列的方式。當儲戶進入銀行時，首先到叫號機處領取號碼進行排隊（進入隊列）并等待。然后，當前面的儲戶辦理完業務后就可以到相應的窗口辦理業務（退出隊列）。事實上，這種方式在現代生活中隨處可見。
在LabVIEW中至少有兩種實現消息隊列的方法。如圖 6所示。前者使用數組函數實現隊列元素的入列和出列；后者使用隊列函數實現隊列元素的入列和出列。二者都能夠實現隊列的有序操作和狀態的序列變化。
圖 6 消息隊列型狀態機模式
本節解決了基本狀態機模式中的（1）~（3）個問題，為了更好地比較和使用這些特點，特使用一個實例說明消息隊列型狀態機的使用過程。
【應用2】
本例要模擬一個自動販賣機的工作過程。它的一次正常交易過程為：投幣→選擇需要購買的商品→找幣，當幣值不足或商品已經銷售完畢時則無法購買。
程序的前面板如圖 7所示。在販賣機的左上側有4個按鈕。- 1USD：單擊時表示投入1美元的貨幣，2USD和5USD類同；
- Change Back：表示找零，也就是將目前剩余的貨幣退還給用戶。
本例將使用本節介紹的消息隊列狀態機模式解決這個應用（也可以使用其它的設計模式）。系統的功能并不復雜，關鍵是要判斷販賣機中的剩余錢數和剩余的貨物數以決定交易是否成功。
圖 7 自動販賣機前面板
程序背面板如圖 8所示。系統分為5個狀態，并分為2大類。
評論