Delacor Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

Best practice when using an DQMH API in PPL Plugins

Solved!
Go to solution

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 Smiley Happy

  • 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

 

_______________
GTester - The LabVIEW GUI Testsoftware | Sign in for more information www.gtest.ch
0 Kudos
Message 1 of 8
(499 Views)
Solution
Accepted by topic author kubes_ch
03-19-2019 12:24 AM

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

Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Message 2 of 8
(459 Views)
Highlighted

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 Smiley Very Happy


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

 

_______________
GTester - The LabVIEW GUI Testsoftware | Sign in for more information www.gtest.ch
0 Kudos
Message 3 of 8
(447 Views)

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" (http://zone.ni.com/reference/en-XX/help/371361P-01/lvhowto/including_ini_files_in_apps/) 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.

Message 4 of 8
(435 Views)

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

_______________
GTester - The LabVIEW GUI Testsoftware | Sign in for more information www.gtest.ch
0 Kudos
Message 5 of 8
(378 Views)

@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 Smiley Wink. 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 Smiley Wink You know I mean well.

 

 

Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Message 6 of 8
(371 Views)

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 Smiley Wink

Message 7 of 8
(358 Views)

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

Sam Taggart
CLA, CPI, LabVIEW Champion
DQMH Trusted Advisor
automatedenver.com
Message 8 of 8
(349 Views)