DQMH Consortium Toolkits Discussions
Architecture Validation
Sounds like a good general start.
I would draw some bubble diagrams similar to what Anti-doc generates. It will help you manage dependencies.
I would certainly change some of your terminology.
Instead of the DMM getting the configuration data (which implies it knows where to get it from), I would have the Main Module supply the configuration data to the various modules.
If the display and logger modules aren't intended to be reused then having them register directly for broadcasts from the various modules might be ok.
You really just want to give thought to your message routing and your dependencies.
See these:
The other thing that helps is to run AntiDoc often. It will easily show your dependencies and where you have issues like circular dependencies.
That lets you do a little less design upfront. You can almost use it like an iterative design tool. Say you have some feature where you need to add a bunch of messages. You can quickly add a bunch of messages and get it working with some tests in place. Then you can run Antidoc and make sure the dependencies look ok and if they don't then just refactor until they do.
Why something synchronous?
also does your logger need to know about the instruments? Adding an instrument would then require changing your logger.
Couldn't your logger have a request that says log this piece of data (with some kind of identifier telling you what channel)?
Then whatever launches your logger and instruments registers for the broadcasts from the instruments and forwards them to the logger.
The wait for reply flag is just that, do you want to wait for a reply or not? Depending on the context the caller (module sending the request) may care about the return or may not. If you don't care about the return data, no sense in waiting.
for the round trip: (from the DQMH help)
- Round Trip: A request and wait for reply event and a broadcast event where the Reply Payload and the Broadcast Argument are the same typedef. The request and wait for reply event has an input to determine whether the code should wait or not for the reply. In the case where the code doesn't wait for the reply, these events are asynchronous but may be logically related (i.e., Do Something and Did Something). In the case where the code does wait for the reply, the broadcast provides the opportunity of notifying other VIs, registered to listen to the broadcast, when another VI has called the request and is waiting for a reply. This is particularly useful in TestStand projects where the TestStand step needs to wait for the reply and we might want to use the API Tester as a sniffer and still see the reply reported there via the broadcast event.
So you have a module, say a power supply and you have a request that sets the voltage. You may want that to be synchronous because you want to make sure that is set correctly before you do the next thing. So you would make it a request and wait for reply event. But let's say you also want other modules in your program to be notified when the voltage changes. If you make it a roundtrip message, then the module will also broadcast the new voltage in addition to returning it as part of the wait for reply data.
It's honestly mostly a convenience, because you could just create the broadcast yourself.
@drjdpowell wrote:
Why is that called a "Roundtrip"? That seems non-intuitive. I would have guessed that something called a roundtrip would involve circular message passing like A-->B-->C-->A.
Ask Fab.
