Not grasping the connection between the Actor Core and my code

[wegunterjrNGC]

I am planning to expand my code to use the Actor Framework, but I am not sure if I am missing something simple.  I have created a couple of classes that contain my VI's that worked have them inherit from the Actor Framework. I have 2 of the same type of simulation, imagine that one is for the left side and one is for the right side.  Each of them contain some simulation code that will run independently of each other. Each will receive its own commands, and return its own data based on the algorithms (ie, simulated sensor data).   So, am I expected to override the Actor Core for each class, so that when I have my program VI that will launch each actor it will launch the code, or do I not have to override the ACtor Core for each class?

[wegunterjrNGC]

alright...light bulb!  I overrode the Actor Core VI of my Actor, and replaced it with a simple dialog box that will pop up when the Actor is launched.  I just made a simple VI that launched the Actor Core of my Actor, and made sure to put in the Call to Parent and pressed Run.   Lo and Behold, the simple dialog popped up!  Woohoo!! Now to add my actual code to the VI.  Still gonna be a task, but that will be a different thread. 

[wegunterjrNGC]

Alright, so now the next question. I can see how to launch a core that I override with my own code. I have a state-machine inside my actor core that runs before the Call Parent Method.   My problem is how does this framework/queue system allow me to STOP this state machine?  I plan to launch four other state machines like this that will all inherit the ACtor  Framework. I would like to be able to start and stop them as needed.  

[matt.baker · Accepted solution]

The Actor Core is running its own while loop de-queuing messages that are sent to it. From what I can see of your current set-up, the parent Actor Core won’t start running until your state machine loop has stopped.

Typically the parent Actor Core is run in parallel to your own custom loops. When a stop message is received by the parent Actor Core the loop stops. Use this to close the parallel loops:

Highly recommend you check out the Simple Actor Example from here: https://decibel.ni.com/content/docs/DOC-23893

The documentation is very good.

Also check out http://www.ni.com/white-paper/14117/en/ and https://decibel.ni.com/content/docs/DOC-17193 for some more examples.

[wegunterjrNGC]

Alright, I am a belie-ber in your words, and recognize that I need to implement them (especially, since I went back to the documentation and saw that it specifically called out to make sure I am running my ActorCore code is in parallel with the Call Parent VI).

Create a set of user events to manage your front panel updates. Create these events in your Actor Core.vi and bundle them into the actor object prior to invoking the Call Parent node. Then create a loop in your Actor Core.vi that runs in parallel to the Call Parent node which is dynamically registered for the events. When the actor receives a message, the handling function for that message can generate the appropriate event and pass along any relevant data. Alternatively, you may choose to use queues, notifiers, or other mechanisms to communicate with your parallel loop rather than events. Regardless of which mechanism you prefer, National Instruments recommends that you select only one data transfer mechanism within any given actor, and keep the total number of such mechanisms to a minimum within the application as a whole. Be sure to provide a mechanism to stop your parallel loop and trigger that mechanism by overriding Stop Core.vi in your actor child class.

How do I provide the mechanism for the loop to stop?  I can't just send a STOP string, nor can I use the STOP button at a higher level to send the STOP command to a lower level directly.....Can I?

Edit:  Okay, I was able to get my actor to stop by making sure the Call Parent Method was parallel to my process, adding an Event, and then sending a message to my QMH queue. 

[matt.baker]

You may have already thought of this from looking at the examples, but just incase:

Do you need the QMH running in parallel to the actor core? Could you make the QMH data part of the actor and send the actor messages?

This would then avoid the potential of sending the wrong data with a message (as it's now strongly typed and errors will are more likely to show at the development stage with broken VIs etc.) and it saves the work of converting the variant data to the desired data type.

Each state of your QMH would become a method of the new actor class.