DQMH Consortium Toolkits Discussions
dynamically register Broadcast and Requests
Solved!
Hello out there,
I didn't come up with a solution, so may be you have some clever ways for the following problem. Lets say we have n modules which all should implement a few common methods, which should be triggered by another module. How do you solve that?
My thought is, that they register themselves with a generic Broadcast Event and the other module "Main" stores some references in an array. Then it can call dynamically the methods of the modules by using the references of the requests...
So, can I implement the Requests "do something" and "do something else" and just copy the refnum out of the Obtain Request Events.vi and pass those as the Broadcast data? When adding modules, I don't want to manually add Requests.vis to "Main".
And how would I register for the generic "Register Module" Broadcast Event? In "Main" I don't want to start Module1 and Module2. Also I only want only one generic EHL-Case for all n modules.
Thanks in advance for any suggestions 🙂
@joerg.hampel wrote:
Maybe you can draw some inspiration from how we start and register modules (and call their API dynamically) in our application template: https://gitlab.com/hampel-soft/dqmh/hse-application-template
Hey Jörg, thanks for the tipp. There is a lot of code to go through in that template. What I've found is the following in the Event Manager:
- The DQMH which should send generic Broadcasts implements a Obtain Default Broadcast Events.vi
- tha VI encapsulates the module-specific Obtain Broadcast Events for Registration.vi and only returns the default broadcast event references that any HSE DQMH module features: here you've added a generic Broadcast "System Message"
- In the DQMH which should register for that generic Broadcast you use DQMH Obtain Default Broadcast Events.vi
- In that VI you look through all your modules in a folder and extract the references to the default broadcast events (by Calling the VI by Reference)
- Finally you use a private Request to send that references to the EHL (Register for module events) and register the EHL to the conrete Broadcast "System Message"
That seems pretty clever to me. And if I would use a template for my DQMHs it wouldn't make too much effort...
Okay, if I've got that right, that would work for the first part of my problem: How to register for generic Broadcast events.
Now, how to call dynamically some request events:
Your're using a similar way to start your Modules dynamically:
- The standard DQMH way is to call two requests: Start Module.vi and Synchronize Module Events.vi.
- Again you've encapsulates the module-specific connector panes by implementing a Load Module.vi which has the same connector panes for all modules.
- you use a path to the module and look for the Load Module.vi
- With a Call By Reference function you finally run the Requests
While writing this post I've learned a lot. So I'll try to sum it up in general and start with the easier case:
One module wants to call dynamically the same Requests to multiple DQMHs.
- Request Events must have the same connector panes to be called by reference dynamically
- That can be achieved by a) encapsulating, if no or the same data input or output is neede or b) using a variant
- Now we have implemented a "Do Something Request.vi" in multiple DQMHs
- Implement a VI "Dynamically Call Do Something Request.vi" which takes a reference to the application and a path to module as Input. There build the path to the "Do Something Request.vi" and call it by reference
- In the DQMH which should call the Requests we need to know the modules path information and call the VI "Dynamically Call.."
Now to the case where a DQMH should dynamically register to multiple Broadcast Events:
- Again: The Broadcast Events "Did Something" all must have the same connector panes
- Implement a "Obtain Did Something Event for Registration.vi" in the multiple modules and wire out the needed reference
- Implement a "Dynamically Call Obtain Did Something Event for Registration.vi" which takes a reference to the application and a path to module as Input. There build the path to the "Obtain Did Something Event for Registration.vi" and call it by reference, wire out the needed reference
- In DQMH which should register for that Broadcasts:
- Create Request Event: "Register for Did Something Event" with an array of the Broadcast reference as argument and move it to the Private folder
- We need to know the modules path information and call the VI "Dynamically Obtain..." (in a loop thats why we need an array of references)
- Bundle a constant of the "Did Something" Eventreferences (as an array) to the DQMH_REG_EVENTS User Event
- Send the array of the Broadcast references to the EHL using the newly created private Request and register them to the EHL
- we can now create a new EHL-case "Did Something User Event"
Updated Sequence Diagram
Please correct me, if I've missed some important points
When creating the user event referencesand the VI references, do I have to consider something? Can I just create them in one Module and use the for the other too? Unless they are not stricty type def...?
What is the difference between dynamic and generic? What should be in my mind when designing a solution?
I think what I am doing in this diagram is only dynamic: At edit time the Dynamic Module doesn't know which Modules it will call and to which Modules it will react. Though having a Dynamically Call Obtain Did Something Event for Registration.vi is very specific. So Dynamic Module doesn't know which modules, but it knows exactly which Events are involved. Is this good or bad?
Are you doing something more generic with your System Message in the template?
Thanks Christopher for your hints concerning the cloneables. Until now I was speaking about multiple Singletons. That problem will probably come later to my mind, when I'll start using clonables.
I don't have any example handy, but basically you could use an OOP factory pattern and dynamic dispatch.
Settle on a common set of messages for all your HW devices (real and simulated). Create an abstract class with a method for each message. This resides outside of any DQMH module.
Then for each HW module, wrap its messages in a child of your abstract class.
Use a factory in the main which outputs an object (type is your abstract class)
The Main module depends on the abstract class and so do each of your HW modules. But there is no dependency between the HW modules and the Main.
To make things easier create a HW template that already has all the messages in it and already has them wrapped with a child of your abstract class. Then when you create a new module, the class will already be in place. All you would have to do then is fill in the MHL code.
