Problem Moving PPLs to LV2017

[CoastalMaineBird]

i have a large (1700+ VIs) application I'm producing.

It works fine in LV2013.

in moving to LV2013, I've hit a few snags.

One of them, involving PPLs that are used by other PPLs, is solved by discovering that LabVIEW 2017 fixed an issue that I had to work around in LV2013..  Previous problem and solution

Now I have another problem.

The app is build of several parts.

HOST.exe - this is the main part, running on Windows.

ADDONS used by host - These are PPLs that the user can compile (in a separate LVPROJ).  They get "attached" to the host, by being in a certain folder and operating a command on the host.

PPLs used by host only - these are PPLs used by the host or by the addons, which provide data/code common to the host or to the addons.  For example, the system configuration data is stored in one of these, and either the host or an addon can register  and get notifications if the config has changed in a certain way.

RTHOST.rtexe - this is the main program on an RT box (PXI 8196 in my case, others are possible)

RT ADDONS - there are PPLS that the user can compile (in a separate LVPROJ).  They get "attached" to the RTHOST, at the same time as the corresponding addon gets attached to the windows host.

PPLS used by RTHOST ONLY - these are PPLs used on the RT box to share data/code between the RTHOST and the RT Addons. Similar to the Windows host above.

COMMON PPLS - these are functions common to both the Windows host and the RT host.  Common utilities such as circular buffer management, formatting text strings, TCP Transceivers, etc.  Generic stuff.

Altogether there are 25-30 PPLs built by my process.

I haven't worked on the RT side in LV2017 yet, because I've had so much trouble with the host side.

In LV 2013, as long as I followed two simple rules, I had no trouble building anything:

1--- Dependencies go only BACKWARD.  If B depends on A then A has to be built first.   No problem.

2--- if a PPL has something that is Windows-Only (like a function dealing with menus), then you cannot use that PPL on the RT side.  If a PPL has RT-ONLY content you cannot use ANYTHING in that PPL from Windows.  That's because LabVIEW must load an entire PPL at a time - if anything is broken, the PPL is unusable.

To make that happen, I separated PPLs into the groups above.  I "certified" that certain ones are RT-safe, and that means that they are usable on BOTH Windows and RT.

As part of the "certification" process, I built the dual-use PPLs using the RT side of my projects.  (Since I have far more Windows-only stuff than RT-only stuff).

In LV2013, the dual-use ones were perfectly capable of being used AS IS, on either side of the fence.  The same PPL was deployed in both locations and worked fine.

But now, in LV2017, the same build process complains.   Some of the PPLs built on the RT side of a project get complained about.  LabVIEW reports that they are missing dependencies, yet refuses to tell me what they are.  

A visual exam shows that nothing in this PPL depends on anything outside of it.  A list of VI DEPENDENCIES shows that nothing in this PPL depends on anything outside of it.  Yet still, LabVIEW complains that it cannot find some "external dependency".

Note that the VIs will all load correctly in the DevSys.  It will compile without error.  yet you cannot load it anywhere.

If I move the LVLIB from the RT side to the MY COMPUTER side of the project, it will compile correctly and NOT complain about such things.  

Not ALL VIs within one of these will load broken.  I haven't discovered a common answer among the broken ones.  In one PPL, only one VI is complained about.  In another, there are three.

It's almost as if there are linkages behind the scenes that are different between RT and the host, and these show up differently between LV2013 and LV2017.

I have the host part compiling completely now, having moved some of these from RT to the MY COMPUTER side. My guess is the RT side will screw up when I tackle that.

So, is there a better plan to do what I am doing?  Should I turn on some new option I haven't figured out?

Should I (can I) build two versions (RT and MY COMPUTER) using the same source library?

Ideas?

[CoastalMaineBird]

OK, I was feeling good about having everything on the MY COMPUTER side compile up to the host itself.

But the host itself is a disaster.

Is LV2017 really the unmitigated dog it appears to be?

Either I'm misunderstanding something very basic, or LabVIEW is flat out lying to me.

For example, while loading, it failed to find something, which was located in exactly the same place it's always been.  When I pointed out where it was, exactly where it was expecting it, I get this:

le:

LV just built this PPL not two minutes earlier, but now it's unreadable ? ? ?

WHY?

But that's a lie, because if I wade thru the loading process and then go and find the error, where it's missing, I can replace it from that exact same place, and it's OK. the library IS readable!

I gave up at 120 of those things.  Why do I have to go and find them when the VI told you where they were and they're still there? ? ?

If you ignore everything and start replacing the "missing" things, here is a dialog .

Note that the library it complained about above is perfectly readable.

Also note that it is looking for something in exactly the place where it is, but cannot find it .

Most (all?) of these errors are in two PPLs, both compiled under the RT part of the project.  I suspect that if I go and compile them under the MY COMPUTER, things will clear up.

I understand if I did something wrong, or if things changed that my project might not work anymore, LV should tell me what the problem is, and I'm fine.

But why tell me it cannot find something, when it actually shows me where it is?

Why tell me something is broken when you it was just built a moment ago?

Arrrgh

[CoastalMaineBird]

This is not infuriating at all:

This project had already been converted to LV2017, and compiled perfectly. Now it's going to DELETE THINGS from my project?

[tyk007]

There is a new option in 2017 for PPL backwards compatibility (ie PPLs built in 2017 can be executed in 2018+ runtime engines without re-build) along with other App Builder build specs (http://www.ni.com/pdf/manuals/371780n.pdf). I don't have it installed to check but have a look and see if enabling/disabling this improves your situation (its on the Advanced page).

[CoastalMaineBird]

Thanks for the tip about "future-compatibility".

In the process of going thru every single Build Spec (about 60 of them) to turn that option OFF (I had turned it ON when I had to go through every single one earlier to turn on the EXCLUDE DEPENDENT LIBRARIES option, I found a case where a PPL was built with a SPACE in the name, instead of an UNDERSCORE.  I'll bet the listing above where it looks like it's found something exactly where it was supposed to be are actually different by that character.

Still, that doesn't explain the "unreadable library" or other weird messages.

So, I got the host all the way compiled, by straightening that underscore thing out.  It would have helped if LabVIEW had told the truth about what the problem was, but I got around it anyway.

It is indeed the fact that certain functions can no longer be shared between the host and RT.

For example:

 Notice that the same VI is OK in  MY COMPUTER, but broken in the RT version.

This VI was in a PPL that was previously (LV2013) "certified" for RT use ("certified" just means the I inspected to see there were no windows-only VIs within it).

I used the exact same PPL on both host (Windows) and RT (PharLap) with no problems.

Now, it seems to be a problem.

Here is the code to that VI:

A single compiled version of this exact code works in LV2013 windows and LV2013 RT.  But it has to be compiled separately for LV2017 Windows and LV2017 RT. 

I haven't yet figured out WHAT about this is different.  Maybe the call to the file system is different, maybe the reentrancy is different, maybe static references are different, I don't know.  Some of the others that show this split behavior deal with files, some deal with TCP connections.

So, to avoid figuring all that out, and being subjected to the same torture next time around, I guess I have to move to a system where I use ONE library, and compile it into TWO different PPLs, one for PharLap, one for the host.

No, that won't work: If PPL B needs something from PPL A, then the HOST version of PPL B needs to get it from the HOST version of PPL A, and the RT version of PPL B needs to get it from the RT version of PPL B.

Rats.

[CoastalMaineBird]

OK, after having gotten everything compilable on BOTH sides of the fence (Windows and RT), i went back and turned ON the 'future-proof" switch, on all of the Build Specs.

Rebuilding the whole thing produced tons of errors, of the same kind as before - PPL VIs reporting that they couldn't find dependencies.  Such dependencies don't exist, but LV imagined them.

Turning the switch back OFF restored everything to correct behavior.

So, it's possible that my earlier conclusion was wrong - with the future-proof switch OFF, maybe there is no conflict between the RT version and the Win version.  That's certainly true now, of the one VI I chased - with it compiled for RT, there were errors, but when I moved it to MY COMPUTER, I also turned OFF the "future-proof" switch, and things healed up quickly.

[tyk007]

I haven't read or heard a good, detailed technical description of what the change actually entails in terms of the PPL binary content and changes in the runtime engine(s) (all platforms including RT). We were planning on using this extensively but have yet to try it - if it makes you feel better you may have spared others some pain.

[CoastalMaineBird]

OK, it's NOT just the "future-proof" switch that does things.  There really is something about certain VIs.  I just don't know what the criteria are...

I started over and copied the LV2013 folder into my LV2017 machine, changed the things I know I needed to change (having to do with excluding dependent PPLs), and compiled a few of the early PPLs.

Then, instead of doing every last one, I stopped and tried something - loading the same VI (which was compiled in the RT side) into both an RT vi and a Host VI.  Sure enough, there's the problem again.

JING: <https://screencast.com/t/g3mufAwU>

Notice that one of those VIs is on MY COMPUTER and one is on the RT box.  the VI was compiled on the RT side, so it's happy on the RT side, but drag it to the host, and all of a sudden it cannot find some external thing.

Note that not everything in that PPL is like this.  There are 8-10 VIs in it, and they're all OK except this one.  It's the only one of those 8 that deals with files, so maybe that's it.

But if I compile it on the host side, then it's usable on both sides (if the "Future-proof" switch is off).

Weird.  and FRUSTRATING !

[CoastalMaineBird]

Here's the code for the VI i used above.

This just opens a file and reads  chunk at a time, feeding it to a hash routine (IN THE SAME PPL), to obtain a signature of the file.

Hmmm.  The GET FILE POSITION returns an I64, which I convert to an I32 for my purposes.  I wonder if the problem stems from the I64 usage - the RT (as far as I know) is still 32 bits.  I'm running LV 32 bits, though.

I just wish I knew the rules that I am violating, rather than guessing at them.

[CoastalMaineBird]

if it makes you feel better you may have spared others some pain.

Well, I do this publicly partly to get help and partly to give help.  It's great if someone would point me to a help document that says "you cannot use 64 bit functions in a PPL in both the host and an RT anymore", but it worked fine in LV 2013 and I find no such document.

I would caution you to NOT take what I say as the ultimate truth, but to evaluate it yourself, and use what I say as clues into any problems you might encounter.  I had troubles when I first started using PPLs a couple of years ago, but I ironed those out and it's been a rock-solid building system since then.

Once I figure out the rules, it's be great, I hope.