Event structure placing in QSM

[ceties]

 Hi all,

1]  In most of my application I used QSM with event structure which was in one of the cases

- This approach has the disadvantage that if some of the states takes longer time the GUI doesn't respond immediately to the user actions. It freezes.

+ Big advantage of this is it's simplicity

see picture1 as an example of [1]

2] Now after reading very nice article I decided to put the event structure in separate loop which assures that every time the user acts it puts appropriate states to the end of the queue for further processing

+ no GUI freezing

- Imagine a situation when state1 is being processed and it takes long time. On the output from this state states2 and state3 should be added to the end of the queue. Meanwhile the user presses button that causes state4 to be add at the end of the queue.

 The desired sequence of the states should be state1->state2->state3->state4

Nevertheless it actually can happen to be  state1->state4->state2->state3

But it can be handled by locking the front panel programmatically

see picture2 as an example of [2]

So my first question is which approach do you use and why?

My second question is pointed on users of the second method with the separate UI loop. What do you do with errors there? If using the first method it is easy to handle error in general. Before dequeueing you just check if there is some error and if so you go to an error state to handle it.

Using [2] you can do it in the Main Loop but what if error happens in the UI loop?

Message Edited by ceties on 03-14-2008 04:25 PM

[Van_L]

Hi Ceties,

Your questions is very good, I am personally not too familiar with QSM and I am reading your linked article about it.

I came across this thread which people talk about QSM and are designing their own designing architectures. They might be a great source of consultants to get you started quickly.

Take care

[johnsold]

I do not use the QSM, although I use queues to pass commands from the GUI/event loop to the state machine loop.

When an event occurs, I put a command on the queue. The command is NOT equal to the next state. When the state machine ends the current state, a Next State subVI compares the command queue output (if any) with the next state requested by the previous state and checks the error cluster to determine the next state. This avoids the 1-2-3-4/1-4-2-3 problem, or, rather allows the Next State subVI to determine which is appropriate for the conditions. Thus, a command to Pause might wait until a Write Output, Read Input, Save Data series was completed before Pausing, while a Stop command might result in going immediately to the Shutdown state.

Lynn