Jump to content

jhoehner

Members
  • Content Count

    5
  • Joined

  • Last visited

Community Reputation

1

About jhoehner

  • Rank
    LAVA groupie

LabVIEW Information

  • Version
    LabVIEW 2017
  • Since
    2013

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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 s
  2. 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
  3. 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
  4. 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 wheneve
  5. 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!
×
×
  • Create New...

Important Information

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