Preserve (virtual) folder structure in LVLIBP of DQMH module

[ngblume]

Hello everyone,

a rather simple question, which I can't seem to get answered via search:

Is it easily possible to preserve the virtual folder structure, when building a DQMH module into a LVLIBP for use in TestStand?

I'm refering to the folders like "Public API" and "Multiple Instances"..

Given that the option "Preserve disk hierachy" under destinations in the build specification refers to the actual structure on disk, which for DQMH modules means all (most) VIs in one folder, this doesn't make much sense, unless I move all relevant VIs to actual folders rather than solely using virtual folders.

Thanks !

Kind regards

Niels Göran

[ngblume]

Anyone any insights / best practices ??

Or am I the only one struggling with this ?

[FabiolaDelaCueva]

I think this belongs in a feature request for changing how we organize the code in the disk.

The PPL should preserve the virtual disk hierarchy.

We have talked in the past about creating a tool for TestStand that would generate a menu of VIs that you could access from TestStand but that has not gathered enough traction.

https://forums.ni.com/t5/DQMH-Feature-Requests/idb-p/delacor-ideas

I will look for others to contribute to this post (not that I had not tried before but apparently no one jumped to the opportunity!)

Regards,

Fab

[~jiggawax~]

I'm confused by what you are asking.  Why not build the PPL and then code TestStand to the PPL?  We've found it much easier to treat PPLs much like an assembly in C# or dll.  Basically build them then use the "binary" as a dependency. 

Hope this helps.  Let me know if you have any questions about it.

[ngblume]

Hello Fabiola and jigg,

thanks for your answers!

I was more hoping for a general LabVIEW solution instead of creating work for you via Feature Requests to restructure the files on disc.

@jigg:

I do not reallyunderstand what you mean by "and then code TestStand to the PPL?"

We currently build PPLs and usually create TestStand wrapper libs around those PPLs.

But when you are browsing these PPLs in TestStand the VIs are listed in no specific order, but in the order on disc.

At least not in the order / folders they are shown in LabVIEW as virtual folders.

This makes it quite hard, especially for beginners, to for example find the Public API VIs, since the folder structure shown in LabVIEW is not present here as well.

We get around this currently by moving the most relecvant VIs to a subfolder on disc, so that they are shown in a folder (since PPL preserve file hierachy in disc).

When you later use the TestStand wrapper library, you do not have this issue anymore.

Thanks !

Kind regards

Niels Göran

[Nightshade42]

Having just finished a TestStand project (TS2019) in which we integrated DQMH PPLs, I can confirm the same behaviour. For me, it didn't bother me, but I can absolutely see that it would be a lot more convenient to have the option to build the PPL with the virtual folder structure instead of the disk structure.

This question was asked back in 2015 (https://forums.ni.com/t5/LabVIEW/Labview-packed-library-internal-paths-problem/m-p/3122055#M896446). It seems like PPL's have been designed to preserve their relative paths on disk when built. If you want to change the hierarchy, you will need to change it on disk.

By the way, I tried editing the preserveHierarcy property in the lvproj file as suggested at the bottom of the same topic without success.

[ngblume]

Hello,

thanks for your post..
I read through the other threads and the initial question and it reminded we why we have a TS wrapper sequence library in between the LVLIBP and the sequence steps, just like shown here ("Empowering TestStand with DQMH", Corinne Doppmann and Jascha Eisenberg, NIDays 2019 in Munich, highly recommended in general).

By using that approach, at least it is only one place to edit these calls..

Or maybe replace them alltogether with a different function of exchange the calls when you switch to a different device, or, or, or....

Thanks!

Cheers

Niels Göran

[~jiggawax~]

I guess I see the process going something like this:

1. Make a cool DQMH module that works and is well tested
2. Create a PPL and deploy it using NI Package Manager
3. Install the PPL onto your development machine to its deployed location
4. Call into the PPL from TestStand (could be your wrapper sequence file or other sequence file, doesn't matter)
5. Build the TestStand sequence file into its own package
6. Install both packages on the deployed machine and make sure the PPL is in your search directories