Native call

[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