DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Dynamic call of modules

Hello Together

 

I have written a larger program that is used as a test program for all our appliances before shipping. The whole thing is solved with several DQMH modules. One of them is used for the communication with the appliance. Each appliance has a different communication interface and I don't want to integrate all modules into the main program. My idea is to integrate the communication module dynamically. At least the broadcasting events are identical for all modules. Unfortunately, something is not working as planned. I have to register the broadcast events at the beginning with "Start Module.vi". Even if I create the output cluster "Broadcast Events" from the same ctl, LabView recognizes this as different. Using my own compiled library filled with ctl's does not work either: The DQMH script then no longer recognizes the modules as it's own and I cannot add any new events. How do I do this?

Thanks in advance

Markus

0 Kudos
Message 1 of 5
(144 Views)

How are you doing this?  Have you built the communication modules into PPLs, or VIPM packages?

 

Rather than having different communication modules for each appliance, could you create a class hierarchy for each appliance communication and use that within one cloneable communication module, that you define on startup what the appliance it will be.  

Christopher Farmer

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

0 Kudos
Message 2 of 5
(111 Views)

If I understand it right, you created a DQMH module for each communication method. That's not wrong in the first place.

If you want to load the modules dynamically, you should think about an abstraction level. This could, for example, be a wrapper that calls either one or the other DQMH module at runtime. However, you could also design an abstract cloneable module, which then addresses the correct interface internally. This would also have the advantage that you could call several interfaces at the same time as clones.

0 Kudos
Message 3 of 5
(72 Views)

Hey Markus, 

 

thanks for looking into DQMH and sharing your question with us.

 

First of all, from a technical point of view, it is surely possible to detach the event registration from any specific datatype definition (.ctl of cluster). In our HSE Application Template, we register dynamically for any module's "default broadcasts" (Status, Error, HSE System Message). Feel free to take a look at the Event Manager module for an example of how to get this working:

 

joerghampel_0-1714375032510.png

 

With that being said, if your appliances expose the same functions over the different communication interfaces (even if they're only nearly the same), I would probably look into creating a single DQMH module with that API and then create a simple LVOOP abstraction layer inside that module. 

 

Hope that helps and gives you food for thought 🙂




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 4 of 5
(64 Views)

Hello everyone

Many thanks for the tips and ideas.

All modules are integrated as PPL. They are started like this:

 

Snag_114dbfa.png


At the top left are all modules for the test programme. These are always the same. The communication module is then loaded at the bottom. I have implemented this in "Start Module.vi":

Snag_114e87d.png

 

I read the name of the communication module from an ini file and start the "Start Module.vi" by reference. I have made the cluster with the "Broadcast Events" identical for all "Start Module.vi". If I take the ctl from a module, LV notices this and no longer accepts the broadcasts from other communication modules. I have also compiled the ctl into a PPL and taken it from there for all modules. That doesn't work either: DQMH notices this and deactivates all scripts to create new events. This is why other ideas such as wrapper vi's or classes don't work either: I can't get the different "Broadcast Events" vi's of the individual modules into the "Event Handling Loop". Or I can no longer edit modules.

0 Kudos
Message 5 of 5
(37 Views)