Refactoring a project into Actor Framework

[bknelson]

Hello, I'm new to this forum and to AF.

I have a large application(two intances) that I've been maintaining for a bunch of years and would like to refactor to make it easier to maintain and read. There are a bunch of parrallel loops that I'd like to encapsulate in AF classes. I understand the concept but get lost in the details. For example, my vi(s) talk to a motion controller, different types for both implementations. The application needs to know the status of the motion controller and execute a handful of commands common to both types of motion controllers. The user wants to see a lot more information about the particular motion controller for manual control and status. What is the best way to display a user interface for manual control of the stages. Can the UI be part of the conrete implementation of the actor core? Any examples available?

[justACS · Accepted solution]

UIs are implemented in Actor Framework by adding UI elements and an event handling loop to an actor's implementation of Actor Core.vi.  Which actor core gets the UI elements is the interesting question.  You have three options:

Worst option:  Adding UI elements directly to one of your specific motion controller actors.  It works, but you always have the UI, and it's tightly coupled to the work of controlling the motor.

Easy, effective option:  Make an actor that inherits from the motion controller that needs extra UI elements.  Then you have the option to run the system with or without a UI.

Most flexible option:  Make an actor that *just* handles the UI for that motion controller, and write your motion controller to launch that actor as a nested actor.  Then you can invoke or dismiss the UI as needed, or even change UIs in flight.

Part 2 of the AF hands-on shows examples of this, as does the AF sample project.

Do you have access to the CLA forums?

[bknelson]

I was able to implement what you referred to as the 'worst' option last night. I speculate that I'm trying to do a hybrid of the worst option and the Easy, effective option. I'll put some more thought into the Most flexible option today. My more immediate problem was understanding how to share information between an actor and a calling vi (test.vi) that isn't an actor. I was able to do it using events once I understood that the event needed to be created in the calling vi.

Back to the problem of designing the heiachy for my motion contoller. Each 'physical' controller has different data, and methods used to control it's stage, There are some commonalities such as X and Y position, move done, abort... that will need to be made available to the calling program. The UI I'm making will have loads of extra information that the calling program doesn't need to worry about but is useful for manual control and debugging operation of the stage. Does this not imply that the UI, controller, and hardware will be highly coupled?

Having the UI be a separate actor than the Controller might be useful but does that mean that when it is not being viewed it is out off memory or not running? Or is it better to just show and hide the UI when needed using the property node.

Thanks for the reply, I have not accessed the CLA forums

[AristosQueue (NI)]

bknelson wrote:

once I understood that the event needed to be created in the calling vi.

Standard rule you can use all over the place: Communications refnums need to be created by the VI that receives the information, not the sender of the information.

[bknelson]

As a brief follow-up to this post, can you please provide some tips on how best ot manage actor libraries. wasn't quite happy with the organization of my file in my project or on disk, I just failed at an attempt to re-organize the files, could you provide some tips on how to do this?

[MattP]

I'm partial to the organization scheme in the coffee shop example code: https://decibel.ni.com/content/thread/12560

EDIT - Ignore the the 'Messages for person' folder.  It should have been called 'Messages for this Actor.' 

<hand wave> These aren't the bugs you're looking for....

[justACS]

I should probably clarify that "worst" doesn't necessarily imply "bad choice for your application."  It's just the least flexible/most tightly coupled solution.  I tend to view these things as bad, but that's my value judgement; your situation might be different.

In your case, yes, it sounds like you need a high degree of coupling, which would push me to making a child class that adds UI elements.

If the UI is completely separate, you have the option to make the UI leave memory when you don't need it, without terminating your motion controller.  You can also change UIs while the system is running, giving you the option to have, say, a panel for normal operations and a panel for debugging.

The good news is that refactoring between these solutions is not difficult (especially between the easy and flexible options).  Go ahead and implement the easier option; you can migrate later without much pain if need be.  I'd still avoid just adding UI elements to the controller itself, unless your application calls for this panel to always be open.

[justACS]

Go get this tool:  The Actor Framework Project Provider

This adds right click functionality to your project for creating actors and messages.  It will give you a default project layout which is very similar to Matt's coffee shop example.

[bknelson]

All of the posts above have been very helpful, thank you to all

[DMurrayIRL]

I have a related question, so I think it belongs here without derailing the OP: When you use the Actor Framework Message Maker from the Tools menu bar, is there a way to change where the directory+message class gets saved? The default is one directory level too high (for me, anyway). And doing a "Save-as -> Rename" after the message is created doesn't seem to work very well.