Best practice when using an DQMH API in PPL Plugins

[kubes_ch]

Hi everybody,

I have some trouble, finding the best solution to use the API from a dqmh module in a plugin.

I have two modules, let's call it A and B. A is the mainmodule and starts and controls module B. Because there are so many different and yet undefined programmsequences who will be executed in module A, we decided to implement a plugin structure there. With this structure we will be able to outsource all this different programmsequences and can replace them, without touching the module A. Because of this decision, the plugins need the API of module B as well to communicate with this. Most of the the time, there is more than one module loaded but they running all sequential.

Ways that are not working 🙂

• using the API in the plugins because the LV compiler will build the module B in every ppl
• ..

Ideas:

• Build module B as ppl, start the module B.lvlibp from module A and use the API in the plugins
  • as consequence, module B.lvlibp has to be in the same directory like the plugins
• Build a "interface" for all the API events, while loading and intitalizing the plugin pass the event references to the plugin and use it. Create a "dummy" API and work on the passed references
  • in my opinion this is error prone and lot of double coding

Are there some experiences or best practices to handle this or are there some other ideas from the community to help to solve my problem?

Many thanks in adance

Matthias

[FabiolaDelaCueva · Accepted solution]

Check out the presentation that Matthias Baudot made at GDevCon 1 or the one at NI Week, he shows a demonstration on how to package DQMH into a ppl for a plugin architecture.

Go to http://bltforlabview.com and go to the Conferences tab.

Regards,

Fab

[kubes_ch]

Good Morning Fab

thanks! This is the best collection around the ppl theme! The idea around creating a ppl from all the dqmh modules was in my mind, but i thought there must be an "easyer" way

One point is still open, if i do it in this way, all ppl's must be at the same place, because labview does the linking in the same folder level, when we select "Exclude dependent packed libraries". How can i change this, that i can organize the ppl's on the system. I would store the "system" ppl's in one place and the plugins in an other place. But all of the plugins depend on a system ppl.

Regards

Matthias

[mbaudot]

Hi Matthias, 

When you build PPLs, they store their paths relative to each other.

Let's say you want your system PPLs in C:\My PPLs\System

and your plugin PPLs in C:\My Application\Plugins

Now, let's say that the Plugin1 PPL depends on System1 PPL.

First, you have to build System1 PPL. Make sure to configure your Build Specifications so it builds into C:\My PPLs\System

Second, open your Plugin1 PPL and make sure it depends to the System1 PPL that you just built and that is located in C:\My PPLs\System.

Then, make sure to configure your Build Specifications so it builds into C:\My Application\Plugins, and build Plugin1 PPL.

At this point, the LabVIEW Application Builder will store in Plugin1 PPL the relative path to find System1 PPL from C:\My Application\Plugins to C:\My PPLs\System.

As long as you install your PPLs the same way you built them on your deployed systems, it should work and Plugin1 PPL will be able to find System1 PPL.

Regardless of the above, you can use the "custom configuration file" (https://www.ni.com/docs/en-US/bundle/labview/page/using-a-configuration-file-with-a-stand-alone-appl...) of your final Executable application to tell it where to look for dependencies, which includes your PPL.

In this case you would add the following tokens to the configuration file:

viSearchPath="C:\My PPLs\System\*;C:\My Application\Plugins\*"
ShowLoadProgressDialog=False

Hope this helps. Let us know if you are able to make it work or if you have further questions.

Regards,

Matthias.

[kubes_ch]

Hi Matthias

thanks for this additional informations! I didn't know that i can tell the application where to find the dependencies.

For me, it was not clear, that labview stores the relative path to a dependent PPL if i build a PPL. At some point in a past project, labview always copied the dependent PPL in the same directory like the targetdirectory. But i don't remember the exact project setup...

It works like expected! Thanks

Are you guys attending the CLA summit in Krakow? So i can spend you a beer for this good answer!

Matthias

[FabiolaDelaCueva]

---

@kubes_ch wrote:

...

It works like expected! Thanks

Are you guys attending the CLA summit in Krakow? So i can spend you a beer for this good answer!

Matthias

---

I will be there, you will need to join me in convincing Matthias Baudot to get his CLA, he only needs the certification as a formality because he already does the job of a CLA and knows plenty more than several CLAs I know (including myself). He just needs to find the time ;). I am glad he did get recognized as a LabVIEW champion, it was overdue. 

Matthias Baudot, don't hate me for calling you out in public, please 😉 You know I mean well.

[mbaudot]

Hi Fab, 

How could I hate you after all the good things you said on me? I prefer thanking you for your trust, your consideration and for always pushing me to go beyond and further. The day I will finally schedule my CLA exam and pass it, you'll have a great responsibility for that and I will thank you again!

Matthias, glad that everything works for you now. As Fab said, I'm not attending the CLA summit. I'm sure there will be another occasion for a beer together.

BTW, I really like your first name 😉

[Taggart]

I think we should just skip the formalities and give him an honorary one.

[D1140]

I am not getting any idea from this video.

And the example that i downloaded has depencencies and not able to open the project.

Do you have any other refrence or documentation that shows how to package DQMH module to ppl.

[joerg.hampel]

Perhaps this thread can help you along some more: 

https://forums.ni.com/t5/DQMH-Consortium-Toolkits/my-DQMH-PPL-and-VILIB-PPL-best-practices/m-p/41559...