LabVIEW程序设计模式(三)—消息队列型状态机模式

针对基本状态机模式的第（1~3）个问题，需要对模式进行改进。本节将一一分析这些问题对应的解决方案，并最终形成一种新的状态机模式——消息队列型状态机模式。

1. 状态的分类不清晰。

这是一个涉及各个状态分类管理的问题，是一个组织问题。我们可以做一个类比，在一个书桌上有许多种类的书籍（通信、计算机、机械、法律等），这些书都摆放在书桌上很整齐。但是我们在寻找一本书时并不会觉得很迅速和随意，因为书籍的摆放是无序的，每次寻找书籍我们不得不从第一本开始浏览直至找到我们想要的书籍。或许可以做一些改变，我们设置一些书立，将不同种类的书使用书立分开。并且在书立上标明这些书籍表示的种类。这样我们在寻找某一种书籍时就不需要从第一本书开始寻找了，只需要找到对应的书立，在这些书立中寻找即可。
让我们回到程序，并给程序的状态设置一些“书立”。如图 4所示，系统共有9个有效状态（UI Initial、Data Initial、Instr Initial、Temperature、Power、FFT、JTFA、Data Clean、Exit）。如果把这些状态混在一起，我们需要找到某一个状态时会比较困惑和麻烦。如同上面所述，将这些状态分为4类并设置了4个“书立”（Initial、Acquire、Analyse、System）分隔这些状态。在实际的状态控制中，需要确保程序只会进入实际的状态中运行而不会进入到“书立”分支中，因此对每个“书立”加入了“-------”以示区别。


图 4 状态分类
尽管我们只是进行了少量的修改，但是这的确有利于程序状态的组织和阅读，尤其是当程序具有很多个状态的时候。

2. 缺乏数据共享和错误处理机制。

在层叠式的顺序结构中，数据在帧之间的传递是靠“顺序局域变量”实现的。那么如果在case结构中如何传递不同分支的数据呢？这个问题似乎很容易解决，使用局域变量，全局变量或共享变量都能够解决，但是这些并不是最优的解决方案。因为上述的方式会明显系统运行的内存空间和时间。由于状态机的基本组成元素除了case结构之外还有循环，因此可以使用移位寄存器来传递数据。如图 5所示。


图 5 状态机中的数据传递
图 5使用移位寄存器进行数据共享和传递，将所有的数据封装在一个簇中并对每个数据命名，这样在使用数据时就可以使用“Unbundle by name”或“bundle by name”。需要说明的是，即使使用一个数据需要共享，仍然希望采用簇的封装形式，这样当后续需要增加扩展数据的时候并不会影响现有的数据引用。

3. 每一个状态分支只能够决定后面的一个状态，而无法决定一个状态序列（多个状态）。

在基本状态机中之所以存在这个问题是因为状态的传递使用的是Scalar（标量）形式，如果需要传递一个状态序列，很明显可以使用队列或数组进行状态的传递。在LabVIEW程序设计模式中将这种具备处理状态序列的状态机称为“消息队列型状态机”，它是在基本状态机基础上的改进。
顾名思义，这种模式就像银行办理业务时排队一样采用队列的方式。当储户进入银行时，首先到叫号机处领取号码进行排队（进入队列）并等待。然后，当前面的储户办理完业务后就可以到相应的窗口办理业务（退出队列）。事实上，这种方式在现代生活中随处可见。
在LabVIEW中至少有两种实现消息队列的方法。如图 6所示。前者使用数组函数实现队列元素的入列和出列；后者使用队列函数实现队列元素的入列和出列。二者都能够实现队列的有序操作和状态的序列变化。


图 6 消息队列型状态机模式
本节解决了基本状态机模式中的（1）~（3）个问题，为了更好地比较和使用这些特点，特使用一个实例说明消息队列型状态机的使用过程。

本例要模拟一个自动贩卖机的工作过程。它的一次正常交易过程为：投币→选择需要购买的商品→找币，当币值不足或商品已经销售完毕时则无法购买。

程序的前面板如图 7所示。在贩卖机的左上侧有4个按钮。

1. 1USD：单击时表示投入1美元的货币，2USD和5USD类同；
2. Change Back：表示找零，也就是将目前剩余的货币退还给用户。

程序的右侧是5个按钮，表示5种不同类别的可乐（这里均使用了可口可乐的图标），每种可乐的价格均是1美元。可乐的下面数字表示贩卖机中剩余的该商品的数量，初始为每种20瓶。Current money显示贩卖机中剩余的货币数，你可以继续购买可乐或者选择退回。单击Stop按钮将退出应用程序。
本例将使用本节介绍的消息队列状态机模式解决这个应用（也可以使用其它的设计模式）。系统的功能并不复杂，关键是要判断贩卖机中的剩余钱数和剩余的货物数以决定交易是否成功。


图 7 自动贩卖机前面板
程序背面板如图 8所示。系统分为5个状态，并分为2大类。