LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW 2017 RT build not including referenced dll

Hi all,

I'm looking into something strange regarding the automatically inclusion of a dll into a RT build. It seems that although the dll is directly called by the Call Library node, and appears in dependencies in the project, when I make a build the "data" file LV creates to deploy to the RT PXI is just not there. 

I tried the same, very basic VI in 2015 and it works as I expected, with the files being there. 

Whats more, if the application is not in RT, but an Application (EXE), it works...

We can include them in the build, but since it will go out to many users I would really rather not have it be done like that;

Naturally the build specs are just normal, default ones, nothing out of the ordinary. And again, same exact example works in 2015 (RT)

 

I'm a bit at a loss here, can anyone pitch in? I couldn't seem to find anything on the forums but I did try in 3 different machines/projects for the same result...

Thanks!

Cris

 

 

 

Message 1 of 12
(3,124 Views)

Is that a custom DLL or an NI DLL? Because for some toolkits NI uses different DLLs on Pharlap ETS than on Windows and if you are using that functionality you are meant to install the actual driver from within NI Max for that library. It's quite possible that the Application Builder in newer versions of LabVIEW knows explicitly about some of those drivers and excludes them in the build on purpose!

Rolf Kalbermatter
My Blog
0 Kudos
Message 2 of 12
(3,082 Views)

@crandiba wrote:
when I make a build the "data" file LV creates to deploy to the RT PXI is just not there. 

 

Whats more, if the application is not in RT, but an Application (EXE), it works...

We can include them in the build, but since it will go out to many users I would really rather not have it be done like that;

 


I want to clarify a couple points here...

 

You've got a PXI system you're working with.  When you run in RT, you don't send the DLL.  When you run as an EXE (does this mean Windows?), you succeed.

 

You also mention being able to build successfully.  But, you don't want to do this because other people will use it. 

 

Can you clarify what you mean by all of this?  Are you talking about running interactive mode versus a startup executable?  Do you mean you dual-boot your PXI into RT and Windows and one of those two works?  As already asked, is this your DLL or a NI DLL? If NI, is it specific to a toolkit?

 

If you're designing this RT application for others and they'll need to deploy your startup executable to work, why does it matter if you include the DLL here?  This is a common design method.

 

 

0 Kudos
Message 3 of 12
(3,069 Views)

Hi Rolf,

Thanks for the insightful info, for sure it will come in handy. Im afraid that in this case its a custom dll...

 

Best

Cris

0 Kudos
Message 4 of 12
(3,067 Views)

Hi,

Sorry for the lack of clarity: its a custom DLL that, upon making the build for PXI RT, does not appear in the files generated to be deployed into the PXI unto the data folder. The dll is a custom one, not related to any NI or OS, nor is it being referenced inside another, it shows up clearly listed in dependencies. 

If I included it manually in the build logically it works, but I would rather this not be the case *since it will go out to others that would be required to do the same).

The DLL is automatically present in the RT build files on LV 15, just that this isnt the case for LV 17.

To add to my confusion, if I make a windows executable with just the call to the dll on 17, then the file is there...just not for RT. Hoping that helped, and thanks again!

Cris

 

 

0 Kudos
Message 5 of 12
(3,064 Views)

What sort of name did you give the DLL? Any blacklisting of DLLs by the application builder is likely purely name based so maybe you hit a name (pattern) that NI considers in use for one of its drivers.

Rolf Kalbermatter
My Blog
0 Kudos
Message 6 of 12
(3,060 Views)

I don't believe so..Its something quite specific like "libLogdatavle", for example. As it was working on 15 I was thinking it was introduced in LV 17. I see they did some work on the Call Library and application builder, but I find it hard to believe it just stops including the dlls in dependecies altogether..

 

0 Kudos
Message 7 of 12
(3,048 Views)

Well another thought might be that they changed the way how shared libraries are meant to be distributed. The Pharlap system was the only realtime system that did deploy shared libraries together with the compiled VIs to the target. On VxWorks and NI Linux Realtime systems you ALWAYS have to get any shared library that is used by your app onto the system in another way, either by copying manually to a correct directory or installing a package onto the system that contains the library.

Pharlap was different since it was the first system they used for realtime applications and it used pretty much the same executable format as the Windows development system, so the DLL that worked under Windows was fairly likely to just work on the Pharlap system too. But that was almost 20 years ago!

The Pharlap ETS system is still implementing a Win32 API from around Windows NT 4.0 times and Microsoft Visual C has gained the somewhat notorious habit of requiring a new C runtime binary for every new version. And this C runtime version can't just be installed on a Pharlap system since Microsoft likes to couple it very tightly to the Windows kernel by using all kinds of low level and undocumented APIs that will not work on an older Windows system and definitely not on a wannabe Windows system like Pharlap. So NI licensed the C runtime source code from Microsoft to port it to the Pharlap system but did so in only a few Visual Studio versions they were themselves using for development for the Pharlap RT system. Those supported versions are VS 6.0 (no seperate C runtime needed since Windows NT and Pharlap come with the necessary MSVCRT.DLL interface) , VS 2003, VS 2008, VS 2010.

Any DLL created with another Visual Studio version has almost no chance to run on Pharlap not to talk about other C compilers which are even less likely to create a DLL that can be properly loaded and executed on Pharlap.

So the days where a DLL build for Windows will likely work on Pharlap too are more or less gone for good. It's not impossible but it requires upfront to choose the right Visual Studio version and to refrain from using any Win32 API that Pharlap doesn't support, or create conditional code paths in your DLL that work around such missing APIs.

Many drivers from NI nowadays provide two different versions of the DLL for Windows and Pharlap. (Well really 3, 32 bit and 64 bit for Windows and 32 bit for Pharlap) and to get the DLL onto the Pharlap system you have to go into NI-Max and install the according package to it.

And yes NI Pharlap ETS is already in legacy mode so expecting NI to add support for newer Visual Studio versions is very blue eyed.

Rolf Kalbermatter
My Blog
0 Kudos
Message 8 of 12
(3,043 Views)

And there might be even a simpler reason. Check your build settings!

Under Additional Exclusions there is a checkbox called "Exclude dependent shared libraries". If that is checked LabVIEW certainly will not copy shared libraries.

Rolf Kalbermatter
My Blog
0 Kudos
Message 9 of 12
(3,033 Views)

Rolf, can't thank you enough for the comprehensive answer; that background info is really valuable and I'm sure others will find it useful as well.

I want to agree with you and suspect that NI just changed the way things are meant to be, and having you manually deploy it. It makes sense in light of what you said, even if I don't agree with it.

The additional exclusions was a good tip as well, but I do have it 'unchecked'. 

Right now I'm hoping to hear back from some NI officials on this and hopefully clarify the issue. Even though I tried on 3 different machines, I was wondering if anyone else experiences this with 2017.

 

0 Kudos
Message 10 of 12
(3,021 Views)