A POSITIVE DISCUSSION on the ACTOR FRAMEWORK

[Q7]

I just though it might be swell to have a thread discussing some of the great benefits and applications the AF lends itself to. Enough people are now developing with the AF that we might learn something from them. Please chime in with your experiences, in our world the positive is always hidden beneath layers of minor bugs and problems. Please leave most of those for another thread.

My first application has been an adventure that lead to more 4AM nights than I would have ever imagined. Ultimately, though, I love the outcome. I realized this on my way to Tokyo 3 weeks ago when I discovered the reason my heater relays were not activating properly. On the plane I was able to open up LV2011 and not only fix that issue quickly but make a complete change to the way all my PID processes were running. By simply having a set of messages all my "model" actors could use relating to PID and by placing a PID method into a parent of those models it was incredible easy to implement a big change. I know you could do this with LVOOP and another messaging system but it seems more elegant with the AF.

Another great benefit I have found with it is actually in the project tree. At first the messages and classes were confusing and hard to follow but with time and some reorganizing of my virtual folders I know have a very clean and self-descriptive project window. I can scan down the tree and see all the actions any given hierarchy might take and can easily pull up and change a message or an actor method.

The AF is young and still has some performance issues to be sure. Many of them might be deeper problems brought to light by the way the AF uses LVOOP and references. I welcome the changes though and truly believe this is making LabView a language for exceedingly complex systems. I was a relative novice before delving into this. I am a bio-engineer by degree and my LabView experience was without much use of references, messaging, queues, and absolutely zero LVOOP before using first Daklu's excellent LapDog and then AQ's Actor Framework v3. The learning curve has been steep but well worth it and I think anybody with a decent engineering skillset can accomplish great things in short order. My first day with the AF was in January 2012 and now I have fairly complex instruments deployed and running the applications worldwide. They will need refining as does most any modern software but they work robustly and I can depend on them to perform exactly as commanded (once the UIs were compiled successfully!).

That's my long-winded Friday contribution. Hope it convinces somebody else to share or experiment with the Actor Framework. Good Stuff Getting Better!

[Daklu]

I agree maintaining an actor-oriented application is easier once you learn techniques such as reliably shutting down actors and message exchange sequences.  I'm especially glad NI is making a push to promote better system architectures by providing a good framework and developer support.  The AF is a bit too heavy for me personally, but the lessons learned by using it can be applied anywhere in your code.

[Q7]

Great, so the only other guy with something to say doesn't even use the AF. Promising!

[lukepike]

I'll say something. The thing I like the most about the actor framework is that if I need to share data with different parts of my application, I don't have to create a notifier/queue everytime and manage their lifetime and who controls them.

Many times my application is forced to change because the customer wants to see some data on a screen that has nothing to do with the producer of that data. Before, I'd have to create a notifier or queue and either share the wire (which can make things really messy) or give them a name (which means anyone could destroy the reference at the wrong time). Now, there's nothing to it. Give the data source a list of message queues and everyone who needs it gets the data.

Another thing I like is that I know where to look when there are problems. Degugging code that shares responsibilities with other sections of code is the pits to debug, because the bug could be in many places (or all of them!). With the actor framework, each actor is responsible for it's task, so all the code is in the actor class and any messages it recieves. No more digging through levels and levels of VIs. Communication bugs are also easy to fix because the relationships are well defined (anyone with the message queue to an actor).

There are probably a host of other small blessings that I'm not covering, but those are the biggies. Thanks AristosQueue and others who worked on this for a great framework!

Luke

[KuGr]

OK jbjorlie.  Here is another...

Three years ago when I started my current position, I had not used LV in about 20 years and then it was for one project.  I developed in text based languages like C++ etc and almost exclusively object oriented but not data flow.  So, in one respect I was ahead of the game, in another it was a learning curve.  In my review of LV projects completed here, I found

    No object oriented.

    No event driven  - polling loops, sometimes without any delays.

    Data shared through globals.

    HUGE top level VIs with lots of loops.

    Very little code reuse - more copy that vi and reuse, perhaps modify first, worse just rename.

Fortunately, LV was not my only development environment and I could feel all warm and fuzzy in my Visual Studio world.  But I was still looking for some LV framework to get this organization out of the programming dark ages.  On LAVA there was lots of discussion and one day around NIWeek 2010 (I did not attend), I stumbled on AQ's LabVIEW CLasses: The State of the Art (https://decibel.ni.com/content/docs/DOC-12737). That is where it all began.  A framework that was generated by NI that I thought could solve all of my problems. And what made me most happy was that it is OO.  My number one item satisfied.  I was used to Windows messaging and I could see how I could use AF Messages as events.  I could transfer data between Actors and there would be lots of little VIs doing the work.  Many of them identical to each other.  I was in programming nirvana!

After nearly 2 years (and counting) of creating a framework derived from AF, I have four systems built with it.  One of my colleagues has started using it - so there is hope for this organization.  A new hire will start soon and he will be assimilated before the others can touch him .

My framework continues to evolve, but I have not needed to change the AF core.  I have had the opportunity to use LV2012 Beta and actually back-port to see if my framework would still function and it did, though I am sure I had to change some things but as I cannot recall anything specific, it must have been reasonably painless.

There are other approaches to solve this problem.  Daklu has one (part of LapDog), Justin Goeres of JKI presented one at NIweek2011, among others.  All are worthy of consideration.  I just saw this one first and kept with it.

Finally, a small plug for NIWeek... Come to NIWeek 2012!

Kurt