Jump to content

Thoughts on Launching actors from non root actor code

Recommended Posts

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!



Link to post

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.

Link to post

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.

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By ACS
      Here's a heads-up for any LabVIEW developers in Central Texas, or any Certified LabVIEW Architects coming to Austin for the CLA Summit next month.  I will be teaching Actor-Oriented Design in LabVIEW, Sept. 13th - 15th, in the training center at NI's corporate headquarters.  Come take the class, enjoy Austin for the weekend, and stay over for the Summit! Details on the course offering here:
      Actor-Oriented Design in LabVIEW
      There are offerings in October as well, in MI, MA, and Santa Clara, if those locations are more convenient.
    • By QueueYueue
      I've made some pretty cool changes to Monitored Actor that help expand it's capabilities. The main being the ability to override the UI. This lets you do cool things like create a web based actor monitor, or run the monitor window in the runtime environment. I also added Actor Labels to help you identify running actors.

      Check out our Monitored Actor 2.0 article for more info!
      If you're at NI week, be sure to checkout the presentation by Brandon Steele on Thursday (1:30 in room 16B). He'll be covering the Monitored Actor as well as some other tips for developers of large application (like MGI Solution Explorer, Class Method Browser and Actor Framework Message Maker)
    • By chrisempson
      Hi, I'm writing a LabVIEW application using the Actor Framework. This is the first time that I have used the framework and I need some advice regarding application architecture. My apologies if this is a basic question!


      How is a settings dialog box best implemented? In the past in non-Actor Framework applications I have loaded the configuration from a functional global variable, displayed the settings dialog, then written the updated settings back to the functional global. I'm not sure this would work correctly (or optimally) within the context of the Actor Framework, though. 


      My application uses the template generated by Create Project -> Actor Framework. The top-level Actor manages the user interface. Two child Actors control separate pieces of hardware. The top-level actor must read a saved configuration from an INI file when the application starts, and save the final configuration back to the INI file on exit.


      Instinctively I think it would be best for each child actor to maintain its own settings, as a cluster in its class private data. Ideally I don't want to have to keep a separate instance of the two clusters of settings in the top-level Actor's private data in order to populate a settings dialog; this duplication seems unnecessary.


      The only way I can think of to make this work is as follows.


      At application start

      1. Top-level Actor reads settings from INI file.

      2. Send messages to both child actors with the new settings, and tell them to apply those settings to their private data.

      3. Each child Actor should respond to acknowledge that the private data has been updated.


      To update the settings using a dialog box

      1. Send a message from the top-level Actor to each child Actor to ask them to send their settings to the top-level Actor.

      2. Wait for both child Actors to reply.

      3. Display the dialog box.

      4. If the user clicked 'Ok' and not 'Cancel', send messages to both actors with the new settings, and tell them to apply those settings to their private data.

      5. Each child Actor should respond to acknowledge that the private data has been updated.


      On exit

      1. Send a message from the top-level Actor to each child Actor to ask them to send their settings to the top-level Actor.

      2. Wait for both child Actors to reply.

      3. The top-level Actor writes the settings to the INI file.


      This doesn't seem like a sensible approach, though. Waiting for message replies sounds like the wrong thing to do. I wouldn't know where in the block diagram to implement this scheme, either.


      Can anyone offer me any advice? There must be a fairly standard way of doing this that I'm missing!


      Thanks in advance,




      Dr. Chris Empson

      Robot Screening and Instrumentation Specialist

      School of Chemistry

      University of Leeds




    • By LewisG
      I have to develop an application and I would like some help designing the architecture.
      The system controls a number of pumps and valves to create flow around a network of pipes.  There are flow meters in the network which are used as feedback for PID to maintain a flow.  The network of pipes is gradually opened up to get flow and then PID kicks in to maintain a flow.  The test sequence is pretty much a big state machine.  For example:
      1.       Open valve 1
      2.       Wait for pressure to build
      3.       Ensure temperature is not over limit
      4.       Etc
      I will have a number of different screens which I want to load into a main sub-panel:
      ·         Main SCADA screen (show state of all valves pumps etc)
      ·         Test setup screen (configure tests)
      ·         I/O screen
      ·         Alarm screen
      I will also have a number of I/O processes:
      ·         Digital (valve sates)
      ·         Analogue (flow meters, temperature etc)
      ·         Modbus and serial devices (flow meters)
      ·         Digital Output – Valves etc
      ·         Analogue  - Proportional valves
      I want to use the Actor Framework because I’ve used it 3 times now and it is easy to spawn processes, make popups, inter-process messaging, error handling etc.  I can have all my processes separate (high cohesion) with separate user interfaces (if they have a UI) .
      My problem is that AF and State machines don’t really go that well together (correct me if I’m wrong).
      What happens when I want to do PID or loop in the same state?
      Time delayed message?
      A a VI for each state and enqueue the next or same state from within that VI?
      Does anybody know a good way to incorporate a state machine into AF or should I chose a different way of doing things?
      Any thoughts will be appreciated.
    • By Mike Le
      I was debugging an application today and tracked it down to an error being passed directly into Actor Core from an initialization method upstream.
      I had expected the error on occasion and have a case in my Handle Error override to display a front panel warning to the user.
      My oversight was thinking that Actor Core would call Handle Error if an error was passed directly into it. This isn't the case, of course: it skips running any of its code and passes the error straight through.
      Should an error passed into Actor Core call Handle Error? I assume this was considered and discarded for some reason. Anyone have any insight as to why?
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.