Thoughts on Launching actors from non root actor code

[A Scottish moose]

Hello everyone,

TL;DR - Any thoughts on if it's a good or bad idea to spin off an actor from a QMH framework?  I've got some library code that would be valuable but the project itself doesn't justify AF.

I'm brainstorming ideas for a tester that I'll be building over the next few months. The project that I'm currently winding down is an Actor Framework test system that has come out really nice. Part of the project was an actor built to handle all of the DAQ and digital control.  The main actor spins it off an tells it when and what tasks to launch.  It send back data and confirms commands, uses Dynamic events to keep up with the generated signals, and uses actor tasks to ship the data back to the controller.  Works amazing. Nothing revolutionary for sure but very handy.

This next project doesn't really need actor framework, it's much smaller and has a lot smaller list of requirements.  That being said I'm curious about integrating my DAQ actor (Dactor, because who can resist an amalgamation?!) into the project. Any thoughts on if it's a good or bad idea to spin off an actor from a QMH framework?  Is this even possible based on how the AF tree is designed to work?

Thanks for reading!

Tim

 

[hooovahh]

I never liked an actor design that didn't allow for an actor to run without the rest of the application.  It just makes it so much easier to be able to develop and troubleshoot an actor when you can run that actor as non-reentrant and have it work without needing the rest of the frame work.  I'm sorry that doesn't answer your situation, but in my actor design an actor can just be ran in parallel with the normal code, and it will publish it's data, and subscribe to user events (including quit).  It won't have any application wide config information but I just have it default to something if the rest of the application can't be found.  In this case actors written for the large application, can be copied to a new project and called like any normal subVI.  Modularity and reusability.

[drjdpowell]

It seems strange that you feel your current Actor Framework project has "come out really nice", yet you don't want to use it in your next project because it "doesn't really need it".

[Neil Pate]

After making the switch to all "modules" launched dynamically about five years ago I really cannot imagine now not using my home grown "actor framework" for all projects, regardless of their size. There is just so much good stuff I would have to recode.

I cannot speak for the actual Actor Framework though; I never really liked the architecture enough to invest the time in. However watching it from the wings for the last seven or eight year has not really made me think I made the wrong decision.