LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Integration of LabVIEW and .NET in Linux

We are going to integrate LabView and .NET in both Windows and Linux. That's to say, we are going to invoke .NET classes in LabVIEW, and also invoke LabVIEW in C# and VB .NET code. It seems that it already has such support in Windows. My question is: Is it supported to integrate LabVIEW and .NET in Linux? Any suggestions and comments will be sincerely  appreciated. It will also be appreciated if anyone provides related documents. Thanks.

0 Kudos
Message 1 of 6
(2,993 Views)

The real question here is: is .NET supported in Linux. Without that, there's no point in considering LabVIEW. The answer? It is, sort of. Mono is the project that tries to bring .NET to Linux. Will it work with LabVIEW trying to call .NET assemblies? Don't know. But I wouldn't bet on it if it's a critical project.

Message 2 of 6
(2,984 Views)

Thanks for your quick response.

 

Yes, we are using mono in Linux for .NET. The question is whether we can integrate LabVIEW and mono. Currently we are investigate whether we could invoke LabVIEW via mono or vice versa. It's critical information for us to make decisions. Therefore, we will sincerely appreciate if anyone can provide us some official related documents.

 

For your question: Will it work with LabVIEW trying to call .NET assemblies? According to the information at http://zone.ni.com/devzone/cda/tut/p/id/4888, we can do so since it's mentioned: With the release of LabVIEW 7 Express, you easily can connect to this new .NET technology as a .NET client. You can create instances of .NET classes and invoke methods to set and obtain properties on them. The usage paradigm is similar in LabVIEW 7 Express to that of ActiveX automation VIs.

 

 

0 Kudos
Message 3 of 6
(2,974 Views)

If you are trying to use Visual Studio built binaries the answer is that it likely won't work. If you want to replicate the code in Visaul Studio on Linux it sort of depends... The Mono stuff is a subset of the CLR. There are missing bits that are netive to windows but not to Linux or X. There are native replacements for some functions but the coe has to be extrmely simple and carefully written to work in both environments. It still ends up being a "port" effort to get simple things to work and many times just isn't worth the extra effort.

 

I like Linux for lots of things but I've learned that the only really dependable common function to both environments is browser support (by installing Firefox on WIndows and Linux machines) and TCP/IP networking using C or C++. Doing similar work with LabVIEW seems to work using the TCP wrappers also for at least LabVIEW 8.0. There are no Linux FieldPoint drivers and the only work-around is to install a real-time application on the chassis to get it to work.

Message 4 of 6
(2,972 Views)

Thanks for your reply.

 

I don't have much knowledge on "TCP wrappers" in your comments: Doing similar work with LabVIEW seems to work using the TCP wrappers also for at least LabVIEW 8.0. I'll do some research on this topic. If I still have questions after research, I'll resort to you again:)

 

I get the following information from your profile: Linux may one day get a LabVIEW environment that is supported as well as Windows but not for a while...  Is fully support for .NET (mono) one of the limitations of LabVIEW in Linux? I'm also curious about the other known limitations.

0 Kudos
Message 5 of 6
(2,961 Views)

The difficulty lies in the components available using C# and the CLR vs. Mono. The Comon Language Runtime (CLR) is the underlying virtual machine for Windows .NET applications and it's integration with Visual Studio is not trivial. Then there is the fact that the components of both systems make different assumptions about the OS because they are, in fact, quite different. Even simple things like text manipulation act differently. While many of the base components are identical to shallow inspection or trivial use, more specialized components and those originated by outside vendors for use as drivers to use specific hardware or to connect to proprietary software simply become unavailable way too often without twice as much work as you originally thought when planning a project. This makes use only on Windows the rule of thumb rather than a hard and fast rule. Technically one could overcome all of these things but the question often becomes "How much is your time worth?"

Message 6 of 6
(2,949 Views)