Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Launching Nested Actors Dynamically after Root Actor Core is Running

Solved!
Go to solution

I've been looking into implementing the Actor Framework into one of my work projects, but I keep running into a block in the framework I cannot mentally figure out: How do I launch nested actors dynamically after the root actor's Actor Core is already running?

 

My project involves managing connections to multiple devices via a Bluetooth connection. The host machine has multiple Bluetooth adapters and can connect to up to 32 devices simultaneously. My vision for the Actor Framework is to have a root actor launch nested actors on-the-fly, with the nested actors maintaining the connection to the device, running the necessary commands, then disconnecting from the device once a specific message is received from the root actor.

 

My problem is that the examples I've seen have the nested actors launched via the Launch Nested Actor VI, then the root actor object is fed into the Actor Core VI which runs until the program exits. After the root actor Actor Core is running, I don't see a way to launch nested actors and have the root actor object updated with the newly-launched nested actors. Is there an established practice for handling these types of dynamically-launched nested actors that I've yet to see? 

 

Let me know if there's any additional information I can provide regarding my application. I can't imagine there isn't a way to do this properly, but my searching so far hasn't turned up much.

 

Thanks,

 

-Preston

0 Kudos
Message 1 of 6
(4,609 Views)
Solution
Accepted by topic author pherrmann90

Use launch nested actor inside of a method of the root actor. To launch one, you just have to send the root actor a message. Since the launch nested actor happens inside actor core.vi message handler of the root, it can add a nested actor to the root's private data.

Message 2 of 6
(4,606 Views)

If you want to store these dynamically with a string, you might also find Variant Attributes pretty helpful.

 

When I have a collection of dynamically launched Actors, I like to use an empty variant in my caller actor's private data as the store for the enqueuers via the Attributes, and then either use a name for each (you can use the Debug input, if that is set, for example) or flatten an enum (I do this because my Actors are from a set, and unique - i.e. they are 0 or 1 of that type).

 

If you have more than one of only one type, an array might be better, but it can be more tricky to identify the appropriate enqueuer.


GCentral
Message 3 of 6
(4,578 Views)

You can have a look at these examples "Actor Framework from basic to PPL Plugin"

Starting from example 3 the plugins/nested actors are launched dynamically.

 

Kind Regards,

Stefan

Message 4 of 6
(4,563 Views)

There it is. This makes sense. Looks like I need to get some more Actor framework practice under my belt, but for now I see how this would work. 

 

Thanks for all the insight and examples everyone!

 

-Preston

0 Kudos
Message 5 of 6
(4,551 Views)

@cbutcher wrote:

If you want to store these dynamically with a string, you might also find Variant Attributes pretty helpful.

 

When I have a collection of dynamically launched Actors, I like to use an empty variant in my caller actor's private data as the store for the enqueuers via the Attributes, and then either use a name for each (you can use the Debug input, if that is set, for example) or flatten an enum (I do this because my Actors are from a set, and unique - i.e. they are 0 or 1 of that type).

 

If you have more than one of only one type, an array might be better, but it can be more tricky to identify the appropriate enqueuer.


I just got a notification about this post, and wanted to point out that from LabVIEW 2019, we can use Maps (rather than Variant Attributes) to store similar setups with perhaps simpler usage.

Especially if you'd like to reference a particular enqueuer with something other than a string, the Map solution would be much simpler (because a Map can have any data types for Key, Value - e.g. "enum" and "Actor Framework Enqueuer", or indeed "class object" and "enqueuer" (that one may be less relevant, but can be considered if required).


GCentral
0 Kudos
Message 6 of 6
(2,970 Views)