LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Malleable VIs in Packed Project Libraries

Solved!
Go to solution

Here's the code (again)

 

See comments in Sandbox.vi and the IConfiguration.lvclass virtual folder of methods. Changing the API's access scope from Public to Protected changes the run-time behavior. You need to control-click the run arrow of the caller (Sandbox) to force the access scope change to recompile before running.

 

Ethan

0 Kudos
Message 21 of 25
(930 Views)

@sdusing  escreveu:

So is it true that you cannot have malleable vi's made publicly available from a packed project library?  I've been able to create a PPL that internally uses a malleable vi, but any public scoped malleable vi's are not available from the PPL file.



That's correct. Actually, you cannot have any public inline VI in your PPL. That's because (please someone correct me if I'm wrong) inline VIs are like a piece of code that you can insert directly in your block diagram. Since PPLs include only precompiled code, it wouldn't make sense to have these "pieces of non-compiled source code" available in the library.

Message 22 of 25
(916 Views)

@EthanStern  escreveu:

Here's the code (again)

 

See comments in Sandbox.vi and the IConfiguration.lvclass virtual folder of methods. Changing the API's access scope from Public to Protected changes the run-time behavior. You need to control-click the run arrow of the caller (Sandbox) to force the access scope change to recompile before running.

 

Ethan


I tested your code and couldn't find a solution. Actually I saw even other strange error situations that maybe you could try to reproduce and see by yourself.

First of all, since VIMs are not debuggable, your problem was difficult to see since the type specialization structure with that last case throwing an error would always leave your code unbroken at edit time. So I called the Read DBL Configuration.vi in the last case of the type specialization structure with constant input values as shown in the attached snippet, letting us see the code break already at edit time (and it really does).

 

Last case.png

 

Right away, if you change the access scope of the folder you marked to "Protected", you'll see that you cannot run Sandbox.vi anymore. The error pointed in several VIs is that a Polymorphic terminal cannot access this data type, even in non-polymorphic terminals.

From this point, if you enable the option Mark as modifier in the Data Value Reference Read/Write node in your In-Place Element Structure and recompile Sandbox.vi, the error result changes. After that, the error shown in Read Configuration.vim is that the the VIM called inside it does not support the wired data types (without pointing any specific error spot or broken wire).

 

Another strange behavior that I noticed but couldn't investigate properly came if I changed the VIs in the "CHANGE to PUBLIC or PROTECTED" folder from non-reentrant to shared clone reentrant. If you try to play with these options you'll probably see these errors I mentioned switching between one and another.

0 Kudos
Message 23 of 25
(903 Views)

@hbaron93 wrote:

@sdusing  escreveu:

So is it true that you cannot have malleable vi's made publicly available from a packed project library?  I've been able to create a PPL that internally uses a malleable vi, but any public scoped malleable vi's are not available from the PPL file.



That's correct. Actually, you cannot have any public inline VI in your PPL. That's because (please someone correct me if I'm wrong) inline VIs are like a piece of code that you can insert directly in your block diagram. Since PPLs include only precompiled code, it wouldn't make sense to have these "pieces of non-compiled source code" available in the library.


As of LabVIEW 2019 when you try and create a PPL build specification with a public or community scope malleable VI, you're warned at the "Source Files" tab (when selecting the lvlib file to build) that this is not allowed.

It does however break any existing libraries' build processes, as I recently discovered (previously it just didn't appear, as described in the first couple of posts of this thread - this is probably an improvement, but was a bit surprising when CI started failing...)


GCentral
0 Kudos
Message 24 of 25
(824 Views)

@AristosQueue (NI) wrote:

Mads doesn't have the VIs shown in the video anymore. He tried to recreate but could not replicate the issue. I tried several variations and could not replicate. If anyone else sees this issue, please take the time to file a bug report with National Instruments, with attached VIs. It's apparently more of a corner case than originally believed, so I'll need VIs to replicate and fix the bug.


I have the same strange behaviour with VIMs in LV 2019 SP1, as shown in the video.

However for me, this has nothing to do with PPLs, nor libraries or classes.

I managed to create a minimalist example that reproduces the bug.

It seems to happen when there is another VIM inside a Type Specialization Structure (which is inside a VIM).

(I also tried to issue a bug to the support, but I got an error message saying it could not create the service request)

0 Kudos
Message 25 of 25
(697 Views)