LabVIEW程序設(shè)計模式(二)—基本狀態(tài)機模式
加入技術(shù)交流群
圖 2 Enum型和Ring型控件
- enum型代表的值只能夠為U8、U16和U32型，而ring型代表的值允許為I8、I16、I32、I64、U8、U16、U32、U64、EXT、SGL、DBL和FXP型；
- ring型實質(zhì)上是一種numeric型，而enum型是一種獨立于numeric之外的數(shù)據(jù)類型；
- 當把ring或enum型控件分別連接到case時，對ring型而言，case結(jié)構(gòu)的選擇端子只能夠顯示數(shù)值；而對enum型而言，case結(jié)構(gòu)的選擇端子能夠顯示具體的枚舉值；
- ring的strings[]屬性可以在程序運行時被修改，而enum的strings[]屬性在程序運行時卻無法被修改；
- 當把ring型和enum型控件分別制作成自定義類型控件（Type Def.）時，ring的控件實例可以任意設(shè)置其strings[]屬性的值，而enum的控件實例卻無法設(shè)置strings[]屬性的值，如圖 3所示；
- 當把ring型和enum型控件分別制作成自定義類型控件（Type Def.）時，改變ring的Type Def中控件的strings[]屬性的值，但是其對應(yīng)的實例的strings[]屬性卻不會改變；而改變enum的Type Def中控件的strings[]屬性的值，其對應(yīng)的實例的strings[]屬性會隨之發(fā)生變化。
- ring型控件對應(yīng)的各個狀態(tài)可以表示任何值（在控件的property>>Edit Items對話框中），而enum控件對應(yīng)的各個狀態(tài)只能夠從0開始順序表示（在控件的property>>Edit Items對話框中）。
圖 3 Enum型和Ring型控件對比
反觀我們在本章開頭提到的10個問題，使用LabVIEW狀態(tài)機模式是否能夠回答上述問題呢？也就是說基本狀態(tài)機模式有什么樣的缺點呢？
- 狀態(tài)的分類不清晰。試想，如果有幾十個狀態(tài)，那么case結(jié)構(gòu)的選擇端會顯得沒有條理。事實上，我們是可以對狀態(tài)進行分類的，如數(shù)據(jù)采集、數(shù)據(jù)分析狀態(tài)可以均屬于對數(shù)據(jù)的操作。其實并沒有統(tǒng)一的規(guī)定如何對狀態(tài)進行分類，其目的在于使程序能夠清晰明了。
- 缺乏數(shù)據(jù)共享和錯誤處理機制。例如在數(shù)據(jù)采集之后還需要增加一個數(shù)據(jù)分析的狀態(tài)，那么如何將采集得到的數(shù)據(jù)提供給數(shù)據(jù)分析模塊呢（使用局域變量、全局變量、共享變量或其它）？這一點并不能稱為基本狀態(tài)機的缺點，只是在上面的例程中沒有實現(xiàn)，所以單獨列出。
- 每一個狀態(tài)分支只能夠決定后面的一個狀態(tài)，而無法決定一個狀態(tài)序列（多個狀態(tài)）。假如狀態(tài)機有三個狀態(tài)A、B、C，前面板上有三個按鈕依次為B1、B2和B3。如果單擊B1時需要使得三個狀態(tài)按照A→B→C的順序執(zhí)行，當單擊B2時需要使得三個狀態(tài)按照B→A→C的順序執(zhí)行，當單擊B3時需要使得三個狀態(tài)按照C→A→B的順序執(zhí)行。這種情況是無法使用基本狀態(tài)機模式解決的。
- 程序一直在占用CPU資源。即使在Idle狀態(tài)下，仍然需要對前面板的控件值進行監(jiān)控以確定對哪一個狀態(tài)進行響應(yīng)。
- 無法響應(yīng)更多的前面板事件。如當單擊窗口右上角的×時，彈出一個確認退出的對話框。當鼠標在前面板拖曳時，捕獲這個事件。這種情況是無法使用基本狀態(tài)機模式解決的。
- 任何時刻只能有一個狀態(tài)在運行。如果用戶需要在數(shù)據(jù)采集過程（acquire狀態(tài)）中查看“關(guān)于&幫助”對話框（about狀態(tài)），那么基本狀態(tài)機模式只能暫停數(shù)據(jù)采集而顯示對話框，卻無法實現(xiàn)在查看“關(guān)于&幫助”對話框的同時仍然進行數(shù)據(jù)采集。
評論