Helper loops for active / repetitive tasks

[joerg.hampel]

I finally managed to write a little something about how we use helper loops in our applications. Feel free to take a look at https://www.hampel-soft.com/blog/dqmh-actors-self-messaging-or-helper-loops/ and let me know if you have any further questions or comments

[psmorris]

Nice post Joerg! I need to get round to writing mine! Your approach matches mine to a great extent. The bit that I've added is to have the helper loop enable/disable itself when the module is idle/active. So the timeout in the helper loop is set to -1 automatically when there's one or more messages in the message queue and reset to the helper loop period when the queue is emptied. That way I can be sure the helper loop never (or at least almost never) gets in the way of the operation of the module.

We're also using the second type of helper loop in a singleton module which manages (and provides the interface to) a cloneable module. The helper loop handles all messages coming from the cloneable modules (and any other external module we're interested in hearing from). 

Now, this COULD be done using the main event handling loop of the DQMH, but I do prefer keeping the two loops separate - one loop for direct commands to the main module (i.e. the DQMH event loop) and one loop which I call the "External module event handler" which registers for the broadcast events of external modules...

Paul

[joerg.hampel]

Paul, thanks for commenting! 

One interesting thing is that you point out that you don't want the helper loop to get in the way of the operation of the module. So far, for most (if not all) of our modules with helper loops, I'd not want the module to get in the way of the helper loop. This distinction is definitely something to keep in mind when designing the module. Let's talk about this some more next week in Madrid.

[joerg.hampel]

When talking to some LabVIEW friends about this blog post, I was confronted with reservations regarding using the timeout event of an event structure for periodic actions. It was pointed out that NI's core 3 training recommends not to use the timeout event for any critical actions.

I know from experience that timeout events used to be tricky (maybe even buggy?) some years ago, maybe in LV8.2 or 8.6 or so. I haven’t had any bad experiences with it ever since. Is there anyone who has more tangible things to say about this? Does NI still recommend to not use it for critical stuff?

[FabiolaDelaCueva]

---

wrote:

When talking to some LabVIEW friends about this blog post, I was confronted with reservations regarding using the timeout event of an event structure for periodic actions. It was pointed out that NI's core 3 training recommends not to use the timeout event for any critical actions.

I know from experience that timeout events used to be tricky (maybe even buggy?) some years ago, maybe in LV8.2 or 8.6 or so. I haven’t had any bad experiences with it ever since. Is there anyone who has more tangible things to say about this? 

Hi Joerg,

This is one of those things that became religious without people understanding the background (think about "Functional Global Variables protect against race conditions", no they CAN, but then don't always do).

It is true that if you have an event structure registered to a bunch of stuff, you don't want to use the timeout event case, because the timer will get reset everytime another event happens. However, if you only have:

* Stop DQMH module event

* Wakeup Helper Loop

* Put Helper Loop to sleep

Then, the timeout will execute without issue. You can benchmark this. Just leave a DQMH with a helper loop running overnight and count the time elapsed between each timeout.

As far as timeout being buggy, I don't remember this. There was an issue brought up at CLA Summit 2011, when Justin Goeres was presenting and Steen Schmidt pointed out that if one registered for an event and didn't handle it, the timer would still reset. This led to half of the room saying it was a bug and the other half saying it was a feature. All I know is that starting with LabVIEW 2013, this is no longer the case. Only the events handled by the event structure (have an event case assigned) cause the timer to reset.

Hope this helps.

Regards,

Fab

[joerg.hampel]

Thanks, Fab. I didn't even think of the timeout case being starved by other events being called because we don't use it that way. It might be worth adding that caveat to the original blog post.

And yes, I remember listening to Justin being interviewed by Michael for the 3rd VI Shots episode, and him talking about Steen triggering that event timeout epiphany.

[psmorris]

Yep, mine is more of an "idle time" helper loop... When no-one's talking to the module, the module talks to itself to keep itself

We're using DQMH for a motion application and the end user can physically move the motion stages around without software input. The helper loop makes the DQMH periodically poll it's controller for any change in encoder position value and then we can broadcast that out to the application to update any UI which shows system position in real time. The module already sends its positions out during moves so there's no need for the helper loop to run...

Anyways, looking forward to a chat, perhaps over a beer?!

Paul

[Darren · Accepted solution]

---

joerg.hampel wrote:

Does NI still recommend to not use it for critical stuff?

---

I would have to review the specifics of the LabVIEW Core 3 course to understand the exact scenario being described, but I can definitely see a recommendation to avoid using a Timeout event for handling "critical" events in an Event Structure that is also handling other "critical" events.

But in the case of a helper loop, the Timeout event *is* the critical event. As you mention above, it is critical that other requests *not* interfere with the operation of the helper loop (other than what was mentioned...enabling/disabling the helper loop, and the Stop Module request). 

I have never had reservations about using the Timeout event for the helper loop use case, and I am unaware of any feature limitations or bugs in LabVIEW that should prevent any of us from doing so.

[danny_t]

Thank you for your blog post a very interesting read. I am currently using your type 2 broadcast helper loop.

One question I have is how to find the constant user event refnum as mention in your quote below. 

"Initially, we only supply a constant of the UI.System Message user event refnum for the event registration node. This allows us to create the corresponding event case. Beware that our helper loop is only loaded, but not yet armed." 

For my DQMH module that is broadcasting I can find a Broadcast Events clust containing a number of Broadcast events but I cannot seem to find the base constant.

[joerg.hampel]

Hey Danny, thanks for your comment!

Regarding the constant, I know of two ways:

1.) In my blog post, in the picture after the one you quote, you can see how I enable the event registration for broadcast events in the helper loop. I place the Obtain Broadcast Events for Registration.vi on the block diagram, wire its Broadcast Events cluster to an Unbundle By Name node, select the "System Message" user event refnum and wire it to the Register For Events node. This is the place where I get the constant: I pop up (right click) on the user event refnum wire and select "Create Constant" from the context menu:

2.) Drop the Broadcast Events--cluster.vi on the block diagram, and drag the "System Message" constant out of the cluster. Because the cluster is a typedef, you cannot move the constant out of it. You need to copy it out by keeping your ctrl-key pressed while dragging: