Starting DQMH helper loop directly?

[1984]

Hi,

The CML/Acquistion module has a "Start Acquiring" event which is processed by the message handling loop then it fires the "wake up helper loop" event which starts the helper loop. If you have one helper loop like in the example than this doesnt seem to be a problem although if you have many - like one of my modules at this point - then it means I need two events to start a helper loop. I figured that my helper loops can register to their own "wake up helper loop" event so it seems I can save an event. The downside is that now incoming events are processed in multiple loops and not just in the message handling loop. In this case it really doesnt bother me, but I'm wondering if doing what I did has any fundamental problems which will kick me in the back later on. The upside (or at least the thing looks like an upside to me) is that I need to deal with one less event and I can delete my "start acquiring" event from my event handling loop as well.

Thanks!

[joerg.hampel]

Hey there, thanks for looking into DQMH and giving feedback here!

Could you maybe share a few screenshots or actual code? That would help us with understanding your questions.

[1984]

Sure, a screenshot is attached, hope that makes my idea more clear.

Instead of this screenshot I wanted to quickly modify the CML project cause modding that accordingly would be a more obvious example. I have noticed though - and that partially answers my question - is that processing the start event in the helper loop is not possible if the helper loop needs any data from the Message Handling Loop. In my code this is not the case, the helper loops run completly independent from the MHL. The advantage of my implementation still looks the same (EHL and MHL has no code for the helper loop and I only need to create one event instead of two), but in its current form there is no mechanism to send MHL data to the  helper loop which could be a disadvantage later on.

[1984]

I have found another huge disadvantage which probably throws my solution out the window... If you catch the start acquisition in the MHL then you can set up some conditions to start the helper loop. In the CML project its not a problem because the start acquisition button is disabled on the UI once its pressed, so that gurantees that you dont start it twice.

In my case there are no buttons, a loop continously bombs the module with requests and this IS a problem as whenever a request comes in my helper loop catches it which kinda restarts the helper loop.

If the message caught on in the MHL then I can decide not to fire an event which starts the helper.

Not sure if that makes sense, I'm already 8 hours in coding.

[joerg.hampel]

I fear there is no right/wrong answer to your original question. It really depends on your preferences or requirements:

• Should your helper loops be "accessible" from outside the module, or do you want them to be a private resource of the module? If private, then you need to separate private(*) request which you will call from the MHL (just as in the CML example).
• Do you need to sync data between different loops? Then you need again a (private) request - or some other mechanism (local variables, DVRs, ...).

And yes, you have to be careful with which events you register for: Any event that is bundled into the event registration node (**) that you registered and created an event case for and is then fired will reset your event structure's timeout counter. So if you rely on the timeout for triggering your acquisition, you have to make sure that no events can interfere with that (see also this blog post). This is especially important for cloneable modules, as all clones share the same event references - an event sent to one clone will be received by all clones (and then discarded).

When you say that "a loop continuously bombs the module with requests", is there a way to rework this? It sounds like there is room for improvement there.

(*) If you find this useful, please go and give Kudos to the feature requests for private events, local events and helper loops.

(**) I apologise for the misinformation. My mind was elsewhere when I typed this, Sam then called me out and Darren clarified. See below.

[1984]

Thanks for responding mate, useful insights! Yes, I'm positive that there is room for improvement in my code. This is the first DQMH project I do and I still need to figure out the mechanics and the way I should organize things. I'm sure more questions will come.

[Taggart]

---

@joerg.hampel wrote:

And yes, you have to be careful with which events you register for: Any even that is bundled into the event registration node and is then fired will reset your event structure's timeout counter. So if you rely on the timeout for triggering your acquisition, you have to make sure that no events can interfere with that (see also this blog post). This is especially important for cloneable modules, as all clones share the same event references - an event sent to one clone will be received by all clones (and then discarded).

(*) If you find this useful, please go and give Kudos to the feature requests for private events, local events and helper loops.

---

Hold on! I am very aware of the issue with cloneables, but your comment about registered events interrupting the timeout. Are we sure that's the way it works? I thought if you don't handle the event, it doesn't matter that you registered for it, it won't affect the timeout?  Is that not the case. Is there some document somewhere that clears this up? or maybe someone (I might be able to get to it later) can code up an example (that would be the ultimate proof).

[Darren]

---

@Taggart wrote:

---

---

Hold on! I am very aware of the issue with cloneables, but your comment about registered events interrupting the timeout. Are we sure that's the way it works? I thought if you don't handle the event, it doesn't matter that you registered for it, it won't affect the timeout?

---

Sam is correct for about the past 9 years. 🙂 In older LabVIEW versions, Joerg is correct. The behavior *used to be* that if you had a Register For Events node with event references wired in, but the Event Structure wasn't registered for those events, the Event Structure timeout would be reset by those events firing. This behavior was "fixed" in LabVIEW 2013. Since then, only events the Event Structure is registered for (regardless of what is wired into the Register For Events node) can reset the timeout for that structure.

Since the earliest LabVIEW version that DQMH ever supported was LabVIEW 2014, this has never been an issue with DQMH.

[joerg.hampel]

---

@Taggart wrote:
I thought if you don't handle the event, it doesn't matter that you registered for it, it won't affect the timeout?

You're completely right, Sam, thanks for keeping me 100! Thanks, Darren, for your clarification. 

In my own words: If you register for an event, wire that event registration to an even structure, but do not create a case for this event, it will not be handled by that event structure. The timeout counter will *not* reset when firing this event.

I apologise for the misinformation. My mind must have been far away when I typed this. To make up for this, I attached a VI that proves the behaviour that Darren describes.