For writing applications, Alware generally uses LabVIEW. In order to start new projects quickly, mostly pre-developed templates are used. A template represents a process or sub-process and each process performs a separate task. Separate processes run in parallel with eachother, communicate with eachother and are being build up out of separate states.

Examples of states are initialization, idle, measure, save, error, and quit. The individual states are called within a state machine.

figure 1. Simplified template of a statemachine


After execution of one or more sub-task(s) in a specific state the next state will be called. To invoke these subtasks or states, unique enumerated constants, are used that contain the names of the individual states. In order to increase flexibility, the enumerated constants (state-calls) can be putted into a status buffer in any desired sequence (see figure 1: ENUMconts).

The sequence as well as the number of states in the states buffer usually depends on decisions made in the individual states. If a certain state has been executed, the corresponding state-call disappears out of the status buffer and the next element becomes valid.

If there are no more state-calls in the buffer, the “idle state” which is default, will be the next state executed. In the “Idle state” the status of the process is updated and the program is waiting for a new action either from the user interface or from the application itself.
The statemachine is extremely flexible and is very easy to expand.

If several processes run in parallel to one another, for example visualization, data collection and data storage, it is possible to send state-calls from one process to another and vice versa. A higher priority can be given to the individual state-calls, which makes it possible to change the sequence of the current elements in the status buffer.
The (re-)arranging or prioritization of states takes place immediately after the actual state has been executed in “State Priority” (see fig.1).

By integrating a built-in debugger in the Next (see fig.1), the actual states that are being executed can be viewed in real time. Breakpoints can be placed and the program can run state-by-state (step mode).
To keep the program well-organized, the process variables are bundled and placed in a shift register. In this way, the program remains clear and all variables are available and editable in every state.

Error handling:
During execution of a state there is always an error check. In case of an error, the “error state-call” is placed as first element into the status buffer. So the error case will be executed in the subsequent call in the status machine.

After closing the program an ini-file is automatically created for each individual (sub)process. In this ini-file the actual values of all control variables on the user interface are being saved. After restarting, the program automatically loads these values out of this ini-file (GET ini-file in fig.1.) into the variables buffer (shift) register.

additional info: