Explain THIS - I dare you !

[CoastalMaineBird]

LV 2013, LVRT 2013

I have a PPL, used in an RT target.

It's simple enough, just reading a message from a TCP connection.

The PPL is my own, it works in other projects, it's known good.

In this one project, containing code that I did not write (involving FPGA and stuff I know little about), there are two particular VIs in the PPL which break.

Oddly enough, I can load them from the PPL and they're fine, and when I load something ELSE, they break.

See this JING - notice how the VIs ("Receive TCP Message" and "Addon Message Receiver") are open and fine.  Then they break when I open the main VI of the project.

The error is that it "cannot find an external routine".

The dependence is ADDON RECEIVER, depends on RECEIVE TCP MESSAGE, depends on ADDON MESSAGE HEADER.ctl, depends on ADDON MESSAGE OPCODE.ctl, all of which are in the same PPL.

Here's another case, this time opening the same VI twice.  The first time (after realoading the project) is OK, the second time, it's broken.

See this JING.

LV provides no tools for helping me figure it out - it doesn't tell me WHAT external thingy is missing (WHY THE HELL NOT?).

Again, this same PPL works fine in other projects.

If I start a NEW project, and put this PPL into it, all is well, until I insert the real code.

The real code is one main VI and 80+ subVIs and controls.

The real code DOES call this "Addon Receiver", and if I disable that in the real code, the real code is buildable (not broken), but the problem still happens.

How is it possible for and "external routine" to go missing, and how do I find the culprit?

[CoastalMaineBird]

So, here is more info:

Another JING shows a brand new project (on left), with the same PPL added to the RT target, and the same test shows no problem - the ADDON RECEIVER can be opened many times, without a problem.

On the right, the old project with the real code (LVLIB) removed, still shows the problem.  the only difference is the old project still has a Build Spec.

So why does one show the problem and one does not?

[CoastalMaineBird]

OK, if I take the old project (which didn't work on the right, above), and remove the PPL (addon tools.lvlibp), and then add it back in, all is well.

I can open the ADDON RECEIVER multiple times, no problem.

I add in the library (eCAS.lvlib), and I can open ADDON RECEIVER multiple times, no problem.

I reconstructed the BUILD SPEC, no problem.

I can BUILD the piece, no problem.

I can SAVE the project, and test the ADDON RECEIVER again, no problem.

When I LOAD the project again, I get a warning about a different path for something.   Now the problem appears again.

The warning is about LVANLYS.dll.  It doesn't tell me where it expected it ("C:\...\lvanlys.dll" is NOT HELPFUL ).

There are at least 20 copies on my C: drive.

I don't know why there are so many copies, or why it's mismanaged here, or what it has to do (if anything) with the TCP RECEIVER.

There are three copies in the DEPENDENCIES list, but they all point to the same 13 VIs as to why they're there (NOT HELPFUL).

[Intaris]

If you hover over the path information for the DLL, does a tipstrip with the full path not appear?

[CoastalMaineBird]

path information for the DLL, does a tipstrip with the full path not appear?

No, it doesn't.  If the thing down below refers to a "private VI", then there is no tip strip.

[CoastalMaineBird]

So, the errors were reduced by something I found - the real code was using items from "eCAS Central.lvlib" as well as "eCAS Central.lvlibp".  That cut down on LV crashing and weird stuff, but the basic problem remains:

If I open ADDON RECEIVER twice, it's OK ythe first time, and broken due to missing pieces after that.

I don't know what LVANLYS.dll has to do with that particular piece, but somehow it's being badly mismanaged:

Notice that the BUILD process complains about the following source file exists in the destination directory.

But the TEMP directory doesn't exist!  It seems to be lying to me.

[CoastalMaineBird]

If I change the Build Spec to put the results into "Temp2", then it complains again:

So, the previous error WAS a lie: it's not that the source file exists in the destination, it's that what it THOUGHT was supposed to be a source file had the same PATH as a destination.

But How did the "source file" (lvanlys.dll) come to be expected in the middle of my code?

And does this have any bearing on the ADDON RECEIVER problem?

[CoastalMaineBird]

Well, a MASS COMPILE showed up a culprit for the LVANLYS thing.

Some VI called BUTTERWORTH COEFFICIENTS, in the VI.LIB.

Don't know how that got changed, but I know better than to go in there and diddle stuff.

If it found it here, why couldn't if find it before?   #MADDENING

[CoastalMaineBird]

OK, so the precursor (eCAS CENTRAL) is apparently now buildable every time.

But when I go to add that to the RT project (the one I started this post about), I get this message.

there's that BUTTERWORTH COEFFICIENTS again.

What is an "xnode" ?

How can I remove something from a lvlibp anyway?

This is all NI stuff, not mine. 

Why are there THREE copies of LVANLYS in the dependencies?

If I ask the project "why is...", the first two copies point back to the same three VIs in the code, the third (broken) one points to 13 VIs...

[CoastalMaineBird]

If I opt to REMOVE that bit of fluff LV complains about, it complains about ANOTHER xnode called "Notch Coefficients".

If I remove THAT also, the thing will load.

But my original problem is still there - ADDON RECEIVER will open once OK, and then open broken.