3 Questions on AF

[MrShawn]

Hi all.

A little background I have been doing LabVIEW since Nov 2017 so I am still fairly new.  Please forgive any lack of knowledge on the vernacular when talking about LV and AF.

Quickly upon starting LV I pushed into object oriented and found that the base object framework in LV was insufficient - particularly when working on setting up asynchronous objects.  That is when I found the AF.

I have a few questions that I am looking to figure out that have been in the back of my head either upon starting AF or more recently as the last month or so I have been more seriously diving into it.

1)  The first question is in regards to the asynchronous responses from sub actors to a top level actor.  From my understanding I need to create a method/message on the top level actor to handle a message response.  How then can I make my sub level actor invariant to a top level actor (and visa versa) when I must send that specific message back up.  I would read the calling actor enqueuer to respond but this still seems clunky to me in some way.  Perhaps someone with experience can better explain and break out this process - I would greatly appreciate it.

2) My next question is in regards to using the Actor Core FP.  When launching some actors (root or nested) I see some cases where I want to utilize the FP.  Maybe one actor manages a test, and has several sub actors which handle the multiple devices.  I want the user of my program to use the test actor's FP to actually conduct or manage the test.  I have in fact played with 2 different architectures and I am wondering what more experienced  LV AF programmers do when they need to make a usable FP.  For both my architectures I inherent from a FP Actor I made which has reference to the FP(I must override the actor core vi to send a message containing the FP reference to itself).  From there I have simple functionality to open and close the FP.  Now one approach I take is to have now on the Actor Core VI 3 parallel loops, one for event handling, one which contains the parent actor core method, and a message handling loop which I build my major functioning off of.  I see this approach as taking away from the AF model as I am removing functioning from the AF's actor core message handling.  The other is I build a cluster which defines the FP and package a reference to that and send it into the actor core message handling and modify the FP in the method VIs using the references.  Is there a more standardized way of approaching FP use in AF?

3) Finally my last question builds off the previous and has to do with how I should handle specific internal functionings of my actor.  For example above I said in one architecture I used a 3rd message handling loop.  This loop is strickly handling internal functionings that I can better control from outside message injections.  Should I NOT be using a 3rd loop for internal message queueing and send message to self through the AF and handle it there or is a 3rd (or second depending on the circumstances, I say third because in my example I have an event handling loop for FP) loop generally standard practice?

Long post I know I tried to keep it as short and simple as I could.  Any responses are appreciated.

Thanks.

MrShawn

[Taggart]

Before answering your questions I am going to recommend that you take the class, it will likely answer all your questions (and some you didn't even know you had) in far more detail than what you will get on here....

1.  look up zero coupling (abstract) messages and loose coupled messages. You should find several threads about them.  It will help you manage the coupling between actors.  For sure, you should always send messages up the tree using zero-coupling (or you could also use self-addressed messages).

2.  You are on the right track.  No need to inherit from an FP actor.  Write your actor as it if had no frontpanel.  Then create a child class called My Actor with FP.  In it's actor core override add a parallel helper loop with an event structure to handle button presses.  Then the event loop send messages to the Actor (using self-enqueuer) and the actor can update the FP by firing custom user events.  For opening/closing the fp, you can just add them to the block diagram of the Actor Core Override.  Or you could also create messages to do that, if you want to dynamically open/close.  

You are not "taking away from the AF model" by using helper loops.  They are internal to the actor.  from the external world, the actor still looks and acts like an actor and the external world has no idea there is a helper loop.  One thing I would caution is try to maintain all your state in the main actor core.  Don't keep state in the helper loops.

3. Not sure what you are asking here?

[MrShawn]

Thanks for the response.

I looked at the class, maybe my company will pay for me to go.

I also went looking for the zero, and low coupling messages.  Looks like my solution is within the abstract messages.  I am trying to find an example of using this(I jive well with examples).  One guy mentions the 'shipping' example which I cannot seem to find, not sure if anyone knows.  When I google I get daqmx shipping examples.

I would like to add something - I am thinking of adding a notifier to my actors.  I honestly feel like sending messages is a little overkill, not to mention I am worried that if it is burred in the Queue I won't get it in time/use old values.  A notifier will allow me to query the state of my actor without having to build a message up.  Every time I create an actor, I am required to have not only the enqueuer but also a notifier.

You actually answered my 3rd question when you answered my 2nd - my third question  was basically can I use helper loops?  However it does seem I have one loop be a state machine loop - this is true in that first architecture i described.  I give the Actor basically a reference to that state machines message Q and use that message Q to send messages from the actor methods back into the state machine helper loop.  The helper loop of course can communicate back via self enqueued messages.

[Taggart]

I would recommend against the notifier.  I recommend sticking to the standard patterns for 2  reasons.  a. they've been tested and work and b. when you hand it off to someone else, if its one of the standard patterns, they will be able to understand it.

That said, I feel like there's probably a very good reason not to do the notifier...I think you are going to run  into some issues... Perhaps AQ or Allen can point to exactly why, but it doesn't seem to jive with the actor model. You should only be able to interact with your actor through messages.  Notifier seems like adding another channel and it would break that.

Also If you are doing a state machine helper loop, you might look at the State Pattern Actor.

[MrShawn]

I am not disagreeing with what you said about the notifier.

When I consider my C++ code I can easily generate an asynchronous object and can call public methods of that object and get values from it.  

I struggle to find a way to do this in LV.  From what I have found besides using reference based OOP - AF is basically my solution, except I can't 'read' values from the actor how I would like.  I think the notifier for reading would be the 'safest' and most simple solution i can think of to give me the reading on demand functionality I desire.

[Taggart]

Well from your previous posts, I assumed that you had some kind of other kind of object-oriented programming background.   I don't do C++ but I've read enough books where they use C++ for example code and I can see exactly what you mean.

So the AF in general is not really designed for this idea of request/response.  Everything is by design asynchronous.  Actor A sends Actor B a message, but instead of waiting for a response, A just continues doing what it is doing and at some point B may send a message in response.  I think of it as delegation within a company.  If you are the CEO and you delegate a task such as write me a report on this topic, to someone (equate that to sending a message to another actor), you don't sit there and wait until they are done with the report.  You continue what you are doing and at somepoint they will get back to you.  So that is the general paradigm.

If you really want to get a reply (again I recommend sticking with the normal conventions), checkout the AF Advanced pallette.  You need to make your message inherit from reply message.   NOTE: Instead of your notifier, this uses a queue (I'm not quite sure why that is.  Allen or AQ would probably know).  But it's basically the same as your idea, although the return queue is part of the reply message, not the actor.  It's a little cleaner. If you are going to use replies, I recommend you use this method.  At least you are not reinventing the wheel.

The main reason for the convention is to avoid potential deadlocks, so be careful...

[Taggart]

oh and for the shipping example:

from the Getting Started Window -> Create Project.  Select the "Evaporative Cooler Project"...

I know... It's not labelled as the AF shipping example...

[Oli_Wachno]

---

@Taggart wrote:
...

If you really want to get a reply (again I recommend sticking with the normal conventions), checkout the AF Advanced pallette.  You need to make your message inherit from reply message.   NOTE: Instead of your notifier, this uses a queue (I'm not quite sure why that is.  Allen or AQ would probably know).  But it's basically the same as your idea, although the return queue is part of the reply message, not the actor.  It's a little cleaner. If you are going to use replies, I recommend you use this method.  At least you are not reinventing the wheel.

The main reason for the convention is to avoid potential deadlocks, so be careful...

---

I second Taggart. If you really need synchronous messaging, I also recommend the build in Reply Message. This keeps your debugging efforts to resolving deadlocks within the application instead of also an own implementation

Concerning clogging the message queue: as long as you stick to the paradigm of delegating time-consuming tasks to a helper loop, you should not run into an issue like this.

[Oli_Wachno]

---

@Taggart wrote:
...
NOTE: Instead of your notifier, this uses a queue (I'm not quite sure why that is.  Allen or AQ would probably know). 

---

My guess is that a queue as a means of point-to-point communication is better suited for a point-to-point message than a point-to-multi-point communication like the notifier.

[MrShawn]

I have actually used the reply message in some cases but that is truly synchronous.  

I want to maintain asynchronous functionality but going from my nested actor back through the AF QMH and then back into the helper loops seems like a lot when the actor primarily exists within the scope of the helper loop already.  The helper loop spawned the actor(s) and is the one sending the actor(s) the messages - why shouldn't my helper have direct access to return values.  My notifier would give me that capability, and I would hold that notifier only within the helper loop.  If I take that information from the helper loop back to AF QMH or another actor I would then pass via a message to its desired location.  

I was looking at that coffee shop example and they had these worker actors or something.  At first I was thinking that that was silly - but I am wondering if I should make that helper loop into a worker actor (problem with that is I now have to work harder to get back to my FP).  Another option would be to downgrade some of my actors to regular 'classes' and just do more reference based and spawn them asynchronously.

I got back to my work computer so I can finally look at that example and see whats going on with those abstract messages.  

The AF is really some cool stuff - thanks for the help guys.