Ideas to make the start easier.

[MaxScz]

Hello everyone,

yesterday Jörg gave a presentation at the LUG Euregio and we had a discussion about the problems people have, when they are starting with DQMH.

First Idea was to start with a more abstract point of view to point out the ideas and advantages of a message based design. Later you can jump into the code and show people how the messaging is done in LV.

Another idea came today in my head. The Idea is to warp the Message Handling Loop in a SubVI. Why? Because in the beginning you don't care about the Event Handling Loop and all the other Stuff. All you need to do is edit the MHL and implement the functionality. I think this could be easier if you don't see stuff you don't care about.
Okay, there is a drawback if you need to edit the request values, you need to edit the EHL, so you need to edit the Main VI and not only the wraped MHL. A quick and easy way to solve this, would be to pack the request data in a variant, pass the data from the EHL to the MHL and unpack the variant.

What do you think about these ideas? Do you have any other ideas to make the starting with DQMH easier?

Max

[Olivier-JOURDAN]

Hello Max,

Just replied to a post pointing out the readability of the main.vi as a problem to adopt DQMH --> https://forums.ni.com/t5/LabVIEW/Generic-question-about-QMH-and-DQMH/m-p/4170696#M1205009

Readability is a tricky question. Not sure I'd love having the MHL wrapped in a VI. As you point, there are drawbacks, and one major for me is dealing with the UI. I'm used to updating UI in the MHL through properties or locals. With an MHL wrapped into a VI, I'd need to use references. It's far less efficient, and you will need to pass them to the wrapper.

Anyway, it's definitely something we need to improve.

Having a bigger MHL tends to come often in discussions...

[MaxScz]

Hey Oliver,

my modules don't have usefull UIs. I'm using my testers as a UI and as a Sniffer for debugging.

So when we can't wrap the MHL, why not warp the start and the end stuff? So the programmer has only some wires and some VIs, beside the EHL and MHL.

Max

[drjdpowell]

NI's design of a Queued Message Handler was used internally to DQMH modules as a way of making it easier for newcomers to understand it, on the theory that they are already familiar with the two-loop design.   Sounds like Max was not familiar, and the over-complexity of having two loops instead got in the way.  As I have long argued, NI's "QMH" has lots of weaknesses.

Better than hiding one loop from view, though, I suggest simplifying by eliminating the "MHL" and its Queue entirely, and making the "EHL" the only loop (with all State Data, Error Handling, and using a User Event to get messages from Helper loops).  This would give you more room in that loop.

Or, just keep it exactly as is, as that's the only way to get the benefit of familiarity for people who have used the NI-QMH.

[joerg.hampel]

Thank you, Max, for trusting in DQMH, and for taking the time out of your day to share with us an idea about making it easier to onboard new people to DQMH. We really appreciate your input.

To give everybody here more context, the discussion we had during the UG meeting had nothing to do with the number of loops in DQMH. In fact it had nothing to do with DQMH, really: It revolved around how to introduce the concept of modularity. How to convey that the real-life requirements should be mapped to modular code? How to introduce the idea of creating modules and having ways of communicating with and between them? How to elaborate on the different message types and their terminology? The idea here being to create an understanding of the different parts of DQMH before showing their technical implementation in LabVIEW, which is great feedback and input for upcoming DQMH trainings we'll give.

At least that's my recollection, please Max correct me if I'm wrong.

From what I understand, the issue here is not the number of loops but the amount of boilerplate and framework code that is visible in a vanilla DQMH module. 

We have been discussing the MHL in the past in the Delacor/Consortium group, like pros and cons of wrapping each MHL case content into a subVI (or even making the data cluster a class and have every MHL case be a method), of wrapping the MHL case structure into a subVI etc. So far, we could not find any alternative to the current design that doesn't come with other challenges or drawbacks.

We are anything but oblivious to the options, and we really bend over backwards trying to pick what we feel is best for the whole DQMH community.

PS: I just replied to another thread, explaining how you can actually rework DQMH to contain only a single loop, if that is what you want. 

[FabiolaDelaCueva]

Hi Max,

Thanks for your trust in DQMH and for taking the time to reach out to us with us your ideas.

---

@MaxScz wrote:

my modules don't have usefull UIs. I'm using my testers as a UI and as a Sniffer for debugging.

I would like to clarify that although API Testers are good to test how to develop the UIs that will ultimately communicate with your modules, I would not make them "the UI" for the DQMH module. The API tester is intended as running documentation of how to use each of your API calls as well as troubleshooting sniffer. Any code that you add to the API tester is code that you are telling future developers to add when they are calling the DQMH requests or handle the broadcasts. When we focus on making the API Testers work as a friendly UI that improves UX, we are making it harder to maintain and it has a lot of added information for the future developer that they may use or not use.

---

@MaxScz wrote:

So when we can't wrap the MHL, why not warp the start and the end stuff? So the programmer has only some wires and some VIs, beside the EHL and MHL.

---

The "end" stuff is a couple of unregistering for events and closing the module. We can look into putting that into a subVI. The beginning stuff is trickier. I have talked in the past regarding the Register for Events call and why I don't like to put it inside a subVI. This has to do with the reference wire, when put as a terminal on a front panel of a subVI, it cannot be typedefed. Anytime you add a new request, you would have to go into that subVI and regenerate the Registration Terminal. 

Another reason is that one should never fork the registration wire! when it comes out of a subVI it makes it really tempting for people to fork it and then complain as to why their program is not working as expected.

There is finally my love for maps and landmarks. To me, the loops and the code on the left and the right become part of the landscape. They tell me where I am on the code but I really care about what is inside the Event Structure and the Message case. Speaking of that, I love to put the EHL on the event I am currently handling and the MHL on the case that handles that event. I even make it an effort to remember to save the block diagram showing frames that are related to each other. This helps to tell the whole story of at least that event - message pair.

That said, we build DQMH with improving the DX (developer experience) in mind and we also knew that we would not have all the answers. This is the reason why you can create your own DQMH module template. However, as you are doing, I would suggest you understand first why certain things are designed the way they are before moving them around. 

Thanks again for your trust on DQMH and us.

Best regards,

Fab