This is the Actor Framework hands-on session we presented at NIWeek 2012. This self-guided exercise takes you through the process of building a small working application in Actor Framework. It takes about 2 - 3 hours to complete the material.
We recommend that you watch the Introduction to Actor Framework webcast (http://zone.ni.com/wv/app/doc/p/id/wv-3101) prior to working this example.
Thanks AQ, could you post it for LV 2011?
Umm, actually, I started this topic...
I'll see what I can do, but it might be a while. I need to backport the example and solution, and AF 4.0 is not compatible with 3.0.7. There will be some discrepancies in the manual.
AF 4.1 for LV2011 is compatible with AF 4.0 for LV2012, though.
Ah, good point. The backport should be easy, then.
Has anyone had a chance to port this to 2011 sp1 running the 4.1 framework? I would love to look at this example.
I'm running through this example (downloaded 2012 evaluation until our disks come in) and I'm playing around with the Simple actor example. I'm curious if this is a side effect of the actor framework or an older computer, however, when i spawn 50+ actors, the messaging become extremely delayed. I am unable to stop individual processes, zero all actors or any of the control options without an extreme delay. Is there an inherent limitation to number of actors you can message with this framework quickly? MY cpu usages is still around 50% so i don't believe i am overtaxing my system.
I'm curious, as i was looking towards to the actor framework for use in a larger system.
We are not aware of any limitation in the framework, but there may well be one with the example. I didn't test the simple example with more than about four UIs. I went back and tried working with 50 UIs, and I do see the problem you are experiencing. I'll take a look at it.
Edit: It is definitely an issue with this example. If you back off the update rate on the UIs to 250 ms, or send the reset messages as high priority, the demo gets much more responsive. As I suspected, it's not the messaging, but something in the update methods that takes longer than 100 ms to complete. Update messages are stacking up, and the reset and stop messages get delayed. I'll run that down tomorrow.
Edit: The issue is with updating the gauges on the UIs, which happens in Simple Actor.lvclass:Update.vi. That mechanism is serialized somehow. Each call to the property node takes some period of time, and each must wait for all of the other calls to the property node that are currently pending. When you stack up 50 such calls (because you have 50 panels open), the total time takes more than 100 ms. Since the update messages are being sent at a constant rate of 100 ms, the messages are stacking up in the actors' queues. The other messages you are trying to send (zero or stop) have to wait their turn. So, not a problem with the framework per se, but if you are sending messages faster than you can process them, you will bog down your actor. This is true for any prodcuer-consumer pattern.
It's a simple demo. I never intended it to run with more than a handful of panels open at once.
This is a very good example to get started with AF! it helped me a lot Thanks!
I prepared an hands-on tutorial Introduction to LVOOP and the NI Actor Framework implementing a simple UPN-Calculator.
It contains talk and manual in german and english language. It is published on github, https://github.com/HB-GSI/Calculator.
Best regards Holger
I am going through the AF hands-on. It is helping a lot, but I ran into something I think is a mistake in the training. Or I am missing the concept completely
Start with the pdf. See on page 18. Section 4. It describes the Dual Fan controller as follows:
Dual Fan is a concrete implementation of a Timed Loop Controller. It manages the I/O and logic operations to control a pair of fans (primary and backup) and respond to hardware faults. When Dual Fan is off, both fans are idle. When Dual Fan is on, the following rules apply:
If no fan faults are detected, turning on Dual Fan starts Fan A.
If a fan fault is detected for a running fan, Dual Fan will stop the faulted fan and attempt to start the other fan.
If both fan faults are detected, Dual Fan will stop both fans.
If the fan is on and both fans are faulty, as soon as one is fixed, that one will start running.
Now, open the solution.
Open "Simulation Data_Global.vi"
Open "State Logic.vi" under Dual Fan
Launch and Run "Dual Fan Test.vi"
My problem comes when playing around with this test vi. There are two different issues I see with this code:
1. There is no awareness of Power On or Off in the Update or State Logic vi. This means it is possible to enable a fan after calling a Power Off. Try this: Disable Fan State, Disable both Faults, then enable eithe Fault. A fan will turn on.
2. Also, when Powered On, the State Logic does not behave correctly when transitioning from a Fault to No Fault state on either fan. Try this: Enable Fan State, Enable Fan Fault A, Enable Fan Fault B, then Disable Fan Fault A. You would expect Fan A to kick back on, but it does not due to the State Logic.
If this is expected, I would love to hear why. If not, apologies if this was already documented somewhere. I'd be interested in seeing a corrected solution. My guess is that it would include updating State Logic and adding a state boolean to DualFan.ctl.
I see the same thing you pointed out. My understanding is: it is due to the global variables the actors are using. When you change those global variables in "simulation Data_Global.vi", it just triggerd State Logic.vi and Update, the Power on/off was just bypassed.
pflores wrote:1. There is no awareness of Power On or Off in the Update or State Logic vi. This means it is possible to enable a fan after calling a Power Off. Try this: Disable Fan State, Disable both Faults, then enable eithe Fault. A fan will turn on.
It does seem like a bug. No, I haven't seen this reported anywhere before.
Thanks for posting this. I'm working with CustEd on a formal AF course, and we're going to give the hands-on a bit of an overhaul sometime in the next few months. I'll address these issues at that time.
Page 17 of the Actor Framework Hands-On Instructions.pdf
When you're instructed to test the actor in section "c" of this page, it tells you to open up Water Level Test.vi and Simulation Data_Global.vi , run Water Level Test and observe Water Valve State become true. I do not see Water Valve State becoming true at all.
Are you manipulating the water level value? You need to do this manually.
Yes, I moved it up to like 20 and still nothing changed.
Recheck your code, then. The exercise works as indicated.
And if you're really sure it doesn't work, post images and video so we can see where our instructions and your interpretation of our instructions do not match! 🙂
Thanks guys, I figured out what I was missing...I came back to this exercise after helping host the CLD Summit here in AZ...and then skipped a step, I forgot to create the override VI Set Output State.vi per the instructions at the bottom of page 16, and I guess that's kinda important. 😉
It's working as expected now.
I just finished up page 22 of the instructions...
Once you change Cooler.lvclass to inherit from Level Controller.lvclass, the Water Level Test.vi and Dual Fan Test.vi no longer work, they compile/run, but no longer actually work (change Boolean indicators on the globals FP) because Set Output State.vi in Cooler.lvclass is broken at first.
Question: when you realize that something isn't working - where do you start your debug? I'm guessing that the answer in this case is "Always start your debug search by looking at the inheritance." No?
It took me a bit to get my bearings and figure out how to approach this after realizing I had changed the Cooler inheritance. BTW, I just happened to try running the test programs and realized it wasn't working anymore (might be good teaching point to add that to the instructions and let user see what is broken and explain why and how to debug).
Is there a way/tool to open up my heirarchy and see all of the VI's that won't compile at present? From a high level view I would like to see what is broken and where it is in the heirarchy.
Even on small projects, I like to use source code control so that when I realize something has broken, I can start my debugging with whatever I changed last, often by reverting that thing.
The Error List Window shows you all the broken VIs in memory. The items with a red X next to them are actually broken... anything else is broken because it depends upon a red X item.
Finally finished up the hands-on exercise.
1. Why is Cooler panel.lvclass a separate class/actor from Cooler UI with Events.lvclass? Why not just have Actor Core.vi in the Cooler UI with Events.lvclass?
2. Are there any examples of zero coupling in this exercise? Low coupling?
3. Are nested actors examples of zero coupling?
Amiri wrote: 1. Why is Cooler panel.lvclass a separate class/actor from Cooler UI with Events.lvclass? Why not just have Actor Core.vi in the Cooler UI with Events.lvclass?
Separating Cooler UI with Events from Cooler Panel means I can have several different flavors of UI for the same actor. You could write a minimalist "end user" panel that just showed "on/off" and inside temperature, for example.
In hindsight, pushing the user event code into Cooler UI with Events was not the best choice, because it assumes that all UIs would use user events. When I revised the hands-on for the AF course, I replaced Cooler UI with Events with a more generic Cooler Interface. The methods are the same, but they are all virutal - the user event code moved into Cooler Panel. At that point, Cooler Interface only defines a set of messages that a family of actors can receive. That's even more flexible, as you can then create children that do different things, such as front for a user interface in a remote location.
There are no examples of zero coupling in the exercise. I wrote, but never published, a Part 3 for this hands on that does zero coupling, but it didn't flow quite like I wanted it to. That material got improved and rolled into the AF course.
Cooler UI with Events and Cooler Panel would have been an example of zero coupling had I put all of the user events in Cooler Panel.
3. Are nested actors examples of zero coupling?
No. Nested actors are additional concurrent processing that you add to your system. Coupling refers to the connection between actors.
Thanks niACS (whoever you are out there in cyberspace ), this is great info and feedback, much appreciated.
Will you/NI be hosting that AF class around the CLA Summit (or NI Week) next year for 2016?
Amiri wrote: Will you/NI be hosting that AF class around the CLA Summit (or NI Week) next year for 2016?
Will you/NI be hosting that AF class around the CLA Summit (or NI Week) next year for 2016?
Good question. I'll have to think about it.
awful. totally awful. Overly complicated. If you must use this to teach newbie how to use AF, pls delete it. Just format your harddrive, seriously. And please change work, 'cause you are not only able to teach but also to write software.
No need to be so rude! You sould probably consider that nobody ever claimed AF was for newbies.
There is all kinds of stuff in different flavours for introduction/ AF basics; you are very welcome check the other stuff here in the community. Maybe you find sth to your liking
Many people nowadays think that criticizing is equal to actually doing something.
If you know how to code, feel free to give your own code examples and help the community.
niACS is one of the top contributors in the community and I felt like I had to defend him instead of him spending a second of his valuable time on comments like yours.
If you pointed what needs to be improved or what you didn't understand we might have been able to help you and others more productively.
It is actually important since we will understand how to make this important subject more approachable to a top noob like you.
Have a wonderful day.
This is not a constructive or helpful comment.
CLA, LabVIEW Champion
Check Out the Software Engineering Processes, Architecture, and Design track at NIWeek. 2018 I guarantee you will learn things you can use daily! I will be presenting!
Ironman is frustrated. It happens to all of us. I posted to him in one of the other threads to see if there was some other existing resource that might help him learn this stuff better. I'm going to be out on vacation for Thanksgiving until Tuesday. If he posts back, see if we can help him out.
I have decided finally to get aquainted with the actor framework. So I downloaded the AF Hands-On Exercise and worked myself through the exercise. Everything seemed to work fine including the tests in the exercise - until I came to the final demo: The Feedback Evaporative Cooler Demo. After finalizing it I tried to run it but nothing happened except that the Cooler UI opened - but no action at all. I have tried to debug using the DETT and it reports and error 1 in the Cooler class:Set Output State.vi. I tried to figure out the reason but being new to the AF I did not succeed. So I decided to run the solution shipped with the exercise (AF Hands-On Solution.lvproj). Same behaviour and same errors reported. I even downloaded the exercise again to make sure that I did not accidentally change anything in the solution project while doing the exercise, but with the same erroneous result. So right now I feel a bit stuck. I am running LabVIEW 2018 32-bit on Windows 10.
This hands on exercise is outdated. To name a few: Actors are highly coupled, It becomes difficult to test individual actor behaviors and prevent code reuses, e.g., Dual Fan actor; Instead of using "Launch nested actor", it use "launch actor" vi, which is no longer supported in newer AF library; No use of abstract messages, etc..
Explain of timed looped controller is not clear. Although the document says that system components will be polled at different rates, actually poll rate is set to 1000 ms once for all.
Water valve control state is not displayed on UI.
I finally got the "feedback evaporative cooler" project working with Actor Framework V4.1 under LabVIEW 2019. It took me a while by including abstract message classes and water valve status, but forced me to learn a little bit more in this way. When using DETT to trace, I noticed the following error from Set Output State.vi. The same error also shows up even when running the original project file downloaded from the very first post here. Any comments?
Also, could someone give me some hints about debugging tools for actor framework? Is there any user guide for Actor Framework Debug Library? How about MGI monitored actor?
Details: Error: 1 (LabVIEW: (Hex 0x1) An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.=========================Command requires GPIB Controller to be Controller-In-Charge.)Call Chain:-- Cooler.lvlib:Cooler.lvclass:Set Output State.vi-- Level Controller.lvlib:Level Controller.lvclass:Update.vi:7340002-- Timed Loop Controller.lvlib:Update Msg.lvclass:Do.vi:3750003-- Actor Framework.lvlib:Actor.lvclass:Receive Message.vi:1040002-- Actor Framework.lvlib:Actor.lvclass:Actor Core.vi:5880004-- Timed Loop Controller.lvlib:Timed Loop Controller.lvclass:Actor Core.vi:5880003-- Cooler.lvlib:Cooler.lvclass:Actor Core.vi:5880001-- Actor Framework.lvlib:Actor.lvclass:Actor.vi:6640012-- Actor Framework.lvlib:Actor.lvclass:Actor.vi.ACBRProxyCaller.D4700038VI Path: E:\ResearchWork_Buli\Coding\LabVIEW_work\AF_Tutorial\Learning\Examples\Ex_WaterCooler\Actor Framework0\Solution\Cooler\Cooler\Set Output State.viThread ID: 5 --- CPU ID: 17