Problems running executable with DQMH made into PPL

[ValeraM]

I made several DQMH modules, made them into PPLs and included them into "TestStand LabVIEW Simple UI" example.

Everything works fine at every step of the process including the whole project when ran in development environment. When I build executable from it some of my modules are not executable.

I only found Issue  #320485   in LabVIEW known issues database with no workaround listed.

Does anybody know how to fix this kind of problem?

Thanks.

[CyGa]

Hi, 

Just to be sure, where are the ppl called?

Within a sequence or within the UI code?

Or both?

[ValeraM]

Eventually I plan on calling PPL  files from both TestStand UI and from LabVIEW. 

What I am having trouble with is some modules become broken (not executable) when converted to exe.

Cannot figure out how to find the issue since everything is working in development environment. 

[CyGa]

Just as a note,

A LabVIEW VI cannot be called in the UI AND in a sequence.
When using a TestStand OI, the domain in which the sequence runs the VIs is the domain of the UI.

So the first code reserving the VIs (UI or sequence (usually the UI)) will prevent the other execution to use the same VIs.

Except if you create a specific project that references your PPL, and in your sequence, call the VIs listed in the PPL specifying the project. In that case the project will create a domain separating the UI code and the sequence code.

In case this is not the issue, can you post the error code you're seeing ?

[ValeraM]

I think I successfully resolved the issue you are describing. I do have some DQMH modules being called by both TestStand UI and LabVIEW. They share application instance and I can pause my sequence and adjust data via LabVIEW interface. Pretty much what I want. 

My problem is that some modules break when transferred to the executable. The modules itself are relatively big. I will try to strip one down and post it shortly.

Thanks

[ValeraM]

I made project a little smaller and the issue is showing up even earlier in the process. Hopefully this will help in troubleshooting.

The project consists of  Common project that is used to build "Common.lvlibp". This packed library is used to share common vis and globals between DQMH modules. Then there is a "Project 11.lvproj" that has GCU Control Module built using DQMH script. There is a "No PPL Test.vi" that only starts and stops module. I made changes to "Get Module Main.vi" to report it's path and have "Start Module.vi" reporting  Execution state of "Main.vi". When "No PPL Test,vi" ran from development environment and from "No PPL Application.exe" it is showing the path of the "Main.vi" followed by it's Execution state which is "idle". Just like it supposed to do. 

When GCU Control Module is built into "GCU Control Module.lvlibp" I can go to Main.vi inside that packed library and it is not executable. 

In my original project before I moved it and stripped some parts of it I could run Main.vi from packed library but the next step where I would create executable based on this library would not run and execution state was reported as "Bad".

[CyGa]

I didn't look at the code yet, but that's typical of code that should be 'always included' and which is not...

Also the build order between several lvlibp referencing each other is important.

This link would be of intereset : https://forums.ni.com/t5/DQMH-Consortium-Toolkits/Best-practice-when-using-an-DQMH-API-in-PPL-Plugin...

Correct me if I'm wrong, but your problem isn't really related to TestStand right ?

[ValeraM]

As you can see from my attached project I am having problem even before I put TestStand UI and DQMH module together. I am having issues building my PPL before it is added to the Top Level Project.

In my example Common.lvlibp is used as dependency and is always included no matter if I specify "always included" or not. Obviously I build Common.lvlibp first. 

I have seen the article you referenced. I have tried to take DQMH classes out of vi.lib and package them into Common.lvlibp as instructed in the referenced article (video) but run into issues with polymorphic vis not showing up in PPL. So I left the classes as they were originally. They seem to be working fine. In my example there is only one DQMH module so duplicate DQMH classes in PPL should not be a problem. Unless I am totally wrong of cause.

[Brett_Percy]

Hi Valera,

I ran into a similar problem with the main.vi in a module being broken, and was able to fix it at least for my case

https://forums.ni.com/t5/DQMH-Consortium-Toolkits/Trouble-with-DQMH-module-using-OPC-UA-in-a-packed-...

The short version is to make the main.vi public as well as include its block diagram when building the library.  This should allow you to see what actual error there is - apparently LabVIEW is hiding the error details because of the access setting in the library

Cheers

Brett