Jump to content

Search the Community

Showing results for tags 'actor framework'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Software & Hardware Discussions
    • LabVIEW Community Edition
    • LabVIEW General
    • LabVIEW (By Category)
    • Hardware
  • Resources
    • LabVIEW Getting Started
    • GCentral
    • Code Repository (Certified)
    • LAVA Code on LabVIEW Tools Network
    • Code In-Development
    • OpenG
  • Community
    • LAVA Lounge
    • LabVIEW Feedback for NI
    • LabVIEW Ecosystem
  • LAVA Site Related
    • Site Feedback & Support
    • Wiki Help

Categories

  • *Uncertified*
  • LabVIEW Tools Network Certified
  • LabVIEW API
    • VI Scripting
    • JKI Right-Click Framework Plugins
    • Quick Drop Plugins
    • XNodes
  • General
  • User Interface
    • X-Controls
  • LabVIEW IDE
    • Custom Probes
  • LabVIEW OOP
  • Database & File IO
  • Machine Vision & Imaging
  • Remote Control, Monitoring and the Internet
  • Hardware

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Personal Website


Company Website


Twitter Name


LinkedIn Profile


Facebook Page


Location


Interests

Found 15 results

  1. 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 com
  2. 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.
  3. 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 applicatio
  4. 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 a
  5. 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 differe
  6. 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 fo
  7. 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
  8. 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 soft
  9. 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 lik
  10. Version 1.1.0

    2,809 downloads

    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 no
  11. 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
  12. 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 Acto
  13. 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 t
  14. 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
  15. 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 LabV
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.