Explain THIS - I dare you !

[tyk007]

Probably unrelated - but Windows will, of course, only load one named win32 dll per process. This can cause problems if your have multiple PPLS being built, all of which rely on the same named dll as a dependency (even if the dll version / file content is different) and then you try and use them.

My advice is to always prefix the dependencies in the build spec (eg. daq_lvanalys.dll, someother_lvanalys.dll) so that windows will allow multiple copies of the effectively the same native code to be loaded into the process. This also helps if you are using dependencies with different versions (the signal processing dependencies are a common complaint in this area). Yes it chews up more memory but saves you a whole lot of dependency problems.

[CoastalMaineBird]

FINALLY , a clue !

A simple test shows it's either a LabVIEW bug, or maybe I'm attempting something that can't be done.

There is a PPL called "MoSAIC Addon Tools.lvlibp"

The source for that is "MoSAIC Addon Tools.lvlib"

Inside that LVLIB are:

an Enum called "Addon Connection OpCode".

A cluster called "Addon Connection Message" (which includes an OpCode).

A VI which creates a QUEUE of type "Addon Connection Message", and an EVENT of type "Addon Connection Message".

I build that into a PPL.

In ANOTHER PROJECT, if I go to use that QUEUE, I can connect to it just fine.

But if I then CREATE CONSTANT from the DATA IN, I get the original TYPEDEF (from the LVLIB), NOT the one from the PPL !

So it's undefined!  Because the LVLIB is not accessible.

I can use the event just fine, but if I try to create a CONSTANT from the OpCode it produces, I get a constant without a typedef, because it's the inaccessible version.

I can use the queue just fine, but creating a constant means a broken constant.

I'll bet this has something to do with my once OK, twice broken issue.

Notice how the help for the constant I created refers to a typedef in the LVLIB, NOT in the LVLIBP.

[CoastalMaineBird]

My advice is to always prefix the dependencies in the build spec (eg. daq_lvanalys.dll, someother_lvanalys.dll) 

But that's not under my control.  I don't directly use LVANLYS.dll.  I use things that use it, and they are in something like AALPro.lvlib - some library within LabVIEW.

I chase those things sometimes, and the CALL LIBRARY node that calls the DLL has been reconfgiured to point to the middle of MY directory structure.

I didn't go change it to point to me, but it did get changed?

Oddly enough, if I MASS COMPILE, I get a message where it changed from the expected path  (somewhere in my folders) back to the original (somewhere in LV2013\vi.lb.

So, the compile process is happy to change these paths, it KNOWS where it's supposed to be, but insists on copying the thing and pointing all over the place.

I have over 30 copies on my hard drive.

[tyk007]

---

@CoastalMaineBird wrote:

My advice is to always prefix the dependencies in the build spec (eg. daq_lvanalys.dll, someother_lvanalys.dll) 

But that's not under my control.  I don't directly use LVANLYS.dll.  I use things that use it, and they are in something like AALPro.lvlib - some library within LabVIEW.

---

Yes, but you can still prefix the dependency in the build specification and then when AALPro.lvlib components (some or all depending on your build specification configuration) is compiled into your PPL you will get the relevant copy and references updated to point to the renamed dll. But yes, you will get multiple copies. 

---

@CoastalMaineBird wrote:

So, the compile process is happy to change these paths, it KNOWS where it's supposed to be, but insists on copying the thing and pointing all over the place.

I have over 30 copies on my hard drive.

---

Welcome to the world of dependency management! Until LabVIEW is capable of understanding linkages between project "builds" (aka solution) and is capable of treating dependencies in the form of components then this is always going to be a pain. But even then, dependency hell is still a problem even in other more "popular" development environments, especially when it isn't a dependency that you created but have to use indirectly.

[tyk007]

More advice from me (2 cents) - prefer to use PPLs as a deployment tool, not a component management tool. Despite NI's claims I have never found them to be the best solution for managing components due to their dependence management handling and odd behaviour in those situations. They are great for final built deployment but without a form of "component dependency" (aka solution again) support in the IDE for developm,ent I have had nothing but trouble.

If I need a stand-alone component then I create a VI package for it (renaming the files and dependencies in the build process to avoid conflicts down the line).

Good luck. Once you're in it's hard to get out.

[CoastalMaineBird · Accepted solution]

For what it's worth, I solved this problem, although LabVIEW was no help in tracking it down.

I finally used intuition to figure it out.

The REAL issue, was that something ELSE in the ADDON TOOLS PPL was not executable on RT.  I suspect it was a VI which used a File Dialog.

I don't know why none of the other instances showed this problem, though.  I don't think the other things were actually CALLED from RT code, but their EXISTENCE seems to be a problem.

When I split it into TWO PPLs, one for the RT-SAFE tools, and one for the rest, ALL the problems went away. No LV Crashing, no mystery complaints about LVANLYS.dll, no mystery breakage of VIs in the PPL, nothing.

It was just that the errors I got ("This VI is broken because it can't find an external routine") didn't really point to the REAL problem - that's what made it so hard.

Anyway, thanks for listening.