How to handle private VIs in packed libraries?

[cpiccoli]

Hi everyone, 

I have a DQMH library that i would like to build as packed library.

If i keep the standard DQMH scopes (with some folders as private) the built VIs do not work, if i set all the VI to be "public" they do work.

As i use packed libraries in TestStand it is not optimal to have 100 different VIs of which only 10 are used.

Is there any way to include private VIs in the build or to "hide" some VIs?

Thanks in advance

[avogadro5]

What makes you say the built version doesn't work? My company builds these modules into packed libraries with the default scopes all the time and they seem to work the same as the source versions.

[crossrulz]

What version of LabVIEW are you using? I had this problem with VIMs being built into a PPL in LabVIEW 2019SP1: PPL will not build if a private VIM is in a virtual folder. That bug was fixed in 2020SP1.

[cpiccoli]

---

@avogadro5  ha scritto:

What makes you say the built version doesn't work? My company builds these modules into packed libraries with the default scopes all the time and they seem to work the same as the source versions.

---

As soon as i hit the "Start Module" the module does not run and i get an error related to DQMH synchronization.
If i change from "private" to "public" it immediately works, and the synchronization VIs are packed in those private folders.

---

[cpiccoli]

---

@crossrulz  ha scritto:

What version of LabVIEW are you using? I had this problem with VIMs being built into a PPL in LabVIEW 2019SP1: PPL will not build if a private VIM is in a virtual folder. That bug was fixed in 2020SP1.

---

LabVIEW 2021 SP1

[avogadro5 · Accepted solution]

---

@cpiccoli wrote:

---

@crossrulz  ha scritto:

What version of LabVIEW are you using? I had this problem with VIMs being built into a PPL in LabVIEW 2019SP1: PPL will not build if a private VIM is in a virtual folder. That bug was fixed in 2020SP1.

---

LabVIEW 2021 SP1

---

I have had issues in the past, specifically that version, where this option would erroneously remove needed members and cause breaks which manifested as exe builds that opened with broken arrow. Because DQMH has a separation layer between the main.vi and the public VIs, it's possible for the public VIs to not be broken while main.vi is broken, which manifests as errors from start module.vi.

So my suggestion is try unchecking "Remove unused members of project libraries" in the build spec. If this works, congratulations you have "won" checkbox roulette.