Problem Moving PPLs to LV2017

[tyk007]

I doubt that using an I64 is the issue. The native instructions generated by LabVIEW at runtime using the 32-bit source would simply require multiple machine instructions to move the data. You could try running the VI itself on RT (not in a PPL) and see if it works; I'd be highly surprised if it doesn't.

[CoastalMaineBird]

Yeah, I'm just guessing.

Here's another fact, though.

I have compiled all the way through the main (MY COMPUTER) host and the main RT program - everything compiles.

Now I have a problem with the RT side of one of the addons, which has both a host part and an RT part.

One of the PPLs that i MOVED from RT to MY COMPUTER now shows a problem on the RT side.  Same deal - it complains that "This VI has a bad connection to an external dependency", which is not accurate.

I HAVE noticed that ALL of the ones where this complaint still occurs are REENTRANT.  Dunno if that's a clue or a red herring.

[CoastalMaineBird]

Without changing anything else, if I go to that PPL where it showed me two (REENTRANT) Vis that had problems, and change a third one to being REENTRANT, and rebuild, the problem shows up with THREE VIs that have the same fake "Missing dependency" problem,  

LabVIEW bug ?

[CoastalMaineBird]

OK, I believe this to be a LV 2017 bug.

Attached is a PROJECT to produce two PPLs and a project to use them.

The SOURCE project, has five simple VIs in a LVLIB on the host, identical except for #3 is REENTRANT.

It also has five identical VIs in another LVLIB on the RT side, identical except for #3 is REENTRANT.

The SOURCE project builds PPLs out of each and puts them in the PPLs folder.

That's already done, so you don't have to.

The USER project has a VI on the host which uses two VIs from the HOST side and two from the RT side.

Notice that ONE out of the four is broken: the REENTRANT one from the OTHER side of the fence.

The USER project also has a VI on the RT side, which uses two VIs from the HOST side and two from the RT side.

Note that here, the broken one is the REENTRANT one on the OTHER side of the fence.

[Ben]

HI Steve,

Thank you for sharing in public. I can not help since I have stayed away from PPLs due to the issues I have read about.

The PPL's aside I have seen situations where things like the general error handler is unique between Windows and RT. If I share a VI that uses same on both Windows and RT one or the otrher has a "dirty dot" indicating it needs to be saved.

In your case the differences in the file systems may be part of the issue.

Not that it helps you but that is all I can offer.

Ben

[CoastalMaineBird]

In your case the differences in the file systems may be part of the issue.

No - later on it boils down to this:

If a VI is REENTRANT, and it's in a PPL...

-- It is broken if loaded on the OTHER side of the host | RT fence from where it was compiled.

My example project above has a simple ADD vi and it shows the same problems.

I've reported to tech support.

[Ben]

If you get a CAR# number could you please share it?

The Champions can request updates on selected CAR#s and this is one that I would like to learn more about. Not that I would be able to share in public what they tell me but when it comes time for you to become a LV Champion you will be able to check for yourself.

Thank you,

Ben

[CoastalMaineBird]

Tech Support has acknowledged the issue and kicked it up the chain.

No CAR# yet.

[CoastalMaineBird]

OK, 2nd tier Tech Support has gotten back to me with this:

Hi Steve,  
I agree, the document wording is confusing. There are also changes made between the LabVIEW 2013 and 2017 help documents: 
 
LabVIEW 2013: 
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.
 
LabVIEW 2017: 
If a VI calls a packed project library compiled for one target and you open the VI on another target that has a different operating system, the packed project library fails to load.
 
From the 2017 documentation, I have taken that:
1. VIs that call Windows PPLs can only be opened on HOST.
2. VIs that call RT PPLs can only be opened on RT.  
 

Given that they've changed the documentation out from under me, it's not likely they will say "Gee, that's a cool feature - we'll fix it for you."

The bottom line is, I've been doing it wrong for 3+ years. In LV2013, it works fine for a HOST program to call a PPL compiled for RT.  In LV2017, it doesn't.
I'm going to have to rework all my (~50) build specs to make TWO copies of the RT-PPLs, and put them into separate folders.

It's already the case that all the RT code uses only RT PPLs, including the PPLs inter-dependencies.

I need to make that true for the host side, as well.

Thanks to everyone who contributed to this. 

[CoastalMaineBird]

My first test shows that this will possibly work.

Each dual use PPL should be compiled TWICE; once for Windows and once for RT.

It struck me as problematic that the code in Windows PPL B that calls to a VI in PPL A would have to be linked to the WINDOWS version of PPL A and would then fail if something called the RT version of PPL B, since buried in the code is a link to the Windows version of PPL A.

But, that doesn't happen if:

1... The PPLs are named IDENTICALLY (i had named one with an "-RT" name to distinguish them).

2... Because of #1, they MUST be in different folders.

i guess (GUESS) that PPL B searches FIRST in the folder it's in for the right PPL NAME and the right VI.  If it finds it, it runs.