01-09-2019 12:06 PM
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
01-10-2019 03:56 AM - edited 01-10-2019 03:57 AM
@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.
01-10-2019 04:52 AM - edited 01-10-2019 04:54 AM
@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).
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.
06-18-2019 08:52 PM
@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...)
05-03-2020 04:59 AM
@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)