Questions about AF , QMH, StateMachines

[Ironman_]

There are already some discussion around the forum but I wanted to summarize and discuss some aspects of AF.

I 've found out that AF is not well suited to make a state machine "as is".

AF is out of the box a MHL (message handler loop) with benefits (spammable, derivable, hirarchical and with error handling all built in).

AF is good to model a "module" of your program, that is a piece of code responsible to do one thing, to/from which I can communicate via "messages".

BUT

if I need a state machine inside the AF, I must do it in a Helper Loop in Actore Core.

This is because I can't manipulate the queue of actor, I can't flush it (and that's good).

But I CAN flush MY queue state machine INSIDE actor core.

Some of you depicted a usage of AF as a "Message Handler Loop shell".

In AF I can receive any message between 2 messages, because all messages are just enqueued WHILE I am doing work in actor core.

That's why I avoid enqueuing messages from within actor method's.

Messages are the "interface" used by other modules to interact with us.

Is this correct?

[Taggart]

You might look into the state pattern actor.  I think you can get it on VIPM. If you search the forums you can probably find some posts on it.

[Oli_Wachno]

I am currently still working with the State Actor. The only thing to really take care of is the concept of the Context Actor.

I have just corrected my posting here and attached the files directly.

Hope it helps

[Ironman_]

What is a state actor?

what problem does it solve?

At the moment I use AF in 2 ways:

1. As a MHL to which I talk, and it "does things", eventually giving me an async reply
2. As a MHL shell + an Helper Loop Classic State Machine, where I can flush the queue

The actor "state" for me is the actor class cluster AND/OR the shift register of the helper loop

[Taggart]

Disclosure: I haven't actually used the state pattern actor in a project, so I'm just speaking from what I saw in the class.

It seems that the statepattern actor replaces having a bunch of conditional code in your actor.  For example:  When a actor recieves a partiicular message, it may check Have I been initialized yet?  If so do x if not do y

That get's replaced with inheritance, based off of what state you are in.  Maybe Olli can explain it better, or maybe Allen will jump on here.

[Ironman_]

Yeah I get what is state pattern now.

I saw his pdf presentation and also I have a book "Design pattern in C#" which implements the Gang of Four patters with simple and straighforward examples.

So state pattern is an actor that "do things depending on which state it is".

I will check it, it looks interesting fusion of state machine and MHL/Actor

This futher prove that AF should be "empowered" with extra code in order to move it forward, or to solve other problems.

thanks

[Oli_Wachno]

---

@Ironman_ wrote:

So state pattern is an actor that "do things depending on which state it is".

 

---

More exactly: A change of State is implemented by an Actor. A state transition implies an exchange of Actors.

The State Pattern Actor implements the handling of these States changes.

The most important things in three sentences

[drjdpowell]

---

@Ironman_ wrote:

...Classic State Machine, where I can flush the queue...

---

Note: the LabVIEW community tends to use the term "State Machine" loosely, to include things where the "states" are really actions, and can thus meaningfully be queued (and "flushed").   Real State Machines (aka "Finite State Machines") are about being in a state (like "Idle" or "Acquiring").  They are in a state, and cannot meaningfully queue state.  The "State Pattern" is way of doing a true Finite State Machine.

[Taggart]

very well put Olli!

[Ironman_]

@drpowell,

by "flush the queue", I mean manipulate the queue that contains the states.

THis can't be done in AF, you have the object "enqueuer" and "dequeuer" which are queue, BUT they expose a restricted API (only 1 method: you can only enqueue message to an enqueuer, and you can only dequeue from dequeuer, that's it).

What I was trying to say is that if I have an actor that has a periodic task that can cause state transitions.... I need an helper loop in actor core, where I can define another queue, that I can manipulate (by flush or by playing with its timeout).

If you take AF "as-is" out of the box, it model a simple MHL.

@oli

in C# State Pattern is very simple, it's just an object X with a private class instance variable that is an interface (IState), and all public methods of X will call methods on IState (and change it, accordly). Pity that Labview doesn't have interfaces built in.