Jump to content

Recommended Posts

Hi everybody,


I am wondering whether or not it is possible to call the functions of a dynamic library over a LAN connection, without needing to control a VI on the server using the LV remote server (my server is Win7 embedded on an SSD, so not much resources to waste running the RTE). Does the "Shared library file is not on the local machine" checkbox allow that when using the Import Shared Library wizard? Is there any easier solution than implementing a protocol over a TCP connection to access my DLL's functions?


Thanks in advance,


Sylvain F.

Link to comment

The "shared library file is not on the local machine" option allows you to import a shared library using only the header, without access to the DLL. This has nothing to do with remote access to the DLL, it just tells the import wizard to rely on the header file and not look for the DLL.


There is no way to call a function inside a DLL remotely. A DLL isn't even loaded into memory until an application needs it. You'll need to write an application - it doesn't need to be in LabVIEW, and you don't need VI server although it is an option - that accepts network connections, parses the received data, calls the correct function in the DLL with the appropriate parameters, and returns the result (if needed) over the network. That could be a lot of work. Why are you trying to do this?

Link to comment



Thanks for your answer.


I am doing this for the production team. They develop their testbenches with TestStand and LabVIEW and need to access internal functions of the product when the enclosure is closed and can only do so through an ethernet link. We have a dll onboard which provides the functions needed, but we have to give them access over the link. From what I understand from this, it is possible to call a VI remotely if the run-time engine is installed and the VI's executable is running on the server, am I right? In this case the VI calling the DLL functions could be located on the server and called remotely from TestStand.


Is there an "embedded" version of the RTE or an older and smaller version that could be used with recent versions of LabVIEW? Also, can we prevent the RTE from loading at Windows bootup so it doesn't consume resources when we don't need it?


Thank again!

Link to comment

Yes, you can use VI Server to get call a DLL running on a remote target. In a Windows environment, you need to have a LabVIEW application (either the development environment or a compiled application) running in order to have VI Server available. You also need to enable VI Server allow access to the VIs you need (you can set this in Options, or in the INI file). The Run-Time Engine loads when a LabVIEW-compiled application starts, NOT at system startup (except in a LabVIEW Real-Time environment, not your situation). However, if you don't have your LabVIEW application run at startup, then you'll need some way to start it remotely in order to get access to VI Server when you need it.


The "web" version of the run-time engine is fairly small (under 30mb download) and might provide everything you need - many of my applications run just fine with it. You can find the version that matches your development environment by searching the NI site for "web run-time" and finding the right one. If you're using a version of LabVIEW older than 2012, look for the "Minimum Run-Time" instead.

Link to comment

Thank you. I am trying to do what you proposed, but I am having trouble to call a VI remotely using the IP adress of the server. It works fine with a PC which is on the same network using its specific name, and by specifying the absolute path to the VI on the server as the VI Path, but when I specify an IP adress and a local VI Path, I have an error saying that the server refused the connection. I configured the .ini file of the .exe to enable everything concerning the VI Server, allowed access to everyone, etc. It seems that there must be some kind of sharing enabled between the client and the server for this to work... Or am I not doing this the right way?



FYI, I use TestStand 2013 and LabVIEW 2013 on the client and the 2013 RTE on the server.


Edited by 20Syl
Link to comment

When you say "local path" - local to which machine? You can only run a VI on the machine on which that VI is located. When you open a connection to remote machine, you can then load a VI that's on the remote disk, not your local disk. When you run that VI, it runs on the remote computer. VI Server doesn't transfer VIs over the network; it only sets up the inputs, starts execution, and retrieves the outputs.


Try including the VI in the compiled application. A static VI reference is a good way to do this. It will cause the VI to load in memory along with the application. You can then refer to that VI by name, rather than through a path. Wire a string (NOT a path) containing the VI name in place of the path to the VI.


If you have a firewall on the server side, it will block connections to VI Server unless you specifically allow them.


It might help to upload your application's INI file, along with your code.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.