Search the Community

I've made some pretty cool changes to Monitored Actor that help expand it's capabilities. The main being the ability to override the UI. This lets you do cool things like create a web based actor monitor, or run the monitor window in the runtime environment. I also added Actor Labels to help you identify running actors. Check out our Monitored Actor 2.0 article for more info! If you're at NI week, be sure to checkout the presentation by Brandon Steele on Thursday (1:30 in room 16B). He'll be covering the Monitored Actor as well as some other tips for developers of large application (like MGI Solution Explorer, Class Method Browser and Actor Framework Message Maker)

Our sequencer interprets an scxml-specification, and should construct a Virtual State Machine .. For this purpose, we launch for every Step and for every transition an actor. Every Step_actor gets an array of the enqueuerOfTransitions having this Step as source. Then, every Transition_actor gets an array of the enqueuerOfSteps, which can be activated by this Transition. Now to my question: when I call iteratively the 'Launch Nested Actor.vi', can I be sure that the created actors have the same order of call in the array of nested Actors (if not, is there any solution like Launch_Batch)?

Hi all, I'd appreciate some advise or pointing in the right direction regarding building an EXE with class dependencies. I have a project built with actor framework and when I build it to exe, I get lots of dependencies which I think should be included in the EXE as seen below: On my Source files build properties page I currently have nothing under Always Included. I did try including all of the lvlibs and including them in the EXE but it didn't make a difference. In summary, I think the way my EXEs are building is not right. It is easy to see what VIs I'm using (although you can't open them) and it doesn't look very professional. What are the best practices for building dependencies into EXE? Thanks

Goal: Find the best methods (or at least some good options) for message decoupling that are simple to implement and efficient to execute. Background: Messaging architectures in LabVIEW that use a class for each unique message type are strongly coupled to the recipient process (aka ‘Actor’). This is due to the need within the message execution code (a method of the message class) to access the private data of the recipient process or to call methods in the recipient process in order to do the work that the message intends. (See Actor Framework for an example of this). The problem arises when you wish to send these messages across a network between two separate applications. In most cases, these applications are not duplicates of each other, but rather serve completely separate purposes. An example would be a client and a server. The client needs to message requests to the server and the server needs to push data to the client. For a process to send a message, it needs to package the inputs in the private data of the message class and then transmit it via the network transport (which can be implemented in multiple different ways and is not material to this discussion). In order to construct the message, the sender will need a copy of the message class included in their application. This will mean they will need to also load the class of the message recipient since it is statically linked to the message class within the method that executes the message. And since that will trigger many other class dependencies to load, the end results is the majority of the classes in the recipient application will need to be included in the sending application. This is not an optimal solution. So, we need to find a way to decouple messages from their recipients but still be able to execute them. My solution: The way I have been handling this is for each message that needs to cross the network I create a message class whose execute method calls an abstract method in a separate class (call this my network message execution class). Both the sender and the recipient will have a copy of these message classes and the network message execution class. Inside the message class’s execution method, I access a variable that stores an instance of the network message execution class and then calls the specific abstract method in the network message execution class for this particular message. In each recipient application, I create a child of the network message execution class and override the abstract methods for the messages I intend to receive, placing the actual execution code (and static links to the recipient process) within the child class methods. Finally, when each application initializes, I store its child network message execution class in the aforementioned variable so it can be used to dynamically dispatch to the actual method for message execution. The advantages of this are: Messages are decoupled between my applications. The disadvantages are: For each message I wish to transmit, I must create a new message class, a method in the network message execution class and a method override with the real implementation in the recipient’s network message execution class child and then edit the message class to call the method in the network message execution class. This also means that each application must have a copy of all the message classes passed between applications and the network message execution class. The problem arises when you add a 3rd or fourth application or even a plugin library to the mix and wish to decouple those from the other applications. You must either extend the current set of messages and the abstract methods in the network message execution class, having each entity maintain a copy of all of the messages and the network message execution class even though they never send or receive most of those messages, or you must add additional variables to your application to store different implementations of the network message execution class for each link between entities. So, now that you have read my long explanation, does anyone have ideas for a better way to solve this? I would love to simplify my code and make it easier to maintain, while retaining the functionality that class based message architectures offer. But decoupling must be addressed somehow.

I am posting this in the Application Design and Architecture forum instead of the OOP forum because I think it fits here better, but admins feel free to move the thread to the appropriate spot. Also, I am posting this to LAVA instead of the AF forum because my questions relate to all Actor Orientated Programming architectures and not just AF. Some background, I looked at AF and a few other messages based architectures before building my own. I stole liberally from AF and others to build what I am using now. But I am having a bit of a crisis of confidence (and several users I am sure will want to say 'I told you so') in the command pattern method of messaging. Specifically in how it binds all actors in your project together via dependencies. For example: If Actor A has a message (that in turns calls a method in Actor A) to create an instance of Actor B, then adding Actor A to a project create a static dependency on Actor B. This makes it impossible to test Actor A in isolation with a test harness. The recent VI Shots episode about AOP discussed the need to isolate Actors so they could be built and tested as independent 'actors'. If Actor B also has the ability to launch Actor C, then Actor C also becomes a dependency of Actor A. And if Actor B sends a message to Actor A, then the static link to that message (required to construct it) will create a dependency on Actor A for Actor B. So, the end result is adding any actor in your project to another project loads the entire hierarchy of actors into memory as a dependency and makes testing anything in isolation impossible. This is the effect I am seeing. If there is a way to mitigate or remove this issue without abandoning command pattern messaging, I would be very interested. In the meantime, I am considering altering my architecture to remove the command pattern portion of the design. One option I am considering is to have the generic message handler in the top level actor no longer dispatch to a 'do' or 'execute' method in the incoming message class but instead dispatch to an override method in each actor's class. This 'execute messages' method would then have a deep case structure (like the old QMH design) that would select the case based on message type and then in each case call the specific method(s) in the actor to execute the message. I would lose the automatic type handling of objects for the message data (and have to revert back to passing variant data and casting it before I use it) and I would lose the advantages that dynamic dispatch offers for selecting the right message execution code. I would have to maintain either an enum or a specific set of strings for message names in both the actor and all others that message it. But I will have decoupled the actor from others that message it. I think I can remove the launch dependency by loading the child actor from disk by name and then sending it an init message to set it up instead of configuring it directly in the launching actor. I guess am wondering if there other options to consider? Is it worth the effort to decouple the actors or should I just live with the co-dependency issues. And how does this affect performance? I suspect that by eliminating all the message classes from my project, the IDE will run a lot smoother, but will I get a run-time performance boost as well? Has anyone build systems with both types of architectures and compared them? I also suspect I will get a benefit in readability as it will be easier to navigate the case structure than the array of message classes but is there anything else I will lose other than the type safety and dispatch benefits? And does anyone who uses AF or a similar command pattern based message system for AOP want to try to defend it as a viable option? I am reluctant to give up on it as is seems to be the most elegant design for AOP, but I am already at 326 classes (185 are message classes) and still growing. The IDE is getting slower and slower and I am spending more and more time trying to keep the overall application design clear in my head as I navigate the myriad of message classes. I appreciate your thoughts on this. I think we need to understand the benefits and pitfalls these architectures present us so we can find a better solution for large LabVIEW application designs. -John

I'm working on a large project and have run into a quandary about how to best deal with a large shared data set. I have a set of classes that define 3 data structures. One is for a script read from disk that the application executes. Another is the output data from the program, generated as the script is executed. The last is a summary of the current state of execution of the script. The first two can be significant in size and are unbounded. In my application, I have one actor (with sub actors) responsible for reading the script from disk, executing it and collecting the data. It also updates the summary status data. Let's call this the control actor. I have another actor that takes the data and displays it to the user, allowing them to navigate through it while the script is being executed. Lets call this the UI actor. The last actor is responsible for communicating the summary to another application over the network. We will call this the comm actor. So, the control actor is generating the data and the other two are consumers of the data. I had originally thought to have all the data stored as state data in the control actor and then as it is updated/created just message it to the other actors. But then they would essentially have to maintain a copy of the data to do their job. This seems inefficient. Then I thought I could wrap the data classes in DVRs and send the DVRs to the other classes. That way they could share the same data. The problem with that is they would not control when their data gets updated. And I am violating the philosophy of actors by creating what is essentially a back channel for data to be accessed outside of messages. Also, I could block the 'read' actors when I am writing to the DVR wrapped class. I would have to be careful when updating subsections to lock the DVR in an in-place structure to do the modify and write. Then comes the question of how to best alert the readers to changes made to the data by the writer. Simpy send them a message with the same DVRs in it? Or send a data-less message and have them look at the updated values and take appropriate action? So, any best practices or thoughts on how to resolve this issue? I appreciate any feedback.. -John

Name: Data Broadcasting Library for Actor Framework Submitter: Stobber Submitted: 01 Apr 2013 Category: *Uncertified* LabVIEW Version: Not Applicable License Type: BSD (Most common) Use v1.0.0 for LabVIEW 2011-2012. Use v1.1.0 for LabVIEW 2013+. The attached library provides extensions to the Actor Framework to facilitate the broadcast of messages from one actor to several others. Listeners subscribe to a message when they want to receive it from the Broadcaster, and they unsubscribe when they want to stop receiving it. The library provides a set of common interfaces that decouple Broadcasters from Listeners so any two actors in a messaging hierarchy can communicate via broadcast without having the same caller. This library extends the Actor Framework; it does not modify the core framework in any way, so it may be used in existing projects as well as new ones. Documentation for the library and the included example program is attached. Click here to download this file

I've started a discussion with the same subject on the Actor Framework NI Community Site. You can view the discussion and download ArT_Actors White Paper (Draft) here. It makes sense keeping the thread in a single location - please reply & post on the Actor Framework site. Please find a copy of my original post attached (purely for your convenience ) Cheers, Dmitry --------------------------------------------------------------------------------------------------------------------------------------------- All, I’ve been recently looking for a cool Messaging Solution for my new OO LabVIEW Framework. Actor Framework seems to be the best thing in town these days – but, out of the box, it does not provide support for some of my [dear] personal programming habits … so I made an effort to create a custom AF extension - but ended up with a somewhat different implementation of the Command Design Pattern. Major deviations from AF3.0 include introducing the notion of Actor API (a new class hierarchy) and splitting Actor class into purely Functional Domain entity (Actor class) and purely Messaging Domain entity (Actor Component class). Please see attached ArT_Actors White Paper Draft for details. It would be quite interesting to know how many of you consider items 1 – 6 (in the Analysis section) important for your projects and to get a crude priority rating for each (Critical| Important | Don’t Care). I would also appreciate getting feedback on the overall design from those, who have time and patience to go through the White Paper Draft (pick 1 or 2 features you like/dislike most). I am arriving in Austin on Sunday, heading back to Bay Area after lunch on Friday. For those going to NI Week - we can get together and discuss the subject in person .