Helper loops for active / repetitive tasks

[bartelma]

Hello DQMH enthusiasts,

I'll admit, I'm just starting my journey through the DQMH Framework so here is one of my first beginner questions and I'm sure many more will follow.

First, a big thanks goes out to everyone in the Consortium and others who post frequently about how to use DQMH. It's such a relief to have so many resources to pull from as I learn the proper way to use DQMH. 

With that said, as I developed my first project I ran into a forks in the road and plowed ahead to find myself asking, "How many Helper Loops are too many Helper Loops?" I have a module which serves as a cloneable test cell manager which receives broadcast messages from my Acquisition module and receives requests from the Main User Interface module. The Test Cell module currently has three helper loops which are Logging/Data Buffer, Display Update, and Safety Shutdown Monitor. 

By adding three helper loops I was able to modularize the code, but now I have a rather lengthy vertically arranged VI since the helper loops are not within subVIs but rather flat on the block diagram of my Test Cell Main VI. I can also conceptualize instances where I would want more helper loops in my Test Cell module if this were a more complex experiment. 

All that being said, how many Helper Loops are too many Helper Loops? Should they start becoming subVIs (probably a personal preference I suppose) and when should I start making those Helper Loops into modules themselves?

Thanks!

[Ozfarmboy]

How many helper loops is too many?

A few ways to consider when answering this question:

1. One way to answer this, is performance.  If the module (or application) is getting too slow then is it too many?  However you can use timed loops for your helper loops to set different priority/execution/thread options.

2. Another way is code readability.  How far down do you want to go on the screen to find the code you're looking for?  Zoom helps with this.

3. Another way is modularity.  If you're starting to add loops that would be better as another module.  For me, I like to have every instrument/device in its own module (ie. camera module, motion module, DAQ module, pump module, power supply module).  I like to have a module for each active asynchronous screen (ie. test engine module, diagnostics module, config/settings module) etc.

If your application is effectively a single DQMH module with multiple helper loops then there's not much difference between that and QMH.

It's rare that we'll have more than one helper loop in our DQMH modules, but we have a few where it made more sense to have 5 or 6 helper loops rather than 5 or 6 DQMH modules.  This is because it was performing DAQ from multiple sources and this data needed to be synchronised (and it was also running on RT) so memory and performance were important factors as well.

Should you turn each helper loop into sub VIs?

There is nothing stopping you from even turning the first helper loop into a sub VI.  This comes down to personal preference. If you don't want your main.vi block diagram to be too large, then subVIs are an easy way to minimise this. An advantage of creating subVIs is that you can set priority and thread for each subVI to help with performance if this matters. However some people believe your code is more readable if you keep the helper loop on the main.vi block diagram.  I think the case for the latter is stronger with the ability to quickly zoom in and out (LabVIEW 2023+) to move around the diagram.

When should you turn a helper loop into a module?

This happens to me from time to time.  I start out creating a helper loop, but then realise it should be its own module. 

In this forum post, we had a passionate discussion about when to create a module or not.  Maybe this would give you some guidance.

Sometimes it's easier to have it all in one module rather than splitting it into two.  An actual example is I had a vision application and I was triggering the camera acq via an FPGA.  Initially I had a module for the FPGA and a module for the camera, and decided later that it was best to have the two merged into one module for performance and simplicity reasons.

[Olivier-JOURDAN]

Speaking of Helper Loop and repetitive tasks, and because it's a very old thread, I'd like to take the opportunity of this new question to point you out to the toolkit I developed later in 2023 --> https://www.vipm.io/package/wovalab_lib_utilities/

On this page, you will find lots of explanations about Helper Loop's repetitive execution timing and the toolkit can help with -> https://wovalab.gitlab.io/open-source/docs/utilities-toolkit/latest/helper-loop-timing.html

I hope this can be useful for any LabVIEW developer.

[bartelma]

Wow, thanks for the insights Christopher and Olivier! That's a lot to chew on. I think my next DQMH endeavor will have a lot more modules and a lot fewer helper loops. I found myself maintaining more state data in the helper loops than I anticipated and I remember reading in Sam Taggart's Simple DQMH Dos and Don'ts - DQMH® that this was a bad idea and now I see why. I'm constantly worried about updating both loops with the new state sometimes and it just it's great programming. 

Thanks again for the replies guys!

-Mark