Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Access dynamic nested actors in callers event structure

Solved!
Go to solution

Hi, 

 

I have a AF like this: 

(found the image on google, please don't mind the obvious errors)

LabviewBow_0-1612958634070.png

here I can comfortable access the Enqueuer of Aquisition and Logging because they are created before the while loop starts.

 

Now I have made another nested actor that is dynamically created inside this loop. Is there some way to access its enqueuer easy and direct from the event structure, like the other nested actors enqueuers? 

 

I use it in combination with a Delacore User Event Lib, remote controlling the AF from TestStand with the events. Most of the events are for the nested actor (in fact I could handle them with a event structure in the nested actor, but I want the data flow to be correct over the main actor). If I had the enqueuer in the main actors event structure I would save a lot of messages.

0 Kudos
Message 1 of 4
(1,462 Views)
Solution
Accepted by topic author LabviewBow

One solution is a little bit different architecture than your picture. After creating and launching Acq & Log, put their references into the Parent's private class data. Don't give the enqueuers to the Event helper loop. Then create a new VI for Parent called "Start" (or however you like), and generate a related AF message. Now, when somebody pushes Start button, your event for "Start: Value Change" should send just 1 "Start msg" message "to self enqueuer". The new Start VI will send the 4 messages from your picture, plus any logic to launch/lookup/send to dynamic nested actors. This makes debugging a little easier too because it's easier to open the non-reentrant VI than opening the Actor Core clone instance.

 

By the way, when you Launch the Acq and Log objects, you need to wire the "Actor out" output terminal (e.g. the light blue wire going in the left, must also come out the right side) before you "Call Parent Method". The Actor Framework has some internal logic for managing nested actors and shutting down at the end. If you don't wire the outputs, none of that will work.

Message 2 of 4
(1,451 Views)
Solution
Accepted by topic author LabviewBow

 


@OneOfTheDans wrote:

One solution is a little bit different architecture than your picture. After creating and launching Acq & Log, put their references into the Parent's private class data. Don't give the enqueuers to the Event helper loop. Then create a new VI for Parent called "Start" (or however you like), and generate a related AF message. Now, when somebody pushes Start button, your event for "Start: Value Change" should send just 1 "Start msg" message "to self enqueuer". The new Start VI will send the 4 messages from your picture, plus any logic to launch/lookup/send to dynamic nested actors. This makes debugging a little easier too because it's easier to open the non-reentrant VI than opening the Actor Core clone instance.

 

By the way, when you Launch the Acq and Log objects, you need to wire the "Actor out" output terminal (e.g. the light blue wire going in the left, must also come out the right side) before you "Call Parent Method". The Actor Framework has some internal logic for managing nested actors and shutting down at the end. If you don't wire the outputs, none of that will work.


I'll second this suggestion. Put your called actor stuff in the main actor. This seems like more work at first (since you have to create more messages) but it's really flexible and expandable.

 

Say, for example, that your GUI and you background stuff is currently the same actor- no problem now, but what if you decide to separate them out later? Any descendant actors will no longer be able to do acquisition or logging, since they're ONLY controlled by buttons.

 

Similarly- what if you decide later on you need to programmatically trigger some logging function? With the given architecture, you can't do that. It only happens with the event structure. So now you're stuck making a new user event that triggers the same case as your button handler, which gets pretty messy.

 

Just stick it in a normal AF message. Keep helper loops local only and you'll find it much easier to debug, expand upon, and modify later.

Message 3 of 4
(1,417 Views)

ok thank you both!

0 Kudos
Message 4 of 4
(1,391 Views)