Search the Community

Hello everyone, TL;DR - Any thoughts on if it's a good or bad idea to spin off an actor from a QMH framework? I've got some library code that would be valuable but the project itself doesn't justify AF. I'm brainstorming ideas for a tester that I'll be building over the next few months. The project that I'm currently winding down is an Actor Framework test system that has come out really nice. Part of the project was an actor built to handle all of the DAQ and digital control. The main actor spins it off an tells it when and what tasks to launch. It send back data and confirms commands, uses Dynamic events to keep up with the generated signals, and uses actor tasks to ship the data back to the controller. Works amazing. Nothing revolutionary for sure but very handy. This next project doesn't really need actor framework, it's much smaller and has a lot smaller list of requirements. That being said I'm curious about integrating my DAQ actor (Dactor, because who can resist an amalgamation?!) into the project. Any thoughts on if it's a good or bad idea to spin off an actor from a QMH framework? Is this even possible based on how the AF tree is designed to work? Thanks for reading! Tim

Here's a heads-up for any LabVIEW developers in Central Texas, or any Certified LabVIEW Architects coming to Austin for the CLA Summit next month. I will be teaching Actor-Oriented Design in LabVIEW, Sept. 13th - 15th, in the training center at NI's corporate headquarters. Come take the class, enjoy Austin for the weekend, and stay over for the Summit! Details on the course offering here: Actor-Oriented Design in LabVIEW There are offerings in October as well, in MI, MA, and Santa Clara, if those locations are more convenient.

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)

Hi, I'm writing a LabVIEW application using the Actor Framework. This is the first time that I have used the framework and I need some advice regarding application architecture. My apologies if this is a basic question! How is a settings dialog box best implemented? In the past in non-Actor Framework applications I have loaded the configuration from a functional global variable, displayed the settings dialog, then written the updated settings back to the functional global. I'm not sure this would work correctly (or optimally) within the context of the Actor Framework, though. My application uses the template generated by Create Project -> Actor Framework. The top-level Actor manages the user interface. Two child Actors control separate pieces of hardware. The top-level actor must read a saved configuration from an INI file when the application starts, and save the final configuration back to the INI file on exit. Instinctively I think it would be best for each child actor to maintain its own settings, as a cluster in its class private data. Ideally I don't want to have to keep a separate instance of the two clusters of settings in the top-level Actor's private data in order to populate a settings dialog; this duplication seems unnecessary. The only way I can think of to make this work is as follows. At application start 1. Top-level Actor reads settings from INI file. 2. Send messages to both child actors with the new settings, and tell them to apply those settings to their private data. 3. Each child Actor should respond to acknowledge that the private data has been updated. To update the settings using a dialog box 1. Send a message from the top-level Actor to each child Actor to ask them to send their settings to the top-level Actor. 2. Wait for both child Actors to reply. 3. Display the dialog box. 4. If the user clicked 'Ok' and not 'Cancel', send messages to both actors with the new settings, and tell them to apply those settings to their private data. 5. Each child Actor should respond to acknowledge that the private data has been updated. On exit 1. Send a message from the top-level Actor to each child Actor to ask them to send their settings to the top-level Actor. 2. Wait for both child Actors to reply. 3. The top-level Actor writes the settings to the INI file. This doesn't seem like a sensible approach, though. Waiting for message replies sounds like the wrong thing to do. I wouldn't know where in the block diagram to implement this scheme, either. Can anyone offer me any advice? There must be a fairly standard way of doing this that I'm missing! Thanks in advance, Chris --- Dr. Chris Empson Robot Screening and Instrumentation Specialist School of Chemistry University of Leeds UK CLD

I have to develop an application and I would like some help designing the architecture. The system controls a number of pumps and valves to create flow around a network of pipes. There are flow meters in the network which are used as feedback for PID to maintain a flow. The network of pipes is gradually opened up to get flow and then PID kicks in to maintain a flow. The test sequence is pretty much a big state machine. For example: 1. Open valve 1 2. Wait for pressure to build 3. Ensure temperature is not over limit 4. Etc I will have a number of different screens which I want to load into a main sub-panel: · Main SCADA screen (show state of all valves pumps etc) · Test setup screen (configure tests) · I/O screen · Alarm screen I will also have a number of I/O processes: Inputs · Digital (valve sates) · Analogue (flow meters, temperature etc) · Modbus and serial devices (flow meters) Outputs · Digital Output – Valves etc · Analogue - Proportional valves I want to use the Actor Framework because I’ve used it 3 times now and it is easy to spawn processes, make popups, inter-process messaging, error handling etc. I can have all my processes separate (high cohesion) with separate user interfaces (if they have a UI) . My problem is that AF and State machines don’t really go that well together (correct me if I’m wrong). What happens when I want to do PID or loop in the same state? Time delayed message? A a VI for each state and enqueue the next or same state from within that VI? Does anybody know a good way to incorporate a state machine into AF or should I chose a different way of doing things? Any thoughts will be appreciated. Cheer Lewis

I was debugging an application today and tracked it down to an error being passed directly into Actor Core from an initialization method upstream. I had expected the error on occasion and have a case in my Handle Error override to display a front panel warning to the user. My oversight was thinking that Actor Core would call Handle Error if an error was passed directly into it. This isn't the case, of course: it skips running any of its code and passes the error straight through. Should an error passed into Actor Core call Handle Error? I assume this was considered and discarded for some reason. Anyone have any insight as to why? Thanks.

I am new to Actor framework and would like to know how to continuously display values read from hardware. The project contains cDAQ class and in Unit test folder is the demo vi called " TestcDAQ9203_ContinuousReading.vi". This VI is actually a QDSM but to simplify I have placed a while loop and set to continuously acquire.How do I 1. Display the readings using queues instead of globals?2. Even when I stop the top level VI the methods in cDAQ class keeps running, how to stop these?Thanks and please advice. Project attached. UnitTest2.zip

Hi everybody, this is my first post here. I am a LabVIEW engineer (CLD) and only recently started to learn LVOOP, specifically the Actor Framework shipped with LV. I have read the whitepapers, presentations and the Evaporator Cooler example, but I'm still struggling with real life programming problems. I'm having a lot of difficulties switching from task-based thinking (JKI State Machine) to LVOOP thinking in Actor Framework and I'm hoping for some good advice here. Basically, my biggest problem is defining what should be an Actor and what not? For this purpose, let me describe my software requirements for a machine vision application in a task-based approach: Init Load settings from file Init Camera Init DAQ device Start GUI [*]MAIN LOOP: Poll for external trigger on Camera IF TRIGGER == 1 Acquire image from Camera Analyse image to get result OK (1) or FAULT (0) Send result to digital output IF RESULT == 0 [*]Update GUI [*]SHUTDOWN: Save settings to file Release Camera Release DAQ device Exit app Camera can be selected at runtime (USB camera, ethernet camera, simulated camera (ie. load images from folder), etc.) - HAL for Cameras Settings (for image analysis parameters) can be changed during operation and applied to image analysis without restart of application Each step can be timed (acquisition, analysis, etc.) - not a high priority, but is a nice feature for client Error handling Timing is crucial. Only a couple hundred milliseconds are available for the whole process. The application must NOT MISS an external trigger and MUST send the result to digital output as fast as possible. This is my current attempt of Actor organization, based on the Evaporative Cooler example: ActorTimed Loop Controller Get External Trigger (needs Camera handle from Camera class, which contains child classes for each camera) [*]Image Acquisition (needs Camera handle) [*]Image Analysis (needs analysis parameters) [*]DAQ (needs Device handle) Send Result OK Send Result FAULT UI abstract layerGUI GUI for changing/updating settings [*]Settings (needs Camera handle, Device handle, analysis parameters, etc) I think this design is flawed, because I am having problems that should not happen with this design pattern: sharing data between Actors (for example camera device parameters between actors get trigger, image acquisition and settings). How should the Actors in the Actor Framework be organized for such an application? What do you recommend? Also, should I have a Main (Controller) Actor? Save Image to folder

I've created a set of Actors that pick up data from a hardware source and display that data live in a Chart indicator. The organization is pretty simple: 1) Controller Actor: Launches the Hardware, Plotter, and Analysis actors. Mediates messages between them. 2) Hardware Actor: responsible for setup and shutdown of communication with the DUT. As it picks up data, passes them up to the Controller. 3) Plotter Actor: picks up hardware data from the Controller and plots the data to the Chart. Also provides controls that let the user change what signals are plotting and what they look like. 4) Analysis Actor: picks up hardware data from the Controller for analysis; results and/or raw data can be saved to file. The DUT produces data at a rate of 1kHz. It's theoretically possible to stream about 200 signals at this rate, though in practice it would be exceptional if someone were to gather more than 50 at once. At first, I had the Hardware Actor pick up each data-point individually and immediately forward each point to the Controller. But the Plotter Actor down-stream had trouble keeping up with the 1kHz rate. My fix was to have the Controller "batch" the messages. The Hardware Actor is still producing at 1kHz, but the Controller builds an array until 30 data-points have been received and then forwards the 2D array to the Plotter. Now the system was fast enough for a few signals, maybe 5-10. But as I add more signals, I find that my software starts to fall behind the hardware data. A colleague suggested using a DVR to store the picked up data and passing the reference around instead of the data array. My concern is that this breaks the "contract" of Actors communicating only through Actor Messages. This thread was helpful, but I thought I'd start a new thread for this particular use-case. I imagine others have used Actors for streaming hardware data and have come up with better, more elegant solutions than I could!

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'm somewhat new to Actor framework and this is my first major project using it. I've completed a few simple Actors before and integrated them into larger applications. I am communicating with a device over Ethernet. A proprietary program takes in ASCII commands and passes them to the device. Data is returned along the same TCP connection as ASCII strings. I want to display the data to the user in a UI. In the future, the proprietary communication program may be swapped out for a custom in-house program. There are likely to be different UIs in the future. I decided to create 3 Actors: a Hardware Interface / Listener actor, a Controller actor, and a UI actor. I want to keep communication between the three Actors simple and consistent, so potential future Actors are able to handle the same messages. The Listener and UI actors may be substituted for other actors in the future (a certainty in the case of the UI actor). A critical task of the UI is to be able to display the parameters/settings of the device. There are several dozen different settings. The UI is interested in displaying some of them as indicators, issuing warnings depending on other parameters, and ignoring other updates. The UI's response to a specific parameter would change depending on which UI is being used. What I'm struggling with is this: Which Actor should store the hardware's current parameters/settings? Should there be multiple copies of the hardware's current settings in each Actor? How should the parameters be passed around? Should there be an abstract Parameter class? If I used an abstract Parameter class, would dynamic dispatch be the best way to handle different UI reactions? I'm afraid of coupling Actors too tightly together. On the other hand, it's not clear to me where the Parameter data should be stored, because it seems like the Controller and UI would need to have access to it. Should it be stored in the Controller and passed up to UI as needed? If anyone has any thoughts/advice, I'd greatly appreciate it.

Hey guys, I have been teaching myself labview for the past 2 to 3 years. I know other programming languages like java and PHP so OOP is not entirely new to me. I am running into an issue with actor framework, specifically writing/reading private data of actor instances. I have created a simple project that encapsulate my issue. Basically, I have a main vi called "test" that starts an actor called "Prime". Prime immediately starts another actor called "Secondary". Secondary has a string in its private data member, with proper read/write accessors. I created a message to be able to write to the string in the private data. Prime has a message dequeuer in its private data so that it can communicate with secondary. My whole goal is to have both prime and secondary running simultaneously and have you, with the click of a button, update that string in secondary and have the new string show on the front panel. I have been struggling with this for a few days now. I have posted the zip file for the project below. Please help. Actor Message Learning.zip

I have some projects on the horizon that have to be more reliable than anything I have done in the past. And this new requirement has me thinking about how I deal with errors in LabVIEW more and more. Simultaneously I have been looking into the Actor Framework. The sample project in LabVIEW 2012 for the Evaporative Cooler does a great job of showing how many of the pieces of a full application fit together. However, as I have studied the example, I have noticed that in many places error handling has simply been ignored. An example of this is in the water level control... specifically, I take issue with the word "guarantee". Documentation states: "Water Level is a concrete implementation of a Level Controller. We will use it to guarantee that the water in our evaporative cooler’s reservoir never falls below a minimum safe level." What if the building loses water pressure? Or the piping fails? Or the valve doesn't actually respond? Or any of a million scenarios that result in the program being unable to really guarantee anything. I'd like to open a discussion of how the Evaporative Cooler example could improve on its error handling so that it was robust enough to safely deal with all the "what ifs" of the world. This question is covering everything from "what if writing to the value property of a UI indicator fails?" to "what if the building water supply fails and the water level doesn't respond when I command the valve?" And those seem like two great places to start! In the context of the Evaporative Cooler example project, I found three VIs whose error handling I would like to discuss: 1. Timed Loop Actor.lvlib:Timed Loop Actor.lvclass:Read Controller Name.vi 2. Live User Controller.lvclass:Update Current Temperature.vi 3. Level Controller.lvlib:Level Controller.lvclass:Update Core.vi In the case of #1, the VI does not have error in/out terminals, but some of the VI's it calls does. This is a situation I have encountered before: how do you add error handling to a very low level VI that does not (and for the sake of discussion cannot) have error terminals? In the case of #2, the VI writes to a property node and ignores the error terminals. In a big application there are soooo many property nodes! What are the implications of ignoring the errors? When is it safe to ignore them? This is probably very common, and has some overlap with #1... In general, in LabVIEW, when can you ignore error terminals? #3 is the logic VI that determines whether to open or close a valve based on water level. But it doesn't keep track of time and whether things are "working". And certainly if you put a human operator in place of the VI, the human would after some time decide that opening the valve hadn't helped the water level. Can the VI mimic this? For all of this error handling business, I think I am really asking four questions: A) What should the software do on its own to respond to the error? B) What should the software tell the operator (who might have never heard of LabVIEW or college) about the error? C) What should the software tell the operator's supervisor about the error? D) What should the software tell the software developer about the error? It is pretty easy to write an application when everything works the way it should! But when things might go haywire, how do you write application then?

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 .