DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

DQMH Packaging

Solved!
Go to solution

Hi,

 

I am embarking on new project where I plan on using multiple DQMH modules (10-15) that will be built into an executable. I am wondering if it is possible to package each completed DQMH into a lvlibp and distribute them with the compiled main application exe. This way I could make updates to each module in the field without changing the base exe. 

 

Has anyone done this before with DQMH modules or have any tips on how to approach this?

 

Thanks in advance,

 

Joe

0 Kudos
Message 1 of 7
(6,031 Views)

Hi Joe,

 

Yes, it can be done and it has been done. 

I know of at least one customer who has done it and one who is on the process of doing it. I am out on vacation until next Friday, but I will send a couple of messages around to see if someone can post here and give you more information.

 

If not, I will answer when I get back.

 

Regards,

Fab

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
Message 2 of 7
(5,909 Views)
Solution
Accepted by topic author BrokenArrow

Hello Joe,

This is something I am doing for one of my project. I have an application composed with several DQMH modules (>50). Each of them is packaged in a PPL and can be updated independently. It works really well but they are several things you need to consider. One thing is that you might loose certain capabilities of DQMH and its scripting tools.

Indeed, by default, when you compile your DQMH module into a PPL, since DQMH resides in vi.lib, it will be packaged within the PPL. Each time you compile a DQMH module into a PPL, it copies the DQMH dependencies into that PPL. If your application has 15 DQMH modules compiled in PPLs, you will then have 15 times the DQMH module dependencies loaded in memory when you load your 15 DQMH modules. It also increases the size on disk for each of your PPL. The solution to this problem is to compile the DQMH dependencies into a PPL, and then have each of your DQMH module depending on this PPL instead of the DQMH code in vi.lib. This way, all your DQMH Module PPLs will depend on the same DQMH core code, also compiled into a PPL.

The best way to do this is first to complete all your DQMH modules as you would do normally, so you can benefit of all the scripting tools offered with this framework. Once done,  create a new LabVIEW Project, then create a new Library (lvlib) and put the DQMH dependencies into that library (the 3 classes you need to put in the lvlib are: Delacor_lib_QMH_Message Queue.lvclass, Delacor_lib_QMH_Module Admin.lvclass and Delacor_lib_QMH_Cloneable Module Admin.lvclass). Save all your library and build it into a PPL. You can then close this project. Now if you open any project where you have a DQMH module, it will now call the lvlib that you previously created for the DQMH dependencies. You can now right click on this lvlib, select “Replace with a Packed Library” and choose the DQMH PPL that you’ve just built. Once you’ve updated all your DQMH modules to depend on the DQMH PPL, you can open the DQMH lvlib (the one you built into a PPL), remove everything from the library and save all. This way, you put back the DQMH dependencies in a “normal state” so you can continue to create DQMH modules normally. Now, if you want to add Events in a DQMH module that depends on the DQMH PPL, the scripting will work, but it will use the DQMH dependencies from vi.lib. You will then have to manually replace the DQMH Vis with the ones from the DQMH PPL. It is not a big deal, but of course it is better if you’ve completed your modules first.

That’s being said, what you want to do will work as long as you don’t make any change to the public API of your DQMH modules (Start Module, Stop Module, or any of the Request to the module). If you do, you will then also need to update the caller EXE which uses those Vis. Otherwise, you will be able to make changes to your DQMH module, rebuilt it into its PPL, replace the PPL with the new one on the end-user’s computer, and after you restart the EXE, it will use the code in the new PPL.

 

In my case, I went a little bit further because I wanted to use a plug-in architecture and only load the DQMH Module PPLs in memory when needed by the application. For this, I had to standardize my DQMH modules, meaning that I now have only 1 Request and 1 Broadcast. Those are generic so the argument is just a variant and it is the same for each DQMH Module in my application. I created a LabVIEW Class with few methods: Start Module, Wait for Module Events to Synchronize, Stop Module, Send Request Event, Broadcast Event. Then each DQMH Module contains a child class of the one just mentioned, and is overridden accordingly to operate on its own DQMH Module. I can then use the parent class code only in my caller EXE application, and the PPL for a particular DQMH module will be loaded in memory only when needed

The drawback of this approach is that you lose some of the capabilities of DQMH by having a unique request or broadcast event for different operations, instead of having specific requests or broadcasts for each module.

 

Let me know if you have further questions. What I’ve explained here is a little but raw, but this is something I’ve done already, it is working well and I can give you more directions if you need.

 

Regards, 

Matthias.



Matthias Baudot | Software Architect | Founder at STUDIO BODs


STUDIO BODs     BLT for LabVIEW     LabVIEW Champion     Certified Professional Instructor     DQMH Trusted Advisor     GCentral Sponsor


 Check out my LabVIEW presentations and videos!

Message 3 of 7
(5,884 Views)

Matthias,

 

thanks for explaining how you went about things in so much detail. 

 

I'm working on a generic networking mechanism for our DQMH modules and therefor need to abstract communication, too. I was just having a code review, discussing the aspects of strong vs weak data-type safety, exactly the thing that you describe in your second paragraph. If it is not too much to ask, I'd be very interested to hear or see more. Do I understand correctly that you created a class-based messaging architecture on top of your single request/broadcast events?

 

Thanks in advance, and regards

Joerg


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

0 Kudos
Message 4 of 7
(5,876 Views)

Hi Matthias,

 

Thank you for the quick and detailed response! Sounds like a really good way of developing a plug-in style architecture using the DQMH. You've given me plenty to work with, now just need to get on with coding!

 

Thanks Again,

 

Joe

0 Kudos
Message 5 of 7
(5,867 Views)

Hello Joerg, 

I apologize for the delay to reply. I was travelling all last week and it was not easy to follow up on this.

To explain more what I did, it's not really a class-based messaging architecture, it is more a class-based UI modules architecture.

I'm using the DQMH Modules as UIs that can dynamically be loaded in different subpanels or other UIs. The hierarchy of the class is used to determine what type of UI / DQMH Module it is, so the module knows how to behave (each DQMH Module library contains a class of its UI type).

Then, to be able to communicate between my modules regardless of their UI Type, I'm using a generic Broadcasts (all the modules are register to it) called "Message sent from Module". The argument of the broadcast are a Message string, a Data variant, and the ID of the sender Module. With this information, any module knows what to do when a message is received.

This type of framework works well for what I want to do, but it might not ideal in your case.

I had the chance to review a little bit some of your architecture documents regarding your Network Communication framework with DQMH and I think you are on the right path.

I'm now back from my vacations so we might be able to set up a code review with Fab if you want.

Regards.



Matthias Baudot | Software Architect | Founder at STUDIO BODs


STUDIO BODs     BLT for LabVIEW     LabVIEW Champion     Certified Professional Instructor     DQMH Trusted Advisor     GCentral Sponsor


 Check out my LabVIEW presentations and videos!

Message 6 of 7
(5,726 Views)

Matthias, 

 

I'd love to hear your thoughts on the networking proof of concept. Also, I'm currently working on other things based on DQMH, perhaps that would also make for some interesting discussions.

 

Fab was on vacation, too, so we haven't had a chance to talk it through yet. Let's arrange something together! I'll send you a PM.


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

Message 7 of 7
(5,722 Views)