Link problem building PPLs with LV2017

[CoastalMaineBird]

Moving a large project to LV 2017, from LV 2013.

Compiles fine in LV2013, been working for years.

i now get an error when trying to build one of my PPLs.

I am sure that all prerequisite PPLs have been built and saved in LV2017.

i get this error:

Of course, searching the "support" page is still useless, so I don't know what it's complaining about.

The code in question is here:

You can see that this VI is NOT broken here. But when I BUILD this into a PPL, it SEEMS to build OK, but then complains after saving things.   And it's not smart enough to TELL me what it's doing. I don't know what file it's trying to write.

If I disable BOTH of those VI calls in the lower right, the error disappears (but of course won't do what I need). Disabling either one by itself is not enough.

Both those VIs are in a previously built PPL called ADDON TOOLS-RT (which was compiled for RT, but has been used on both RT and Windows for some time). Here is one of the VIs.  It uses a TypeDef called UNIT SELECTOR, which is in a separate PPL called Addon DataTypes.lvlibp.

If that TypeDef was the problem, then disabling the VI calls wouldn't cure it, i wouldn't think.

So, what is happening?  How do i find out what the real problem is?  What file is it trying to write? "Missing external dependencies" is so generic as to be useless.

Ideas?

[CoastalMaineBird]

Turning off the BuildSpec's PROPERTIES : ADDITIONAL EXCLUSIONS : MODIFY PROJECT LIBRARY FILE...

doesn't help.

But there's a NEW option:

PROPERTIES : ADDITIONAL EXCLUSIONS : EXCLUDE DEPENDENT PACKED LIBRARIES.

That option is not in LV 2013.

Turning that ON cures the complaint.  Don't know if it leaves things in working order, but it's a step...

[mcduff]

Do you have any VIMs in your library?

See https://forums.ni.com/t5/LabVIEW/Malleable-Vi-Application-builder-Errors/m-p/3656737#M1027473

mcduff

[CoastalMaineBird]

No, I think VIMs came after LV 2013 - I'm coming from a working LV 2013 setup.

And now, everything AFTER the PPL in question is broken - all with "Can't find external dependencies" errors.

but they're right there where they always were...

[CoastalMaineBird]

Oh dear, back to THIS crap again.

if i load the project, the main VI shows up unbroken.  As soon as I SAVE it, crack!

JING:<https://screencast.com/t/7knTVYcuNN>

[CoastalMaineBird]

Great.  Now it has puked on itself and ruined the file:

[CoastalMaineBird · Accepted solution]

OK, I have figured this out.  Here is the problem and solution for anyone who stumbles across this.

LV 2017 (or 16, or 15, or 14) actually fixes a problem with LV2013.

My app has 40+ PPLs associated.  Some of them are addons, some are just so the addons can share data/code with the host without linking back into the host EXE.

The dependency chain is carefully managed - dependencies go in only ONE direction - backwards. A given PPL must depend ONLY on something that is built BEFORE it.  That all works fine in LV2013.

My plan has been to put all the "sharing" PPLs into ONE folder (MoSAIC PPLs\).  There are several projects that build the things, to better manage the dependencies.

But any place in the host should use the VI from the MoSAIC PPLs\ folder, nowhere else.

The problem is that LV2013 made that difficult.  If you have PPL A which uses PPL1, then (absent any special measures) when you built PPL 1, it would build into the MoSAIC PPLs\  folder.  Then when you build PPL A, it would try to COPY the supporting PPL 1 from where it is (MoSAIC PPLs\ )  into the MoSAIC PPLs\ folder.  But that's the same place, and it would fail, complaining that the source files were in the same folder as the destination.

It seems that NI never imagined using more than one PPL in a project, but they did what they did.

SO, I had worked around that by putting a MoSAIC PPLs\ TEMP\ folder in the Build Spec as the destination, and running a postbuild VI to move the one build target down into MoSAIC PPLs\ , and deleting the TEMP folder.

That means that I end up with all the PPLs in one folder and everybody's happy.

Well, in LV 2017, something was different. Something about the paths within the PPLs themselves, I suspect.   In any case, I had to do three things to EVERY build spec to make it work:

1... Remove the TEMP folder from the DESTINATION.  Specify where you want it to go.

2... Check the EXCLUDE DEPENDENT PACKED LIBRARIES box in the ADDITIONAL EXCLUSIONS category of the build spec.  This option is not available in LV2013.

3... Remove the postbuild move-it code.

It took me all day to figure this out, mostly because the error messages are particularly unhelpful.  "This VI has a missing dependency or a bad connection to it", doesn't tell me as much as "VI X is expecting "Y" at path 'Blah\Blah\Blah.lvlibp:Y.vi' and can't find it" would have been useful to point out the path problems.

But there it is.

[dgd.gomez]

Sorry to continue with a closed thread, but I am working with LV2017 and PPLs.

When I work in windows environment, everything works correctly, but when I try to do the same in RT, it does not work.

That is, if I create a project with a library and compile the application for RT, the application launches correctly, but when I change the library for PPL, the application is not launched.

Has anyone worked with LV2017 and RT and can add an example, in which the compiled code can be executed in RT?

Thank you very much.

[protocoled]

Carlos,

I'd give this link a look: http://zone.ni.com/reference/en-XX/help/371361P-01/lvconcepts/packed_libraries/

Specifically, the last section might give you some troubleshooting steps to try. I'd recommend creating a new thread with your issue if it still persists.