Aataqah

Hi Mike Le, thanks for your input. I'm still struggling with the Actor Framework mindset, but I hope my efforts will be rewarded ... CAMERA and TRIGGER: The camera has a physical digital input (trigger), so the "External Trigger Detector" actor needs the Camera Handle to poll for the HW change. The Camera Handle is received after the camera is initialized (think of it like a reference to the camera). I was thinking of creating a Camera actor with a Get Ext Trigger message and then a Trigger actor would constantly poll the Camera actor for the trigger. SETTINGS: How would you suggest I handle loading and saving settings from XML file? How to handle all the settings from multiple actors?

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