Cannot build PPL - Healthy VI breaks when called.

[CoastalMaineBird]

I ran into this some months ago, and wrestled and wrestled with it.  I DON'T KNOW what fixed it, but it's come back again.

i'm using a series of PPLs (.lvlibp; packed project libraries). 

On my main machine (Win7, LV2013) everything builds fine.

I moved the whole package to a virtual machine running LV2015 (also running Win7), where I have to rebuild (can't use 2013 PPLs in LV2015).

In the rebuild process, I hit a snag, building ADDON TOOLS.lvlibp.

One VI in this lvlib uses a VI from a previously built PPL, ADDON TOOLS-RT.

When building  TOOLS, LV complains that a VI in ADDON TOOLS-RT is broken (not executable).

In spite of the fact that ADDON TOOLS-RT just got built without error, LV complains.

The message is "A VI in the lvlibp cannot be recompiled to match an external dependency."

REALLY, NI ? Is that the best you can do?  "Something's broken but we're not going to tell you what" ?

In any case, I boiled it down to four VIs.  Two of those call the other two, so I think it's only two.

Here's a <JING> to show the issue.

Note that I can load the project, look in the dependencies, and load the prerequisite VI ( "Convert Control to Properties").  It LOADS HEALTHY (unbroken) .

I then load the dummy Vi "YYY", which does nothing on the diagram except call "Convert Control to Properties" and that breaks the subVI ! !

It's sitting there healthy, but when i want to actually call it, it says "No, no, I'm broken!".

How is that possible?

[CoastalMaineBird]

As I said, this whole thing works fine under LV2013.  

There are lots of other dependencies that DO NOT cause this behavior.

The only thing I can think of is that the two that seem to cause it are both recursive (They call themselves).

Here's the code in question: it's called PUT PROPERTIES INTO CONTROL.  Inside that FOR loop, it calls itself.

Note, the logic works.  I understand recursion, and when it works, it works well. 

It strike me that I have created a dilemma, though.  Remember that this is going into a PPL.

The recursive call is a call to the LVLIB version.  But in the PPL, I want to call the LVLIBP version .

Maybe this is trying to put a call to a non-PPL version into the PPL, and we have namespace collision?

The thing is, it actually works in LV2013.

Maybe LV2015 has some stricter rules?

[CoastalMaineBird]

If I change the prerequisite (recursive) VI to not call itself DIRECTLY, but INDIRECTLY:

The same basic failure persists, but now the error message is different:

Now, it's "Bad Connection to an External Routine".  Not that I need to know which one, or anything...

Maybe that static ref is still tripping me up.  Although, that is just for TYPE - the NAME should provide the proper version (LVLIB or LVLIBP).

I don't know about the innards of PPL construction, but somewhere, LV has to change the name "Some Library.lvlib: Some VI.vi" into "Some Library.lvlib<b>p</b>: Some VI.vi", if the VI being called is in the same LVLIB.

It looks like that applies EXCEPT if the VI being called is yourself?  Don't know of a reason for that.

Any other ideas?

[CoastalMaineBird]

Going back to fundamentals, I built a simple FACTORIAL project + VI.

The FACTORIAL function can be defined as F(N) = N * F(N-1) if N >1, and F(1) = 1.

A classic case for teaching recursion.

Doing this the simple way shows no problem - with the PPL built for the host platform (Win7), there is no issue - it works fine.

HOWEVER

My initial example is built on the RT side of a project, and the caller (YYY) was built on the host.

I do this in my real project because there are some libraries that contain no host-specific code, so they are usable on either host or RT.  some libraries have host-specific code (menus, dialogs, etc) and that makes those PPLs unusable on the RT side.

If i build my FACTORIAL library the way I do in the real project - it fails. Same symptoms.

[cblanchard]

Hi CoastalMaineBird,

After looking through the combination of errors that you have been receiving it seems that this document will be a great resource for troubleshooting.  In terms of "A VI in the lvlibp cannot be recompiled to match an external dependency," did you place the dependencies in the top-level library before building the packed library? This is further explained on the third to last bullet in the link above. 

Also,  when correcting the error that you are receiving for "cannot find a subVI or external routine" it can be difficult to identify what is missing.  Have you had the chance go through your subVI's individually to see if they loaded properly?  This error can arise often when using the "Call Library Function Node," as explained here.  Lastly, it could be helpful to do a LabVIEW repair. I have identified cases where this fixed the error.

[CoastalMaineBird]

Thanks, cblanchard

The bullet item you mentioned did NOT resolve the problem, since I simplified things to have a single recursive VI and still saw the problem. It's not an issue of things not being included in the LVLIB.

However, the FIRST bullet item might explain things:

• If a VI calls a packed library on one target and you open the VI on another target, when the VI calls the packed library, the library tries to open on the original target. If the new target has another operating system or a different version of LabVIEW, the packed library cannot open on the new target, and the caller VI breaks. If you want the VI to call the packed library on the new target, rebuild the library for the new target.

Review of my situation:

--- Things work on my main machine: Win7 LV2013 and PXI 8196 LVRT 2013

--- I moved to a VM running LV2015, (BUT WITH THE SAME PXI 8196 LVRT 2013 box !)

--- I am building the PPL to run on LVRT, but I am actually USING it on the host.

(I do this to clearly distinguish PPLs which MAY run on both host and RT, and PPLs which may ONLY run on host).

--- If I simplify to a single recursive factorial VI in the PPL, and the PPL is built on the host, then there is no problem (both PPL and host are LV2015).  It builds fine and runs fine.

--- If I more closely simulate my real environment, by building the PPL on the RT side, it fails with these weird errors.

The reason is, that when I specified the target in the project, I specified my real RT box, and LabVIEW figured out that it's running LVRT 2013 ! !

So, therefore, EVEN THOUGH I am asking to run the PPL on the host (and thus in the same environment as the caller), it sees the PPL as being compiled for LVRT 2013 (even though it was compiled on LV2015) and that violates the above rule.

My problem is that LabVIEW is not smart enough to tell me that was what's happening, and I wasn't smart enough to figure it out until your post.

Thanks.