At the beginning of 2000 I programmed software for processing medical image data with labVIEW and imag Vision. The program is classically structured as an event-driven consumer producer design pattern. Asynchronous messages are transferred to different subVIs and processed with queues, notifiers and GOOP 3 classes. As you can see in the picture, there are many windows that receive messages and return them to the main VI. It is now difficult to develop the code further.
I now have some experience with LVOOP, but would like to reprogram the program with an LV framework.
I think the Actor Framework would certainly fit very well here.
I'm in the process of learning AF now. I wanted to work through the hands-on course, but unfortunately the VI "Launch-Actor.vi" is no longer supported by LabVIEW 2019. (Simple Actor Example). Do you have a tip how I can replace the VI?
A general question? Would you rather recommend the Actor Framework or the DQMH Framework? In any case, reprogramming is a lot of work, but I think it's worth it.
I would be really happy for your help.
Solved! Go to Solution.
That program looks awesome, especially if it's from the early 2000s!
The original Actor Framework only had "Launch Actor", but it was a bit complicated to correctly launch an Actor, because there was extra bookkeeping to do setting up the queues.
So they deprecated "Launch Actor" (as you see) and replaced it with 2 new VIs:
"Launch Root Actor" for the top Actor in your tree (usually it's some main controller).
"Launch Nested Actor" for any children launched by your Root Actor (or its children).
The main benefits are that it's easier to launch your Root Actor, and each Actor tracks it's Nested Actors. So if you send a "Stop" message, it will propagate to all Nested Actors. It cuts down on accidental zombie Actors (those whose parent actor stopped without telling children to stop).
Yes, I only updated VIs, such as "Open Config Data.vi" ... or added new buttons from the silver palette. The windows were generated dynamically via VI server and templates (* .vit). There were always new functions added, which unfortunately always involved work.
As for the Actor Framework:
I can't easily replace "Launch Actor" with "Launch Root Actor" or "Launch Nested Actor" (see attached screenshots from "Simple Actor Example.vi" and from the Hands-on course "Water Level Test.vi").
There is still some extra programming work to be done, right?
Can you give me a tip what to do. Thanks! 🙂
Are you using the examples from here: https://forums.ni.com/t5/Actor-Framework-Documents/Hands-On-Actor-Framework/ta-p/3511540?
I'd suggest perhaps looking instead at the examples that Stefan wrote at this forum link: Actor Framework from basic to PPL plugins, which is a bit newer and has more up-to-date examples.
Allen C Smith (ACS, the author in the first link) has also given recent presentations on a variety of Actor Framework topics, so some of those might give you pointers (although they aren't hands-on examples in the same way).
Tom McQuillan also has a (very, in a LabVIEW-scoped sense) popular Youtube channel discussing Actor Framework. I haven't seen the videos (because I generally prefer to read introductory materials than watch them) but he knows a lot about AF 🙂 https://www.youtube.com/watch?v=2k3ZDwJolbA&list=PLmF-6jvwRvVNFzBjzh4bQDjFbv6lShcth
I took a look at modifying the examples I downloaded from the first link (they looked similar to what you posted images of), but frankly I think you'll spend more time worrying about how to map from old to new than learning about what the "new" (as of maybe 2014? guessing somewhat wildly, I'm not sure the actual date) method is.
Launch Actor.vi is deprecated, but isn't going to be removed from the framework. It remains useful the kinds of test harnesses shown in the hands-on exercise, and in unit testing, where you need to be able to receive messages from the actor you launched. For production code, though, you should switch over to Launch Root/Nested Actor.vi.
You don't have to provide a message queue with either of those two VIs. Launch Root Actor just sets up a dummy queue - your root actor has no caller, so you don't need a queue. Launch Nested Actor is a method on the calling actor, and does the work of providing the nested with its caller's queue. In normal AF code, then, you never set up a message queue, and you only ever use it when you wire an enqueuer to a message's Send VI.
If you can, look into taking Actor-Oriented Design in LabVIEW, NI's course on the Actor Framework. It will clear up a lot of your questions. It's not offered in the regular rotation, though. It gets taught on request, when we get enough students who are interested. PM me if you need help in that regard.
As for which to use, AF or DQMH, the answer is a resounding "it depends." If you are comfortable with the existing QMH template that ships with LabVIEW, the transition to DQMH is pretty easy. All it really does is add a standardized messaging system based on user events, tools to implement those messages, and other productivity aids. It's pretty popular for that reason. It's going to be a pretty solid choice for systems with 3 - 7 actors, or if you work a lot with TestStand. It has some down checks, though. All of the actor loops run in the UI thread, which is a potential performance issue, all of the messages are broadcast (though I'll confess that many consider that a feature), and access to the actors is essentially global. There's another handful of things I don't care for, mostly because I don't think they scale well. That said, I think most developers would go quite a while before those things became an issue for them.
AF is more complex, but more feature-rich, and more amenable to scaling. DQMH uses OO, but DQMH users don't have to. AF, by contrast, is OO all the way. This lets you do things like build a complex actor through inheritance, where each layer implements fairly simple behavior, and those simple layers can be reused. AF also naturally supports a deeper application structure (actors calling actors to make subsystems). You can do that in DQMH, but you do more of the work. AF is competitive with DQMH in the 3 - 7 actor space, and you can take it further.
Now, in the interest of full disclosure, let me just say that I have *years* of development experience with AF, whereas I've only looked at DQMH and talked to some of its users. But I don't think Fab would disagree with my assessment here. As in all things, your mileage may vary.
Thanks a lot cbutcher.
I'd better accept your suggestion and work through Stefan's examples (Actor Framework from basic to PPL plugins).
Tom McQuillan's videos have already been of great help to me with LVOOP.
His tutorials are really great! I will also check out the AL tutorials.Actor Framework from basic to PPL plugins.
There are a few instructors in Europe for that course. Tom McQuillan is one of them, and I think Peter Horn still teaches it in the UK. It's available as a virtual instructor-led course now, as well, and NI is only offering virtual courses this year.
If you find me, Tom, or Peter on LinkedIn, we can try to let you know when we're offering courses. Tom and Peter are in Europe, and I'm in the US, so you might find their teaching hours a bit more convenient.
I have now made my first attempts with the Actor Framework.
And thanks to the video tutorial by Tom McQuillan (Tom's LabVIEW Adventure)!!!
I was able to achieve initial successes.
I am currently trying to write a small program that, in simplified form, contains all the essential functions for the image processing program.
I'm sure I have a question or two about that.
I will then publish the test program here.
It may also be of interest to other AF beginners.
Thanks for your help!