Implementing the State Pattern in Actor Framework

[AristosQueue (NI)]

[AristosQueue (NI)]

You cannot change state in Pre-Launch Init.vi. The object that you start with is the one that must make it all the way to Actor Core. The Pre-Launch Init.vi requires you to call parent and then requires the output of call parent make it to the output FP terminal. You can change *values* along the way (i.e. call any method you want, bundle in any data you want) but you have to maintain the same type of object. That's enforced by the architecture in order to make the AF work. If you want to launch a different state then the caller needs to launch that state.

The only time you'll be able to change states is by posting a message to yourself inside of Actor Core.vi.

[AristosQueue (NI)]

If your caller truly does not know what to launch and you need to change states immediately, you can post a message to yourself in Pre-Launch Init.vi to change states. If you make it a High priority message, it'll be guaranteed to be the first message handled by your actor.

[paul.r]

I am curious how others manage dependencies between the various state actors - in the example, there are several circular dependencies between the actors. Is there a better way to handle this? 

[crandiba]

Thanks once again for a really great piece of work. Its stuff like this that really makes a difference in the community.

I have a project which fits this design incredibly - however, it all hangs on solving a particular technical challenge: have a way to copy the parent data of a class to a child of said class generically. To clarify: we wire two class objects in to a subVI, and (only) the parent portion of the data of the object is copied over to the other one. 

At the moment, we have to implement an override on the state transition and "manually" do the work to add the appropriate get/set accessors to copy the data from one state object to the other. I would like us to have a way to do it automatically, so no additional work from the developer is necessary, and ship it as part of a framework. 

I looked into other related posts like: Substitute Actor.vi: Child to parent? but other than trying to flatten the class data to .xml and playing around, I got no other solutions in mind at the moment. Do you think this would be possible, or even we would/should never be able to do?

Thanks again,

Cris 

[aa82]

There is no clean or recommended way I know of doing what you mentioned, as I have the exact same problem. What I have done is that I have created extensions of the base actor, packing in more functionality, and then I have extended that actor with a finite state machine actor that has a method called "Copy State Data.vi". (To be honest, my FSM framework is much more mature than the one posted here, as I consider the one posted here just a proof of concept. It even has apparent problems, which I mentioned in my earlier post, and is not really useful in a complex project. The problem is that for any generic FSM actor to be useful, you basically have to implement the change state message as a high priority message and not just a method that gets called when you want to change states.)

Anyway, for my FSM actors, there is one single parent class that is THE FSM, and then its child classes are the states. When the FSM changes between states (child classes), the "Copy State Data.vi" method is called that copies the FSM state data (the parent class that has data global to all states) to the new state. The child class data is lost, which is what I want anyway, since any local state data within a particular state shouldn't carry over to the next state, which has the global data plus its own private, local data. In the "Copy State Data.vi" I utilize the "Substitute Actor.vi" method for the Actor Framework VIs, but then my own "Copy State Data.vi" in my actor extensions is called. You have to manually configure at each level what data gets copied over. This is a bit annoying, but it is simply a required step of the framework. If you edit the FSM state data, then you should update the "Copy State Data.vi". This is actually nice in a way because it forces you to ask questions like "should this data be copied?". I have actually come across a few instances where I wanted global FSM state data to be reset (i.e., not copied) upon changing states.

There are ways you could probably do it. For example, you could keep your state data as variant attributes. Since these are relatively generic, you could have ways to automatically copy them. However, that provides annoyances in reading and writing the data since you will be type converting all the time. It's easier to just manually edit the "Copy State Data.vi".

[aa82]

Also, I am just going to warn you, you are going to come across serious problems in LabVIEW when using the actor framework, especially with more complicated actors. This basically stems from the class implementation in LabVIEW being extremely fragile. Just today, I open a project that's been working perfectly and get this message in my "Copy State Data.vi", which I described in my other message:

This is unfortunately not the first time such things have happened. You should just be aware of the challenges that you will face, much of them completely unsupportable by NI.

[Oli_Wachno]

---

@aa82 wrote:

...

This is unfortunately not the first time such things have happened. You should just be aware of the challenges that you will face, much of them completely unsupportable by NI.

---

This does sound strange indeed. Sounds like a corrupted file. I’d suggest to do a complete checkout from the SCC. If this doesn’t help, uninstall the State Pattern Actor and reinstall. 

I’ve not encountered problems with AF like this before.

Can you please share your findings?

[crandiba]

Hi dostini,

We happen to be in the exact same situation: a plugin framework in which we would like to take advantage of the State Pattern. Like you said, its hard to think of expansion if you want to inherit from a "State Pattern" actor that has its "State" classes.

I guess that is why you and Casey both mentioned "Delegation": carrying the "State" object in the State Actor. I was hoping you could share your experiences with this and if they paid off in the end?

Cheers!

[dostini]

Hey crandiba,

I did end up getting this to work.

I ended up including a State Core object in the State Machine actor's data. To call it, you  pass a concrete State Core-type object to the "New State Machine.vi" and launch the State Machine actor that it generates; it then launches the core actor and you're away.

The state machine caller sends state change messages to the state machine (i.e. "Initialise"), which causes it to change state (if allowed) and send an associated message to its State Core actor so it can do stuff appropriate to that state (i.e. open com ports, spin up its own nested actors, etc etc).

Error handling was a pain.

I packaged the message abstracts, the State Machine actors and the abstract State Core actor separately; I can't remember why at this point.. The State Machine.lvlibp depends on the State Core.lvlibp, and they both depend on the Message Abstracts.lvlibp.