DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

DQMH as PPL + API Tester

Solved!
Go to solution

Hi All,

Are there any best practices for including the API Tester of a module when distributing a DQMH module as a PPL? The API Tester is not park of the Module Library, so it isn't packaged with it by default. In my PPL build on the Source File tab I specified the Test My Singleton API.vi to be Always Included and under Source File Settings the Test My Singleton API.vi shows as Always Include with Destination of My Singleton.lvlibp as I expect.

 

When I build the PPL, there doesn't seem to be any Test My Singleton API.vi inside. My goal with including the API Tester with the PPL is so developers using the module can use the API Tester as a sniffer. Is it okay to just include the API Tester inside My Singleton.lvlib? Is this a bug in the Build Spec for PPLs? (I was also seeing inconsistent behavior when checking Exclude Dependent Packed Libraries in the Additional Exclusions tab.) Maybe I could instead add a Post-Build action to copy the Test My Singleton API.vi into the build destination directory?

 

Sorry if I'm missing something obvious. I'm running DQMH 4.2. Thank you!

0 Kudos
Message 1 of 3
(2,521 Views)
Solution
Accepted by topic author A_Tamalonis

Hi,

 

We move the API Tester inside the library right before building the PPL. This is the best way to ensure that the API Tester keeps the links with the VIs that are inside the PPL after building. 

 

There are ways to do this as a Prebuild VI or you can make it a manual step in your build process.

 

My suggestion is to then move the API Tester back out of the library. We want to have the API Tester out to make sure we never accidentally call private VIs in the library. The API Tester is there to ensure that we know how to exercise all the public VIs in the library.

 

Also, I suggest you move to DQMH 5.0. You could build, with earlier versions, the  DQMH libraries into a PPL (so you don't have to include them in every DQMH module you build into a PPL). Matthias has a good demo about this. Now with DQMH 5.0, you could create your own DQMH Templates that point to the VIs in the PPL and when you create a new event, you can specify to use the enqueue function from your PPL as opposed to using the one from the package.

 

Video on one way to package DQMH into PPL: Bottom of this blogpost https://delacor.com/techniques-for-starting-your-dqmh-based-project/

 

I hope this helps.

 

Thanks for your trust in DQMH,

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 3
(2,462 Views)

Thanks for the reply, Fab!

 

I noticed DQMH 5.0 was out when writing my post, and on your suggestion I updated my modules last week. Great job with the Validator tool, by the way. It was really easy to update everything. I had to do two of the Start Module VIs by hand, but that was a good experience to understand what's going on under the hood, and my other Start Module VIs all updated automatically when I moved the controls I added out of the main case structure.

 

That's a great point about keeping the Tester outside of the library so it can't call private VIs. It shouldn't be too much work to do manually for now.

 

Thanks for linking to Matthias' post. It was helpful in deciding to try using PPLs in the first place!

 

I'm really enjoying DQMH, especially after working on a QMH project that was getting a little out of control.

 

-Anthony

0 Kudos
Message 3 of 3
(2,438 Views)