Implementing the State Pattern in Actor Framework

[helcio]

Hi,

I have the AF 4.1.1.33 installed. You may have to generate the VIPC  file and make it available, so that all dependencies can be installed.

thanks

Helcio

[helcio]

This is what happens:

[helcio]

Never mind, it works now!

thanks

[joezeppelin]

Hi niACS,

I've used the State Pattern to  change the way a Test actor responds to different messages from other actors where the Test actor will send a message (command) to another actor (such as a hardware controller) and wait in its current state until it receives a message (status) from another actor (harware controller) which will cause the Test actor to advance to the next appropriate state based on the message received.

This seems to be working pretty well, I'm wondering if the State Pattern will be incorporated into the next official release/update to LabVIEW and when that might be?

Also, can you elaborate on what is new in the latest version 1.0.1.7 of the State Pattern, do I need to uninstall version 1.0.0.5 first before installing 1.0.1.7 which has a different VIPM name?

Is 1.0.1.7 backwards compatible to what I've coded with 1.0.0.5?

Thanks

[AristosQueue (NI)]

> This seems to be working pretty well, I'm wondering if the

> State Pattern will be incorporated into the next official

> release/update to LabVIEW and when that might be?

We generally wait until we get enough community users who say, "Yes, this is useful and is done the right way." before we add anything to the framework. Just having a couple people use it -- even Allen or myself -- isn't generally enough to trigger that (though, obviously, the standards for what constitutes "enough people" is totally up to me and Allen's discretion, as there are some features we never expect to have wide usage, so just one or two people are enough). So when any feature will cross that line is hard to predict.

[St3ve]

Hi,

I am not sure if this thread is dead or is a support thread for the pattern. Anyhow...

Following some experimentation with the pattern I was looking at error handling. Essentially, my error handling is state specific but, in some cases, requires a state transition (to FaultState!). Unfortunately it appears that this is not possible in an override of Handle Error.vi as the output is a dynamic dispatch terminal i.e., the Actor type must propagate from input to output. Therefore, swapping the Actor (state transition) seems to be out?

Any suggestions of a work around?

As far as the Actor Framework is concerned I don't think the output actually needs to be DD but forking the framework would be a last resort.

Regards,

Steve.

[CaseyLamers1]

Steve,

I would recommend introducing a state class that is contained in your actor with state. I beleive this is more of a "has a " relationship than an "is a" relationship. Your actor has a state; not your actor is a state. I have successfully implemented this in my own large AF project. Feel free to contact me directly if you want some guidance.

Casey

caseylamers@gmail.com

608-577-7946

[AristosQueue (NI)]

Casey recommends against. I know niACS recommends in favor. I'm neutral on the topic -- if it works for you, do it.

As for the error handling, you are correct that error handling currently does not allow you to change types. I wish someone had pointed this out a couple years ago... at this point, changing that terminal to not be dynamic dispatch output would be a breaking change for all existing overrides of that method, so it can't really be changed. But I agree, that sounds like it would have been a good idea.

But I have a workaround for you: If you are using LV 2013 (or later), there is a dynamic dispatch method on Actor called "Receive Message.vi". It is meant for creating proxy actors, but you could use it to solve your problem. Override that method, call the parent version, and then include your error handling there, including the change of actors. The output of that method is NOT dynamic dispatch output.

[KuGr]

And if you are using LV2012 I can get you a direct LV2013 to LV2012 version downgrade if you don't want to go thru the trouble - and it is a bit of trouble.  I also have 2011 and 2010, but I don't test those extensively.

Kurt

[St3ve]

Thanks for your replies,

@ CaseyLamers1: I agree, in fact I have an implementation which does just that (Actor is the "Context" -- GoF terminology -- with State). However, I saw this implementation and liked the fact it made it easier to take an Actor, which was not originally designed with State in mind, and easily move it to a State orientated design (possibly). Conceptually, I see Actor Core as the Context with State in this case. Although, this does stray a bit from the idea that the Actor object is fully contained and can be tested like any other LabVIEW by-value object.

@ AristosQueue

     "I wish someone had pointed this out a couple years ago... at this point, changing that terminal to not be dynamic dispatch output would be a breaking change for all existing overrides of that              method, so it can't really be changed."

I suspected this may be the case and also, unfortunately, it holds true for Actor:Stop Core.vi.

@ Kurt Grice: I am using LV2012 SP1, a downgrade would be appreciated -- at least to see how much further I can go with this.

Regards,

Steve.