Linux Users

cancel
Showing results for 
Search instead for 
Did you mean: 

How to use .NET to access methods on a Linux machine from a Windows machine?

I'm trying to use LabVIEW on a Windows machine to communicate to a Linux machine.  The goal is to use .NET to access a specific library on the Linux machine so I can call certain methods and return the results to the Windows machine.  I will need to access the Linux machine from the Windows machine using a specific IP address and port.  If the dll is located on the Windows machine, I can easily call the required method(s) using .NET, but I'm not sure how to do this with the dll on the Linux machine.  Any suggestions?

0 Kudos
Message 1 of 7
(4,879 Views)

What language is running the DLL on the Linux box? Are you using LabVIEW? If so, then you could use VI Server to talk between the two instances of LabVIEW (Windows and Linux) and send and pass information directly. You could even run the VI on the Linux machine calling the Linux DLL directly from the Windows machine using VI Server. If you are using a different language to call the Linux DLL on the Linux machine, then let us know and we might be able to point you in the right direction.

It is also possible that I don't totally understand your question. You might also try restating exactly what you want to do from the Linux side.

0 Kudos
Message 2 of 7
(3,805 Views)

I'll try to give more details.  The Linux machine is running an XMLRPC server.  I will need to call methods from this dll.  I have LabVIEW on the Windows machine, but not on the Linux machine.  Currently we are using Python in LabVIEW on the Windows machine to make the calls we need, but I was wondering if there's a better way to make the calls.  Perhaps .NET?  It would be nice to get rid of one layer (Python) but I'm not sure that is possible. 

0 Kudos
Message 3 of 7
(3,805 Views)

You need something running on the Linux machine that can receive commands from Windows, run the appropriate functions in the .so on Linux, and then return the results back to Windows. You can use any technology you want for that as long as it supports loading and calling your shared library and communicating with Windows (probably via TCP/IP). As Randy mentioned, LabVIEW works pretty well for this. If you get a copy of LabVIEW for Linux then you can just wrap the DLL in some LabVIEW VIs and call them remotely with VI Server. This is a built in feature of LabVIEW that is basically Remote Procedure Calls (RPC). The tough part of writing a system like that is all of the network communication. Writing your own protocol and handling all of the connection/tear down issues is not easy. Using LabVIEW for that part may save you a ton of time.

0 Kudos
Message 4 of 7
(3,805 Views)

Are you just looking for a XML-RPC implementation? It looks like you already have the service running.

For CLI implementation: http://www.xml-rpc.net/

0 Kudos
Message 5 of 7
(3,805 Views)

Okay, I do have an XML-RPC server running on the Linux machine. It looks like I will need a LabVIEW client application for communication to/from the XML-RPC server.

0 Kudos
Message 6 of 7
(3,805 Views)

Not necessarily. I didn't notice in the original question that you had an RPC server running already. I don't know exactly how XML-RPC works, but I think you just need to hook up some client that is capable of loading your shared library and calling the correct function in response to an RPC call. Then you need the proper glue code on the Windows side to send the right XML string to the server. You could get away with doing that without LabVIEW.

My point before was that instead of using XML-RPC it may be easier to just create some wrapper VIs for your shared library and use LabVIEW's VI server to do the RPC. That completely replaces the need for the XML RPC (on both ends). The result will be a much more native LabVIEW experience with all of the protocol issues being handled internally by LabVIEW.

Basically it works by just opening an application reference using the address of the Linux machine (with LabVIEW already running on that machine with a configured VI server with TCP enabled; see Tools->Options), then open a VI reference to a remote VI using that app reference, and then call the VI with the Call By Reference node.

For more detailed information look in the LabVIEW help in the "Programmatically Controlling VIs" topic (under Fundamentals). There's also a category of the same name under Example Finder (Help->Find Examples).

0 Kudos
Message 7 of 7
(3,805 Views)