LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Bug: PPL will not build if a private VIM is in a virtual folder

So I have a situation where I want to build up a polymorphic VI to handle a bunch of numerics, strings, or Booleans.  For the numerics, I created a malleable VI so the core is the same.  I set the vim to be private to the library.  But when I try to build my PPL, I get an error stating "The top-level library you specified contains an exported malleable VI."  But I don't.  The malleable is private, so it should not be exported.  I abandoned the library, just making the cases I absolutely needed and duplicated code and it build just fine.  So a few months later, I came back to this library.  After some experimenting, I discovered that the PPL will not build if the private VIM is in a virtual folder.  It does not matter if this virtual folder sets the access or not.  VIM in virtual folder causes an error.

 

NOTE 1: I discovered this bug in 2019 SP1, but the example project is in 2020.

NOTE 2: My exact situation puts the VIM in a class inside of a library.  If the VIM is at the top level of the class, the build will work.  So I do have a work around, but it does hurt my project organization.

 

So in summary...

This causes a build error:

 

This does not:


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 1 of 5
(1,773 Views)

I confirm that the bug exist in LabVIEW 2020 f0 and that moving the vim outside the virtual folder the PPL builds ok

0 Kudos
Message 2 of 5
(1,509 Views)

I can confirm that this behavior still exists.  Has there been a bug report to NI on this?

Steven Dusing
CLA, CTA
0 Kudos
Message 3 of 5
(1,413 Views)

Just played around with this bug with LabVIEW 2020 SP1 and it appears to have been fixed!  It did not show up in the fixed bug list, but I'll still gladly take it.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 5
(1,360 Views)

To those hitting this bug and not knowing, it shows up in the AB_API with error 1057 if you take a library reference and use it with "NI_AP_API_PPL.lvclass:Set Top Level Library.vi"

 

An example output:

 

Error 1057 occurred at To More Specific Class in AB_PackedLibrary.lvclass:Page_Source_Can_Add_to_Top.vi->AB_API Can Add.vi->NI_AB_API_PPL.lvclass:Add.vi->NI_AB_API_PPL.lvclass:Set Top Level Library.vi->Set Name and Library.vi->YourCallingVI.vi

Possible reason(s):

LabVIEW: (Hex 0x421) Type mismatch: Object cannot be cast to the specified type.

GCentral
0 Kudos
Message 5 of 5
(872 Views)