Adding a CML/helper loop module to standard DQMH project

[Olivier-JOURDAN]

Great to read your message @_Ian_ 

I hope the DQMH framework will help you be successful in your project!

Shameless plug: don't forget to generate your code documentation with Antidoc 😉

[_Ian_]

---

@Olivier-JOURDAN wrote:

Shameless plug: don't forget to generate your code documentation with Antidoc 😉

---

Indeed - I found myself watching your GDevCon presentation last week!
(Which can be found here along with several other great presentations, if anyone else is interested  https://www.youtube.com/watch?v=r0HKScV6Fwg )

[Peter_B]

---

@Ludwig72 wrote:

You have to add the helper loop manually. But there is already an accepted feature request for this. So you have that to look forward to.

---

What is the most definitive guide to date on creating my own helper loop ?   

I feel a bit uneasy about copying the CML example given it doesn't look to be trivial coding as there is more than just the timeout frame in the ES which seem mandatory [1].  sure I could fumble about and get something working but as a nebiw to DQMH I am not confident - I like to take the easiest lowest risk method available.

Alternatively is there another method already supported in DQMH if I want to poll some switches at say 100ms rate and broadcast any switch state changes ?

[1] 

[ChrisFarmerWIS]

1. This has a good description of creating a helper loop: DQMH Actors - DQMH®
2. When DQMH 7 is released, there will be an option for helper loops to be automatically created 

[Peter_B]

Thankyou Christopher.  The article is definitive enough for me and it helped me realise I can solve my need without using a separate helper loop, and keep the overhead to a minimum. In fact I see no advantage of a helper loop if I address reach caveat as follows:

1. The module still needs to call itself.  (Easy peasy. That's the self messaging option explained upfront in the article, and the one  Fabiola appeared to promote in the first comment.)
2. There’s a risk of flooding the queue with messages (not if I set a parallel delay in the self messaging case that is longer than any code in that case takes to execute)
3. Other cases of the MHL might starve (not if I ensure other cases take less time than the above delay or I have no other cases and the self messaging case is the "only" one for the module)

In short, I can dedicate the module solely to be polling my switches and I need no helper loop !  Simple works best for me. Thanks again 

[joerg.hampel]

Peter, I will check back with the rest of the Consortium later today, but I _think_ that our official recommendation is to *not* self-enqueue messages for periodic actions.

Here at HSE, we definitely do not allow that design for repetitive, periodic actions. We will always go with a helper loop for those scenarios. It gives us more control over when to start, when to run, when to stop, true parallel execution, protection from external influence (another request being executed in between polling), protection from flooding the queue, better readability, and probably other advantages I'm forgetting right now. 

Since writing the article on helper loops in 2018, I gained five more years of experience with DQMH, and I have a much stronger feeling against self-messaging now than I had back then. Also, I cannot see where Fab would make a recommendation in her comment - can you please point me to it so I can update the article accordingly?

Furthermore, Sam's great article on the Simple Do's and Dont's says "Don’t Enqueue inside of MHL".

With all of that being said, whatever works best for you is a good solution for you. I just want to make sure that you understand the implications, and that others finding this page later have the complete picture and all the pros/cons.

[Peter_B]

Hi Joerg,

thank you for noting all those points.  If a helper loop was available out of the box right now I would use it.  I think I can mitigate the potential problems with self messaging per my reply above.  I don't need to stop and start it, it will always be running and in true parallel execution because the entire module will be devoted to that one task plus no other cases will interrupt it.   It won't be as flexible and convenient as a helper loop and if it gets too unweildy I can switch to a helper loop.

>Also, I cannot see where Fab would make a recommendation in her comment - can you please point me to it so I can update the article accordingly?

The first comment on this page is where she wrote "One thing I want to clarify is that DQMH modules are already Actors, they don’t need to have a helper loop to be considered an actor."

Her initial comment was basically saying a helper loop is not needed for a DQMH module to behave like an actor.  She was open to helper loops and obviously has now adopted them but her initial comments were insightful for folks like me understanding what is possible.

[FabiolaDelaCueva]

Hi Peter,

MHL = Message Handling Loop

EHL = Event Handling Loop

CML = Continuous Measuring and Logging

We adopted helper loops for repetitive tasks early on. One of the earliest discussions I remember was the Message Pumps. We added the CML sample project as a way to show their use in October of 20018 for DQMH 4.1). In fact, they are so much a needed component of DQMH that DQMH 7.0 will have a way to script them. The Beta will come out anytime now.

I believe you are making an informed decision but you will have to keep an eye open for all the caveats that everyone has highlighted. 

I will add my own take on the different ways to handle repetitive tasks and why I prefer helper loops to handle them.

There are different ways to get repetitive tasks working:

1.  Self-enqueuing: The issue with this is that you may get messages out of order. It seems that in your case, you could get away with it because at the moment you will not have any other things running in the MHL. However, if you do decide later to add a start/stop acquiring requests, realize that you could go down a slippery slope. You would be tempted to make your stop acquiring request a high priority so it is addressed right away, however, that would leave you with a queue full of continuously acquiring messages, then you will be tempted to flush the queue, but then you could end up flushing the Exit message.... Don't ask me how I know this, suffice it to say it was painful enough that we advocate against self-enqueuing especially for repetitive messages, even if at the moment it seems that your module will always be acquiring and it seems that you would never want to stop and start acquiring without having to start and stop the whole module.
   • Timing is a big caveat here. If you are acquiring very slowly, then this may work but this will definitely not work if you are acquiring fast and you need to be ready to read from the DAQ buffer as soon as it is ready. Otherwise, you may end up getting an error from DAQ that you are not reading as fast as possible.
2. Self-request: This is when we create a request for the DQMH module and then we fire that request inside a case in the MHL... stop right there, now we are in essence adding two enqueues: one to "enqueue" the request event to the EHL to handle the request event and then the enqueueing to the MHL queue... it makes everything discussed on number 1 worse, don't even go there... At that point, might as well self-enqueue.
3. Helper Loop: Can run as fast as possible, granted that there is something else like hardware that will be adding 'rest time' to the CPU. This is the example used in the CML and that we recommend for acquiring data. The Helper Loop may be going to the Timeout case as fast as it can, but then it will be waiting there until the DAQ buffer is full and there is something to read. This also reduces the chances of you getting an error that you are not reading as fast as possible. Additionally, if you ever change your mind about adding extra functions to start and stop without restarting the whole DQMH module, it will be straightforward to add them to the helper loop. This also leaves the MHL dedicated to the business logic of the DQMH module.

In summary, the Helper Loop is more flexible and easier to extend than doing self-enqueuing for repetitive tasks.

Now, to really blow up your mind. We have come to the realization that we should have named DQMH the DEHM because a DQMH module can exist without the MHL but it could never exist without an EHL. 

I hope this helps.

Best regards and thanks again for your trust in DQMH and in us.

Fab

[Peter_B]

Hi Fab,

Wow.  Thank you so much for chiming in and taking the time to write such a thorough reply !

The caveats are understood and I am willing to take any risks I have failed to mitigate.  One thing in my favour in this instance is that I am polling some push button switches at about a 50-100ms loop rate, so I will not have to worry about  any errors from not reading a DAQ buffer fast enough.  The app is also runnning on a RPi so the executable never needs to exit except for an error condition and in such a case I will resort to debugging such an error manually using the LV IDE or perhaps an error log file.

I welcome the advent of helper loops and once they are debugged I anticipate utilising them as needed.   I really appreciate your efforts to the LabVIEW community, esp. through DQMH.

Now, to really blow up your mind. We have come to the realization that we should have named DQMH the DEHM because a DQMH module can exist without the MHL but it could never exist without an EHL. 

😲