Queued State Machine

[F._Schubert · Accepted solution]

As I stated before, I advise you to use the enqueue function inside your producer (event handler). Your code will work fine at this scale, but on a large scale, you might get into troubles. Some advanced discussion which mainly focusses on the documentation of this design took place here on lava

The other improvement I suggest is your error handling. You already cover the basics (which is good and good enough for this size of code):

* Use a shift register for the error wire in the producer loop

* Use an error case around the Event structure and stop the loop on error (like in the consumer loop)

* Pass the error wire from the enqueue Idle State to the dequeue element at the consumer loop

* Use a shift register in the consumer loop for the error wire as well

* After the consumer loop, use the general error handler to clear error codes 1122 and 1 (use 'no dialog' and 'cancel on match')

* Merge the errors from producer and consumer before the General Error handler

Felix

[dan07]

F. Schubert and blawson

I followed all your advices. The only thing that I did different was that instead of having a Enqueue function inside each Event Case, I put only one before the Event Case and put the State of the State Machine in a Shift Register.

What do you thing about the code? What else can I improve on it?

Thanks

Dan07

[Yamaeda]

To me it looks very good now, clean, clear, structured. The only minor visual improvement is an unnecessary error wire in the event loop, as you can continue from the '?' of the case structure, just as you've done on the state machine.

The shift register for the enqueue is clever, but requires that all cases generate a state i assume. What happens if you have a empty event (state machine wise)? Will you enqueue Idle or nothing? I think many often solve small events directly in the event loop. With the shifted register you'll need to create a state for all such small things and possibly keep track of where you were to get back to the right state afterwards.

That's not a fault or error, just a small warning regarding the chosen design.

/Y

[ceties]

The enqueue primitive should definitely be in the same iteration and not wired via shift register into the next one. It makes it unnecessarily too complicated and confusing. What I also usually do is that I wrap the enqueue into for loop and and make it a subVI. Thus I can pass multiple states at once.

 

Message Edited by ceties on 04-06-2010 03:34 AM

[blawson]

yeah I absolutely would not enqueue in the producer loop outside the event structure.  What happens if you want to enqueue multiple states?

I don't think the general error handler accepts an array input for exceptions, I believe you've wired the user error codes input by accident.  keep the array, put a little for loop around the node.

[F._Schubert]

You forgot to wire through in the error case! So you will at the moment never trap any error, but get an error 1 from the top loop in case of any error in the top loop.

Felix 

[dan07]

Ok guys, I did all the changes.

Is there anything else to do to improve this code?

Thanks

Dan07

[Lucither]

Hi Dan,

Is there any reason why you cant enqueue both states within the event case?:

Message Edited by Lucither on 04-11-2010 07:36 AM

[Lucither]

Hi Dan,

Reading earlier posts i can see that this is only an example of what is going to be a larger program. Im just wondering, will you be wanting to use this enqueue technique to add more then 1 state. ie will you be adding state 2 from state 1 but then maybe add a state 3 from state 2 and so on, so on...  The only reason i ask is because if this is what you are planning to do you may encounter problems in future. If for example your state 1 can possibly take a relatively long time, ie establishing comms with a peripheral device or hardware, you could encounter a problem where within that time another event has been fired which in turn adds more states to the queue. Your state 1 then finishes, adding the other states to the queue. For example, if while state 1 is establishing comms another event fires which adds state 7, then your state 1 finishes which enqueues state 2, which then enqueues state 3. You will have a queue that goes 7,2,3.

This may never be a problem for your code but just something to bear in mind.

Rgs,

Lucither

[dan07]

In my real code I have to make one state trigger the next. Because sometimes one state will run a subVI that will compare something or run some code and depending of the results will be necessary to run state A or B (for example), as the next state.