jhoehner

Juicy drama...

Hey drjdpowell, Thank you for the feedback and yes good question... I think my intention is to try and combine good features from the two frameworks rather than try to mesh them together in their entirety. I think the idea of a broadcast from a generic child module up to a generic parent module through a user event is solid (DQMH has this feature by default). My team/customers familiarity with the actor framework is also good. A little more digging led me to a package on VIPM called the "Event Source Actor" which might already do what I'm trying to do (but better). I think I can take a stab at posting this in the AF forum as well but may have found my answer. Thanks again! -John Hoehner

Broadcast Actor.zip Hello All! I'm looking for a little bit of feedback on an Actor I've put together. The zip file attached contains an Actor called "Broadcast Actor". I know the idea of a "broadcast" partially goes against the AF rules but bare with me. The reason I put this together is because the idea of an abstract message was driving me a little crazy. I probably haven't had it properly explained to me but in any case I decided to try and build something that accomplished a similar task as an Abstract Message while also maintaining the low/zero coupling abstract messages provide. I do know Interfaces are out and about in LabVIEW 2020 but this approach is for older code bases that we can't quite upgrade yet. I loosely based this approach on DQMH which has an interesting architecture for messages going "up the tree" using broadcasts (user events), that parent modules register for when they start up. I figured something like this could also be implemented in an Actor. The attached broadcast actor has a message that returns its own populated "Event Cluster". Calling actors can call this message and are returned this "Event Cluster". The parent actor can then register for all of the events of the child actor in their Actor Core. I know reply messages are kind of discouraged in AF but this also felt like an okay way to use them. Once the child actor is up and running it can call it's own broadcasts which the parent can hear and do something intelligent with. My understanding of "low coupling" is limited, but I *think* this approach would prevent the parent actor from being loaded into memory if we are just trying to load the child actor. Maybe I'm way off or maybe this has been done before but it felt like a way to not have to use abstract messages (a barrier for some people to adopt AF), but also allow for low coupling between the actors themselves. Any and all feedback is welcome. What am I missing? -John Hoehner

Hi All! I've been thinking a lot recently about actor based development and best practices (not necessarily limited to Actor Framework actors, but the general idea of creating separate processes that all have one job, modularity, yadda yadda, you get the picture). Specifically I've been wondering about how a developer should set up their actor such that any cyclical action/method plays nice with other methods that the actor might need to accomplish. An example: -I've developed an application that has one simple DAQ actor and a separate UI that sends commands to this actor. -The DAQ actor has a timeout case that it executes every 100ms or so along with a separate command API. -This timeout contains a method that grabs some data from the hardware and then broadcasts that data via user event so the UI can display it. -The UI calls another one of the DAQ actors commands which in turn has the DAQ actor execute a case that is different from it's cyclical case/method mentioned above -The DAQ actor has to switch gears to execute the other command/method and then will return back to executing it's timeout case. I know that helper loops are an important concept when working with Actors, but they've only been described to me as a way to offload methods/actions that take the actor a long time to execute, not necessarily as a way to protect your cyclical/timeout method from delays. Is it normal to have helper loops handle the cyclical actions/methods for an actor and have the main message handler worry about all the other commands it can receive? The frameworks I'm kind thinking about/applying this to are AF and DQMH, but I feel like this concept finds it's way into tons of different homebrew frameworks as well. How do you guys approach this problem? -John

Thanks for the insights fellas. I think the main points are that it's mostly a preference based thing but could also help/hurt code readability depending on the situation. I will say, after programming this way for about a month (method B in the image above), I do find that I have less wires overlapping the error cluster wire especially when LabVIEW class wires are thrown into the mix. The nodes that live in between the class wire and error wire much more accessible when the error wire comes out of the bottom of the VI. I think my visual preference is to prevent overlapping wires whenever possible... Different strokes I guess. Thanks again!

Hello All, First time LAVA poster here with my first question. Why do some LabVIEW programmers insist on wiring the error cluster to the bottom of their VI as opposed to the sides as shown in most NI documentation. Is there any benefit to it? Is it 100% a preference thing? Is there a way to make LabVIEW connect error wires like this automatically? I've only seen it in advanced LabVIEW code from experienced programmers and some parts of the Actor Framework. Your insight and experience is appreciated!