DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Event channel wire for local helper loop communication?

Has anyone tried using the event channel wire type for communication between the MHL and helper?

 

I gave it a shot today and I'm not sure how I feel about it. I also don't fully understand the deep under the hood stuff so maybe I just didn't do it right.

 

Typically, my helper loops are simply an event structure inside a while loop. Outside the while loop I create a user event and send that ue wire to the MHL as well as to a register events where the resulting refnum is wired to the dynamic node on the helper loop event structure. Ok, this seems like a pretty common thing in DQMH land. I can then generate user events from the MHL to talk to the helper and toggle my event timeout for any continuous process needed.

 

What got me interested in the idea of using channel wires was to simplify things and also because I recently went through the hell that is registering an invalid daqmx task event and figuring out how to avoid that nasty access violation error/crash.

 

So without knowing anything really about channel wires I gave it a shot. The only way I could think to register a channel event outside the while loop was to make a channel writer, but I thought doing so would also cause an event so I ended up moving this to the initialize case of the MHL and piping the wire "back" out to a reg events and then that refnum into the helper. It worked, but it sorta "feels" wrong since it flows right to left and the helper loop can't "start" until the MHL init case executes (which isn't a problem, like I said, just feels different/wrong). I wish I could post a pic but I'm no longer at work, so hopefully my description is good enough.

 

I would love to see a sample block diagram of how our resident DQMH experts would implement a module with an event channel wire as the  communication method with an EHL-style helper loop. 

0 Kudos
Message 1 of 5
(1,033 Views)

The default approach for this (instead of using a channel wire) would be to create a new event that you only use internally to the module (ie. it's not publicly available). 

 

Once you've created the event, you'll need to remove it from the Public API folder to a new private folder (call it Private requests). 

 

You'll also want to remove the handling of the event from the EHL, and the corresponding MHL case that DQMH automatically creates for you.  Then you'll setup your helper loop to handle this new event. 

 

And you'll call the event VI from within your MHL at the required time that you need to pass an event down into the helper loop. 

 

Does this make sense?  Fab has demonstrated this with the wake up helper loop concept.

 

(Fingers crossed in DQMH 7 you will be able to create an event that is private from the get go.)

Christopher Farmer

Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

Message 2 of 5
(1,015 Views)

I think you must be misunderstanding how channels work (they are counterintuitive compared to normal LabVIEW wires).  For example, your helper loop actually does start before your "initialize" case in the main loop.

0 Kudos
Message 3 of 5
(999 Views)

There are already some feature requests revolving around this topic:

 

Make sure to give them your kudos if you like them. 




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


0 Kudos
Message 4 of 5
(991 Views)

@Ozfarmboy wrote:

The default approach for this (instead of using a channel wire) would be to create a new event that you only use internally to the module (ie. it's not publicly available). 

 

Once you've created the event, you'll need to remove it from the Public API folder to a new private folder (call it Private requests). 

 

You'll also want to remove the handling of the event from the EHL, and the corresponding MHL case that DQMH automatically creates for you.  Then you'll setup your helper loop to handle this new event. 

 

And you'll call the event VI from within your MHL at the required time that you need to pass an event down into the helper loop. 

 

Does this make sense?  Fab has demonstrated this with the wake up helper loop concept.

 

(Fingers crossed in DQMH 7 you will be able to create an event that is private from the get go.)


Yes, makes sense, I've even done it a few times, just sort of forgot about it between projects. That might be the best way, I like the idea of it being "a part" of the DQMH ecosystem. 

0 Kudos
Message 5 of 5
(968 Views)