LabVIEW标准状态机：基本状态结构和程序框图

2023-07-02 理论教育版权反馈

【摘要】：状态是状态机运行的经脉，在开始使用状态机模式编写程序时需要将应用分为若干个状态。由图5-4可知，LabVIEW标准状态机主要由一个While循环（①）和一个条件结构（③）构成，并利用移位寄存器（②）来实现状态的跳转。根据要求，该应用至少包含以下5种状态结构：1）Initial：初始化状态。5）Stop：停止状态，退出循环并中止程序。数据采集应用基本状态机各个状态的程序框图如图5-6所示。

状态机是一种最为经典的程序设计模式，最基本的状态机结构如图5-1所示。状态是状态机运行的经脉，在开始使用状态机模式编写程序时需要将应用分为若干个状态。

由图5-4可知，LabVIEW标准状态机主要由一个While循环（①）和一个条件结构（③）构成，并利用移位寄存器（②）来实现状态的跳转。为了方便编程，可采用自定义类型来实现状态枚举值，这样当需要修改程序状态时，只需要改变自定义类型就可以改变所有的枚举变量。

图5-4 标准状态机程序框图

【例5-2】基本状态机应用

前面板具有3个按钮控件和1个波形显示控件，功能分别是：

1）“开始采集”按钮：Label是Start，单击后开始进行模拟数据采集程序（这里使用随机数代替）。

2）“关于”按钮：Label是About，单击后弹出对话框以说明这个程序的版权、帮助等信息。

3）“停止”按钮：Label是Stop，单击后停止程序的运行。

4）波形显示控件：用于显示获取的随机数。

这是一个非常简单的应用，但是具有一定的代表性。根据要求，该应用至少包含以下5种状态结构：

1）Initial：初始化状态。

2）Idle：空闲状态，用于响应各种用户界面操作。

3）Acquire：采集状态，用于持续模拟采集数据。

4）About：用于弹出关于和帮助对话框。

5）Stop：停止状态，退出循环并中止程序。

数据采集应用基本状态机的程序前面板如图5-5所示。

数据采集应用基本状态机各个状态的程序框图如图5-6所示。

图5-5 基本状态机的程序前面板

图5-6 数据采集应用基本状态机程序框图

a）Initial状态 b）Idle状态

图5-6 数据采集应用基本状态机程序框图（续）

c）Start状态 d）Acquire状态假分支 e）Acquire状态真分支

图5-6 数据采集应用基本状态机程序框图（续）

f）Stop状态 g）About状态

分析图5-6中的基本状态机，可以看出状态始终贯穿整个应用程序，并由移位寄存器进行值的寄存和传递。当前状态分支的结果将决定下一个状态，如图5-6b中的Idle状态。在这个状态中，程序将自动检测前面板的三个按钮是否被按下。如果“Start”按钮被按下，则进入Acquire状态；如果“About“按钮被按下，则进入About状态；如果“Stop”按钮被按下，则进入Stop状态；如果没有任何按钮被按下，则仍然进入当前的Idle状态继续检测。在Acquire状态中，为了保证程序的重复采集使得下一个状态仍然为Acquire，但是这样会导致程序无法停止（中断采集），于是需要在Acquire状态分支中加入Stop的探测，如果“Stop”按钮被按下，则不再进入Acquire状态而直接进入Stop状态。

例5-2中使用的是“枚举（enum）”型结构来标记状态，事实上也可以使用其他的数据类型替换，如下拉列表（ring）、数值（numeric）或字符串（string）。从严格意义而言，ring并不属于一种数据类型，它只是一种特殊的numeric，其性质与numeric基本上一样。尽管ring与enum控件从外观上看去类似，如图5-7所示，但是它们实质上是不同的。主要体现为以下7点：

图5-7 枚举类型和下拉列表外观

1）enum型代表的值只能够为U8、U16和U32型，而ring型代表的值允许为I8、I16、I32、I64、U8、U16、U32、U64、EXT、SGL、DBL和FXP型。

2）ring型实质上是一种numeric型，而enum型是一种独立于numeric之外的数据类型。

3）当把ring或enum型控件分别连接到条件结构时，对ring型而言，条件结构的选择端子只能够显示数值；而对enum型而言，条件结构的选择端子能够显示具体的枚举值。

4）ring的strings[]属性可以在程序运行时被修改，而enum的strings[]属性在程序运行时却无法被修改。

5）当把ring型和enum型控件分别制作成自定义类型控件（TypeDef.）时，ring的控件实例可以任意设置其strings[]属性的值，而enum的控件实例却无法设置strings[]属性的值。

6）当把ring型和enum型控件分别制作成自定义类型控件（TypeDef.）时，改变ring的Type Def中控件strings[]属性的值，其对应实例的strings[]属性却不会改变；而改变enum的TypeDef中控件的strings[]属性的值，其对应的实例的strings[]属性会随之发生变化。

7）ring型控件对应的各个状态可以表示任何值（在控件的“属性”→“编辑项”对话框中），而enum控件对应的各个状态只能够从0开始顺序表示（在控件的“属性”→“编辑项”对话框中）。

由于应用程序的各个状态在设计时就是相对固定的，不会在应用程序中进行修改。对比以上ring型和enum型的区别，可以看出在基本状态机中，enum更适合来标记状态。首先当把enum直接与条件结构相连时，条件结构的选择端会立刻显示enum的各个状态值，有利于程序的理解和维护；其次，当把enum制作成一个TypeDef型自定义控件时，如果之后要增加新的状态则只需要修改TypeDef型的strings[]属性，此时其各个实例的strings[]属性会随之改变。

基本状态机模式大体上能够满足主程序结构的需要。该模式能够很好地使得应用程序的各个功能以状态的方式有顺序地执行，并且保证了程序的可读性（以状态图的方式显示清晰明了）和扩展性（日后只需要扩展状态即可扩展相应的功能）。

但基本状态机也有局限性：

1）状态的分类不清晰。试想，如果有几十个状态，那么条件结构的选择端会显得没有条理。事实上，我们是可以对状态进行分类的，如数据采集、数据分析均属于对数据的操作。其实并没有统一规定如何对状态进行分类，其目的在于使程序能够清晰明了。

2）缺乏数据共享和错误处理机制。例如在数据采集之后还需要增加一个数据分析的状态，那么如何将采集得到的数据提供给数据分析模块呢（使用局域变量、全局变量、共享变量或其他）？这一点并不能称为基本状态机的缺点，只是在上面的例程中没有实现，所以单独列出。

3）每一个状态分支只能够决定后面的一个状态，而无法决定一个状态序列（多个状态）。假如状态机有三个状态A、B、C，前面板上有三个按钮依次为B1、B2和B3。如果单击B1时需要使得三个状态按照A→B→C的顺序执行，当单击B2时需要使得三个状态按照B→A→C的顺序执行，当单击B3时需要使得三个状态按照C→A→B的顺序执行。这种情况是无法使用基本状态机模式解决的。

4）程序一直在占用CPU资源。即使在Idle状态下，仍然需要对前面板的控件值进行监控以确定对哪一个状态进行响应。

5）无法响应更多的前面板事件。如当单击窗口右上角的“×”时，弹出一个确认退出的对话框；当鼠标在前面板拖曳时，捕获这个事件。这种情况是无法使用基本状态机模式解决的。

6）任何时刻只能有一个状态在运行。如果用户需要在数据采集过程（Acquire状态）中查看“关于&帮助”对话框（About状态），那么基本状态机模式只能暂停数据采集而显示对话框，无法实现在查看“关于&帮助”对话框的同时仍然进行数据采集。

LabVIEW标准状态机：基本状态结构和程序框图

相关推荐