Native call

[jhersh]

Originally Posted by byteit101

nope, still

i'm using the default 2010 project.
I've also copied ZomB.out to
/ZomB.out
/ni-rt/ZomB.out
/ni-rt/startup/ZomB.out
/ni-rt/system/ZomB.out <- Loaded on startup dll's

You should only put it in /ni-rt/system/

In the call library node, you should only specify the name.*, not the path.

If you have it in the start-up DLLs, then you should see it loading in net console on boot. If that is succeeding, then the VI should not be loading it again. If it fails to load on startup, then you have a problem with your library.

-Joe

[byteit101]

Oh, silly me! I had an earlier version of ZomB in /ni-rt/system, and assumed that labview would be using the newer one in /ni-rt/startup since it deployed there!
Now that I have it working, is there anyway to generate a lvlib that can be automatically included in projects?

[Greg McKaskle]

You've already gotten it to work, but for anyone else doing this level of integration, LV loads the library from the path entered -- made a bit more complicated for RT targets. For that reason, most of the time, you only enter in the library name and let the OS and/or LV insert the appropriate paths. This is controlled by LibPath or a similar mechanism and includes the LV search path. Also note that some OSes may only allow one DLL with the same name to be loaded, even if from different paths or different versions.

An lvlib provides a namespace, an ability to determine what is private and public, and that is about it. If you build VIs to wrap your DLL, you can ship them in a folder and if you like, you can include an lvlib file descriptor too. You can also include a dir.mnu file.

As for where to place it, you have a number of choices. Possibly the best place to tell users to install it is into the vi.lib/addons directory. Another location is the user.lib directory. Either of these can easily integrate into the palettes and if used by the user, the VIs will be downloaded to the cRIO. I believe the users will need to install the lib on the cRIO as part of the build spec or via ftp (not sure about this one).

Greg McKaskle