LabVIEW Programming Pattern (III) - Message Queue State Machine Pattern

For the problems (1-3) of the basic state machine pattern, the pattern needs to be improved. This section will analyze the solutions to these problems one by one, and finally form a new state machine pattern - the message queue state machine pattern.

1. The classification of status is not clear.

This is a problem involving classification and management of various states, and it is an organizational problem. We can make an analogy. There are many kinds of books on a desk (communication, computer, machinery, law, etc.), and these books are neatly placed on the desk. But when we look for a book, we don't feel very quick and casual, because the books are placed in disorder. Every time we look for a book, we have to browse from the first book until we find the book we want. Maybe we can make some changes. We set up some book stands to separate different kinds of books. And mark the types of these books on the book stands. In this way, when we look for a certain kind of book, we don't need to start from the first book. We just need to find the corresponding book stand and search among these book stands.
Let's go back to the program and set some "book stands" for the program's state. As shown in Figure 4, the system has a total of 9 valid states (UI Initial, Data Initial, Instr Initial, Temperature, Power, FFT, JTFA, Data Clean, Exit). If these states are mixed together, it will be confusing and troublesome when we need to find a certain state. As mentioned above, these states are divided into 4 categories and 4 "bookends" (Initial, Acquire, Analyse, System) are set to separate these states. In actual state control, it is necessary to ensure that the program will only enter the actual state and not enter the "bookend" branch, so "-------" is added to each "bookend" to distinguish them. Figure 4 State classification Although we have only made a small modification, it does help organize and read the program state, especially when the program has many states.

2. Lack of data sharing and error handling mechanisms.

In the stacked sequence structure, data transfer between frames is achieved by "sequential local variables". So how to transfer data of different branches in the case structure? This problem seems to be easy to solve. It can be solved by using local variables, global variables or shared variables, but these are not the best solutions. Because the above methods will obviously consume the memory space and time of the system operation. Since the basic components of the state machine include loops in addition to the case structure, shift registers can be used to transfer data. As shown in Figure 5. Figure 5 Data transfer in the state machine Figure 5 uses shift registers for data sharing and transfer, encapsulates all data in a cluster and names each data, so that "Unbundle by name" or "bundle by name" can be used when using data. It should be noted that even if a data needs to be shared, it is still hoped to use the encapsulation form of a cluster, so that when the extended data needs to be added later, it will not affect the existing data reference.


Application 2 ]



The front panel of the program is shown in Figure 7. There are 4 buttons on the upper left side of the vending machine.

1. 1USD: Clicking it means investing 1 USD, 2USD and 5USD are similar;
2. Change Back: means to make change, that is, to return the remaining currency to the user.

On the right side of the program are 5 buttons, representing 5 different types of cola (the Coca-Cola icon is used here), and the price of each cola is $1. The number below the cola indicates the number of bottles of the product remaining in the vending machine, initially 20 bottles of each. Current money shows the amount of money remaining in the vending machine. You can continue to buy cola or choose to return it. Clicking the Stop button will exit the application.
This example will use the message queue state machine pattern introduced in this section to solve this application (other design patterns can also be used). The function of the system is not complicated. The key is to determine the remaining money and the remaining goods in the vending machine to determine whether the transaction is successful. Figure 7 Front panel of the vending machine The back panel of the program is shown in Figure 8. The system is divided into 5 states and 2 categories. [page]

1. Category 1: Initial

1. UI Initial: Initialization of the front panel interface.
2. Data Initial: Data initialization.

2. Category 2: System

1. Idle (Default): Idle state.
2. CheckMoney: The remaining money and the remaining goods in the vending machine determine whether the transaction is successful.
3. Exit: Exit the program.

When the program starts running, it enters the UI Initial and Data Initial states to complete the initialization operation. From the figure, it can be seen that the system uses array functions to process message queues. Figure 8 Back panel of vending machine In UI Initial, the system assigns values ​​to the title bar and description bar, and sets the goods on the front panel to a non-purchaseable state, because the coin insertion action has not been completed during initialization. As shown in Figure 9. Figure 9 UI Initial branch In Data Initial, there are two shared data: Money and GState. The former represents the remaining coin value in the vending machine, and the initialization value is 0; while the latter represents the remaining number of each commodity in the vending machine, and the initialization value is 20. Data is transferred using shift registers to facilitate sharing and use in various case branches, as shown in Figure 10. Figure 10 Data Initial branch CheckMoney branch is mainly used to prevent illegal transactions (such as insufficient coin value or insufficient number of commodities), as shown in Figure 11. Figure 11 CheckMoney branch When the program runs to the Exit branch, it will stop the loop and exit the program, as shown in Figure 12. Figure 12 Exit branch Idle branch is used to monitor the changes of each button control on the front panel and execute the corresponding state. This branch is more complicated. When the 0th button is detected to be pressed (i.e. the 1USD button), the currency value in the vending machine should be increased by 1, and it is also necessary to determine whether the transaction conditions have been met (i.e. entering the CheckMoney state). The other states can execute the corresponding code, and I will not repeat it here. Figure 13 Idle branch