3 Questions on AF

[drjdpowell]

---

@MrShawn wrote:

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.

---

Note: the AF is an implementation of the Actor Model, which is not necessarily the same as an "asynchronous object".  A C++ analogous framework is CAF.  If you wanted a non-actor async object in LabVIEW, you might try using an Async Call to create a background process and share data with it using a DVR (could also use a Notifier).

[MrShawn]

Yessir, I was thinking of taking that approach.  As my understanding of things mature it becomes clear that perhaps some of my 'actors' shouldn't be actors but rather just a regular asynch object.

[Taggart]

---

wrote: 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.

---

That makes perfect sense.

[Taggart]

---

@MrShawn wrote:

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 recommendation would be that if your helper loop needs to spawn nested actors, that you send the actor a message and let it spawn the nested actors.  This lets the nested actor get its caller's enqueuer for returning data and you can also take advantage of the automatic shutdown.

I also recommend that you don't share that enqueuer with the helper loop and send everything back through the actor core. Yes I realize that is more work, but I feel like it makes for much easier debugging.  

[Taggart]

I'm not sure exactly what problem you are trying to solve, but this might be useful

https://lavag.org/files/file/95-by-ref-active-object-framework/

[Eric.M]

Maybe a dumb question but what is the lifetime of your "async objects"? Is it finite (like, a long computation that you want to parallelize, connecting to a server/database...) or continuous threads?

In the first case, you may want to use the Last Ack message if you're using AF, or "simple" dynamic VI calls using the Call and Collect pattern if you want to stick more to the async object/ background worker concept.

Make sure you have a valid reason to create async components. LabVIEW makes it easy to create parallel processes, and nowadays developers tend to overusing parallelism even when the problem is simple (also valid in many areas like mobile programming or Node.js or other event-based programming languages — we're not alone it this async world)

[MrShawn]

For now I have two actors that I have seriously developed and a third that still needs to be worked on.

One really is the top level actor (that I have set up to in theory be a nested one as well)  this handles the core of the program which displays production data from the database for multiple sites on the floor.  The other actor handles only database interaction.  It is the select messages that I force to be asynch with the return message because I want that data right after I make the call.  I am experimenting with other methods of achieving this but for now that is doing to trick.  Eventually I will need that database actor to run some batch commands and i want that in the background (a good candidate for actor I think).

My third one I am still working on is an actor that handles an IAI MSEL multiaxis controller I have the communication down but I need to get the methods to make it versatile and usable.  The above actor also uses the SQL one because I want to allow the other non-programming engineers access to troubleshoot some of the messaging(to controller) components without me if needed.  I want that asynch as well because eventually I will be managing other actuators and electrical equipment that are making measurements and sensors on the machine as well.  Plus I need user interface on this(multiple depths of user interface VIs).  That will be a multi actor/object project for sure.  I just started a few months ago they want me to use labview so I am learning.  Plus my first job so we gotta nail that.

Also I have been looking at ref based OOP stuff and also download that ADDQ G# on the VIPM to check that out.  They didn't have an asynch example in my look through so if I took that approach id have to add that in there.

[MrShawn]

also I do give the enqueuer to the actor core for the exact reason you mentioned, to propagate the shutdowns.