LabVIEW
Actor Framework resources
@ConnerP wrote:
@BertMcMahan wrote:
5- One big benefit is that Actors are trivial to launch and close. If you don't need an Actor to be around, kill it and re-launch it when you need it again. Keeping an Actor idle is usually more work than making it ephemeral.
This took me forever to grasp. "A car object is like a car" yea car's don't just not exist so my object should also exist forever right? Wrong!
If I could vanish my car when I don't need it, and then suddenly spawn a brand new one, I'd sure do it! 🙂
(Kinda reminds me of the Tediore guns in the Borderlands games... the lore is that they're so cheap to "digistruct", aka magic up a new one, that you can't reload them. You just toss the old one aside and fab a whole new, pre-loaded gun on demand! And funny enough, I'd bet the actual underlying "weapon" in the game code DOESN'T get destroyed, lol)
If they CAN be the same Actor, I'd do that. If they need to be different, I'd suggest having both inherit from a common ancestor. Remember inheritance = "is a" relationship. It doesn't look like the 303 "is a" 301.
That said, consider composition as well (Prefer composition over Inheritance). If both systems have mostly the same "stuff" in them, you could have a "Test stand" Actor that "has a" force sensor, "has a" communication interface, etc.
(And also also, just a reminder- only make something an Actor when it needs to be asynchronous and handle messages by itself. Otherwise you can use a regular Object. You can still use Actors for the GUI or other business logic, just resist the urge to make EVERYTHING an Actor... and remember, keep Actors ephemeral unless you need them to be otherwise. Stopping and restarting a new Actor is trivial; maintaining state long-term through idle periods is usually more work.)
Bert (and others):
Perhaps I am getting a little ahead of myself here. I am just thinking - actually typing - all of the stuff that needs to happen.
Currently, when my app runs, the Launch Test Parameters, ReTest Sample, Stop Button, and Test Sample VIs send messages & just pop up a one-button message box, other than the Quit and Close Panel? Events. They have the Stop Core.vi. I have also added User Events to the Pre Init and Stop Core VIs (as overrides). Learned that from Tom Mcquillin's videos.
I think the next step is to start with the MARK-10 Actors (the test stand and its force gauges). Is that the right call?
This should probably be moved to the Actor Framework Discussions category, too.
So, my app needs another UI for the Test Parameters. This should send data to the UI you see in the screen capture. Currently, the Send Launch Test Parameters VI just has a One-Button message box that displays a message "User clicked Test Launched".
Do I create another Actor for the Test Parameters UI?
Eric
It depends on a couple things-
1- Does the Test Parameters window need to be an asynchronous process, capable of receiving independent messages?
2- Does the calling Actor need to keep running asynchronously while the Test Parameters box is open?
If the answer to either of those is Yes, then make it another Actor. If not, just make it a regular VI. Often my "settings" menus are regular UI's because the calling code needs to be synchronous with the Settings update window- basically, you WANT the caller to block while the user changes their settings. If you make Settings an Actor, then you have to force the caller to behave synchronously. Making Actors synchronous is (usually but not always) an anti-pattern.
The last question would be "Does the main Actor have a Settings API that other code can call to update the settings?". If so, then I'd use that same API. For example- does some initialization routine need to update the settings; if so, use that same code for your user-based settings window. If THAT code needs to be an Actor (or needs to NOT be an Actor) then duplicate that functionality with your User settings window.
@BertMcMahan wrote:
It depends on a couple things-
1- Does the Test Parameters window need to be an asynchronous process, capable of receiving independent messages?
2- Does the calling Actor need to keep running asynchronously while the Test Parameters box is open?
If the answer to either of those is Yes, then make it another Actor. If not, just make it a regular VI. Often my "settings" menus are regular UI's because the calling code needs to be synchronous with the Settings update window- basically, you WANT the caller to block while the user changes their settings. If you make Settings an Actor, then you have to force the caller to behave synchronously. Making Actors synchronous is (usually but not always) an anti-pattern.
The last question would be "Does the main Actor have a Settings API that other code can call to update the settings?". If so, then I'd use that same API. For example- does some initialization routine need to update the settings; if so, use that same code for your user-based settings window. If THAT code needs to be an Actor (or needs to NOT be an Actor) then duplicate that functionality with your User settings window.
It would be no to #1 and #2 so it would just be a regular VI. Do I place this VI under the lvlib or the My Computer hierarchy? Does it matter?
Functionally wise it doesn't really matter. Assuming this UI is tightly coupled to your code, you can put it in the lvlib. That helps keep things organized for you (the programmer).
Benefits to putting it in the lvlib are that it will give it a namespace, so if you have a VI called "Settings.vi" then its full name will be "Deflection Tension UI.lvlib:Settings.vi", so if you have an unrelated VI also named "Settings.vi" then LabVIEW shouldn't complain you have two files with the same name. If it's in a regular (non Actor) class then you'd get the same benefit.
Drawbacks to putting it in an lvlib are that, if you ever load JUST the settings functions, it'll load the WHOLE lvlib into your project, including all of your other Actors. I would assume you're not planning on doing that, so keeping it in the lvlib is probably the way to go.
