DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Adding a CML/helper loop module to standard DQMH project

Solved!
Go to solution

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 😉


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
0 Kudos
Message 11 of 32
(6,075 Views)

@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 )

Message 12 of 32
(6,040 Views)

@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] CML DQMH helper loop snippet.png

Peter
0 Kudos
Message 13 of 32
(5,791 Views)
  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 
Christopher Farmer

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

0 Kudos
Message 14 of 32
(5,786 Views)

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 

Peter
0 Kudos
Message 15 of 32
(5,780 Views)

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.




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 16 of 32
(5,775 Views)

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.

Peter
0 Kudos
Message 17 of 32
(5,756 Views)

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

 

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
Message 18 of 32
(5,691 Views)

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. 

😲

 

Peter
0 Kudos
Message 19 of 32
(5,601 Views)

@Peter_B wrote:

I welcome the advent of helper loops and once they are debugged I anticipate utilising them as needed. 


Sorry to be nitpicky, but for posterity, I want to go on the record here and state two things:

 

1. It is perfectly possible to use helper loops in current versions of DQMH, no need to fear any bugs or other side effects (if implemented correctly, that is)

 

2. Once we release DQMH 7.0 into the wild, it will be just as thoroughly tested as all the previous versions always have been. It might not be a publicly or well-known fact, but we invest 100s (in words: hundreds) of hours testing, validating and documenting each new release of DQMH - on top of the actual implementation of the new features. We use beta versions internally and distribute them in batches to our Trusted Advisors, to "friends of DQMH" and eventually to the public before creating a public release. 

 

We pride ourselves on the product we deliver. Delacor set a very high standard, and the DQMH Consortium strives to take it even higher, if anything. Like we've said before, we are aware of the responsibility towards our users. There is no precedent, no known reason to not use any new version of DQMH right away, or to anticipate that any of its features will have to be debugged. 




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)


Message 20 of 32
(5,582 Views)