Mystery "VI Failed to Compile"

[CoastalMaineBird]

LV 2013.  Still trying to work toward LV 2017, adjusting all the things that don't work anymore.

So, what is the mystery "VI Failed to Compile" message supposed to mean?

The main program is MoSAIC HOST, which it claims is broken (it's not), because the Vi "Read Table File" failed to compile (it's not broken either).

The READ TABLE FILE is in a PPL.  The program runs OK from the DevSys, but will not build.

[CoastalMaineBird]

Hmmm.   I replaced the allegedly broken VI with a  copy from a backup.  I haven't worked on this, except to move dependencies around, so the backup should be good.

But I get more silliness from the compiler:

It's not broken and will even run, but it will not build.

[Hooovahh]

Delete the compile cache and try again?  Just expect all VIs to have to recompile.  Tools >> Advanced >> Clear Compile Cache.

[CoastalMaineBird]

Did that just now.  No joy.  

Tried enabling DEBUGGING on the PPL - no change.

I can't see anything, even with debugging on, because it works in the DevSys, just not in the build process.

The error is 1003 - not executable.  But I can open it and even run it from the DevSys just fine.

[WNM]

I have seen this behavior one or two times in the past and was always able to clear it up by exiting Labview and then restarting it.

[CoastalMaineBird]

So... if I disable EVERYTHING in the VI in question, rebuild the PPL, and then try to build the main host, it STILL complains that it can't compile.

[CoastalMaineBird]

I copied all the code into a brand new VI, hooked up the terminals and saved it.

Then I threw away the old one and replaced it with the new one.

Still no joy.

I deleted ALL the code and all the front panel items, hooked up dummies to the wires and STILL no joy.

[CoastalMaineBird]

Hmmm.  I renamed the file to "READ TABLE FILE DANGIT", and it still complains about READ TABLE FILE being uncompilable.

[CoastalMaineBird · Accepted solution]

OK, if anybody is interested, here is the problem.

I once had this code in quite a few LLB files.  Been using them since 1990 or so, and this project started out that way.

I've changed practice to avoid those, and I had converted the LLB containing this set of functions to a folder, but I NEGLECTED TO DELETE THE LLB.

Part of the code still linked to the LLB version.  Since I haven't changed that piece of code in some time, it didn't matter and I didn't notice.

But now that a dependency (CTL file) had moved, I had to change the code to point to the new place.

That change was done in the current (.VI) version), and built into the PPL.  But the CALLER to it was actually in the LLB version.

In the DevSys, the PPL gets loaded, and LV substitutes the PPL version of the CALLER for what's really there WITHOUT TELLING ME.  The CALLER in the PPL calls the READ TABLE FILE in the PPL, so the code is all as it should be.

But in the BUILD process, the PPL is not present in the build context, so it uses the CALLER from the LLB, which calls the READ TABLE FILE from the LLB, which is broken.

Arrrrgh.

[CoastalMaineBird]

Now if only it wouldn't do this every time: