Leaderboard

Concerning coupling related to DQMH modules, keep in mind that: - When module A broadcast data and module B is registered to this broadcast. Module A is not coupled to module B - When a module B uses a request or is registered to a broadcast from module A, Module B is coupled to module A With that in mind, it's easier to detect where the coupling is. Basically, your "low level" modules should be decoupled from the high-level modules. High-level modules are projects related and low-level modules could be used in any project.

I don't use DQMH myself, but some suggestions: Re #1 and using the timeout: you don't need to use a fixed timeout; you can write some small subVI that calculates the time remaining till the next scheduled read. For example, if teh last Read was at 98700 ms, the next read should happen at 98800 ms. If it is now 98712 ms, then the subVI can output a 88 ms timeout. If a message is handled, and the time is now 98798 ms, then the subVI will calculate a timeout of 2 ms. You would code in logic of what to do if it is after the scheduled time (either do anyway, or skip). Re #2: you could have the higher-level Module A send a message to C containing the User Event of B's Broadcast. Then C can listen to B, without directly referencing it. B and C would need to agree on the datatype of the User Event, but would not otherwise be coupled. A is doing the coupling, but without handling all the messages.

Hey Matt, great that you're looking into using DQMH! Regarding your first question, I think you're using the term MHL (Message Handling Loop, the one in the bottom with the case structure) to describe the EHL (Event Handling Loop, the one on top with the event structure). You're saying that "by having my helper loop broadcast, I feel like I'm taking away from the main design that the MHL is supposed to broadcast". I don't think that by design only the MHL or EHL should do broadcasting. I would most definitely go with a helper loop. If you haven't seen it yet, feel free to take a look at our blog post on helper loops. It shows how to create helper loops that can be enabled/disabled. Regarding your second issue, many people advocate to structure your modules like a tree, for exactly those reasons you already mentioned. You will find that as you remove the static dependencies, reusability of Modules B and C will pay for a little "cumbersomeness". Here's a graph illustrating that tree structure (I created it for another thread some time ago, so please excuse that the naming is different to yours) : Let me know if this helps!