LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Facts and opinions on the Actor Framework as a LabVIEW add-on

Solved!
Go to solution

I am researching LabVIEW framework add-ons to help our group choose one for all future projects.  Below I've listed facts and opinions about the NI Actor Framework as "feature: value" pairs that I've found online from multiple resources.  I'd be happy to consider any informed contribution to feature values that are missing (marked by "?") or that you find inaccurate.

Paradigm: Queue-Driven State Machine
Brief description: State Machine is replaced by instances and inheritance of "Actor" class enabling extension without modification
Released: 2011
Data and messages: Handled together or separately?
Messaging model: Hierarchical Tree Structure (some parent/Child restrictions)
Message type safety: type-safe messages imposing assorted levels of coupling
Priority enqueuing: Yes, 3 priority levels
Subscription to messages: Yes
Data formatting: text, clusters?
Special error handling features: ?
Debugging tools: Trace tool often unavailable due to reentrancy
Compatibility with TestStand: poor
Documentation: Good

Message 1 of 18
(16,808 Views)

(As a disbeliever, still) a big advantage of AF would be that it ships with LabVIEW.

 

This also implies (at least near) future compatibility and maintenance. 

0 Kudos
Message 2 of 18
(16,764 Views)

@skinnedknuckles wrote:

I am researching LabVIEW framework add-ons to help our group choose one for all future projects.


I would advise against this.  Don't be dogmatic in a framework.  I've seen too many applications become WAY too complicated trying to fit into a framework when a simple single loop with an Event Structure would do the job (I may be slightly exaggerating here, but the point is still valid).  Learn many frameworks/architectures and figure out which one fits best with the project requirements.

 

Going through your list, I'm not sure you actually understand how the Actor Framework works.  Your messages are objects.  And each of those messages has a "Do" method that the message handler calls.

 

I am personally not a fan of Actor Framework.  I think it is too OO heavy and it takes a lot of VIs to do something.  But I also know lots of people who are extremely successful with it.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 3 of 18
(16,733 Views)

I've only dabbled with Actor on a few shared development projects and am neither an expert nor a particular fan.  

 

That said, I would very strongly advise you that the brief summary list you've started will BY NO MEANS provide clarity for making a good architectural decision.  You're marching down the wrong path if you're hoping that a.list of characteristics will be a good basis for deciding.

 

I'm not prepared to tell you what to decide or how, except that a list like that is definitely NOT the way.

 

 

-Kevin P

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 18
(16,699 Views)

Perhaps I should have been more explicit.  I've been told to choose a framework for projects with sufficient size and complexity to benefit from the use of a framework.  I'm well acquainted with OOP and understand the Actor Framework well enough.  I'm almost certain we will choose Aloha, DQMH or JKI State Machine rather than the Actor Framework but I'm including AF in my research and presentation because it has been used extensively and represents one extreme of the "ease of learning/capabilities" continuum in my view.

0 Kudos
Message 5 of 18
(16,650 Views)

@skinnedknuckles wrote:

Perhaps I should have been more explicit.  I've been told to choose a framework for projects with sufficient size and complexity to benefit from the use of a framework.  I'm well acquainted with OOP and understand the Actor Framework well enough.  I'm almost certain we will choose Aloha, DQMH or JKI State Machine rather than the Actor Framework but I'm including AF in my research and presentation because it has been used extensively and represents one extreme of the "ease of learning/capabilities" continuum in my view.


In a way that is like asking to pick a vehicle for all future transportation. You can't practically go to the market in a rocket, you'll never reach the moon by foot.

 

I do understand why you'd try to do that. I wouldn't and I'm glad I don't have to 😂.

 

If the comment "NOTE: This version of ALOHA does not support building EXEs." (found here) is still accurate text, I would avoid Aloha.

 

AFAIC, ALOHA and AF (modular) solve different problems than DQMH and JKISM (application logic). You can reach the same goals if you're careful, but their intent seems different to me.

 

If you'd blindly use DQMH or JKISM to make an application, most logic will live in the architecture. Very convenient, but harder to reuse. Of course you can avoid that by forcing loosely coupled code, but with AF and ALOHA you'd be more or less forced to do this. At the expense of a more rigid design philosophy.

 

Both not only have advantages and disadvantages, but what actually is an advantage or disadvantage is highly circumstantial and could even change over time.

 

I'd use these kind of considerations to make a choice.

 

Take a few typical applications, and (on paper, hypothetical or for real) try which strategy gives you the most short and long time benefits.

0 Kudos
Message 6 of 18
(16,630 Views)
Solution
Accepted by skinnedknuckles

Here's a poll I made a few years ago on Frameworks: https://lavag.org/topic/21199-poll-on-architecture-and-frameworks/

 

This suggests, by popularity, you consider AF and DQMH first.  I could make some arguement that my Messenger Library is more popular than Aloha, though I haven't kept up with that framework.  

 

I actually have the opposite opinion on choosing different frameworks for different jobs.  All these frameworks are essentially trying to solve the same problem, and all have significant learning curves making it expensive to master multiple of them.  It is more important to master one, even if that is not the best one, then it is to identify the very best one. 

 

Though, if you're asking, the very best one is Messenger Library.

Message 7 of 18
(16,624 Views)

@drjdpowell wrote:

I actually have the opposite opinion on choosing different frameworks for different jobs.  All these frameworks are essentially trying to solve the same problem, and all have significant learning curves making it expensive to master multiple of them.  It is more important to master one, even if that is not the best one, then it is to identify the very best one. 

I do agree that once you're committing to a strategy (framework or not) there should be a bias towards using it.

 

At some point somewhere there was a commitment to using a producer\consumer as a template. Even the about was implemented as a P\C. That's too much for me. The entire hierarchy of structures could be replaced by one event structure, no loop. 

 


@drjdpowell wrote:

Though, if you're asking, the very best one is Messenger Library.


That's not a framework though 😋.

 

Using the right tools\libraries and common sense would be my preferred strategy. The right tool could mean AF if you need a lot of actors, (D)QMH if you need a QMH and\or P\C, SM, MS, or whatever if you need one of those.

 

George Box's law seems somewhat appropriate: All models are wrong (EDIT, but some are useful) - Wikipedia

0 Kudos
Message 8 of 18
(16,621 Views)

If you have been using DQMH and "need lots of actors", then use lots of DQMH modules.  If you are experienced with the AF and "need a QMH", well you are in luck because AF actors are Queued Message Handlers.  The other things you mention are either patterns that can easily be implemented with queued message Handlers, or, in the case of a true State Machine, something independent (as in, one can make an actor/module act as a Finite State Machine).

0 Kudos
Message 9 of 18
(16,596 Views)

I've noticed that each Framework is based on one or more fundamental software design patterns including: singleton, factory, producer/consumer and state machine.  The 7 Most Important Software Design Patterns 

 

Yes, the Actor Framework is a queued message handler and likewise anyone who wants to implement more OOP features with DQMH can add more classes as templates.  Or they could use the JKI State Machine Object (SMO) which implements OOP.  So like many things in life these are not "either or" options and there is no "one best option" for every task and person.  But given the oodles of hours I'll invest learning at least one of these tools, I thought time spent understanding and comparing them was worth the investment.

0 Kudos
Message 10 of 18
(16,574 Views)