LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VI Package Manager Fails to Build with Malleable VIs (VIMs)

VI Package Manager is complaining that the source files are missing for the malleable VIs I have in my toolkit. I've tried mass compiling and the source code works without any issues. VIPM has the VIMs themselves, but apparently not the background VIs.

LabVIEW: 2018.0f2 (32-bit)

VIPM:2018.0.0f1

 

I know others have had this issue, but I am unaware of that their workaround was. I don't know if this is relevant, but all of the malleable VIs are a part of a class.

Any thoughts to why I'm seeing this behaviour?

Source VIs Missing.JPG

 

Missing Source VIs.JPG

 

 

 

0 Kudos
Message 1 of 7
(1,453 Views)

I'd put a shout out to Jim 

<jim.kring@jki.net>

There must be an update available.


@McQuillan wrote:

VI Package Manager is complaining that the source files are missing for the malleable VIs I have in my toolkit. I've tried mass compiling and the source code works without any issues. VIPM has the VIMs themselves, but apparently not the background VIs.

LabVIEW: 2018.0f2 (32-bit)

VIPM:2018.0.0f1

 

I know others have had this issue, but I am unaware of that their workaround was. I don't know if this is relevant, but all of the malleable VIs are a part of a class.

Any thoughts to why I'm seeing this behaviour?

Source VIs Missing.JPG

 

Missing Source VIs.JPG

 

 

 


 


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 7
(1,426 Views)

For what it's worth, we ran into this exact same issue.  Removing the VIMs from the Class solved the problem entirely.

The VIMs were still inside of a Library, so the issue seems to have something to do with the class inclusion.

0 Kudos
Message 3 of 7
(1,380 Views)

Yeah, that's what I ended up doing - I was just using VIMs as a shortcut to creating polymorphic VIs. I was lucky I only had a couple to rewrite.

The phrase 'Write once, build often' springs to mind!

0 Kudos
Message 4 of 7
(1,373 Views)

If someone is willing to create a very simple example project that demonstrates this issue, I'll have our team at JKI look at what's causing the error.

JKI Blog
0 Kudos
Message 5 of 7
(1,318 Views)

Jim,

I'll look into doing this in the next couple of days. It strikes me as a bit inconsistent behavior, because I would swear that I have projects where there are vims in classes/libraries that build just fine... however we had one particular project where we had this error, and the resolution was to remove the vim from the class.

 

I'll do a little digging and get back to you!

0 Kudos
Message 6 of 7
(1,308 Views)

This is a little disappointing this was never investigated by JKI, even with the release of VIPM 2019, which still has this issue. I just came across this today. Malleable VIs are a two year old feature at this point.

 

This is relatively trivial to reproduce, even from the comments here. The problem (or at least one of the problems) is when you have a malleable VI calling another malleable VI inside a class. VIPM fails to build such a package with this arrangement. Move both malleable VIs outside of the class (in my case into a library containing the class) and VIPM successfully builds the package. If the malleable VI inside the class does not call another malleable VI (or maybe any other VI, I did not test this permutation) then the build succeeds (in my case the malleable VI inside the class called nothing).

 

I am sure there are other permutations of where this does or doesn't work, but the attached project and .vipb file will reproduce this readily with VIPM 2019 and LabVIEW 2018 SP1. The project is setup such that the build fails (the malleable VIs are inside the class).

 

Does the VIPM still use its own custom build process rather than the internal VI Server build system?

0 Kudos
Message 7 of 7
(1,079 Views)