LabVIEW Developers Feature Brainstorming

[Lycangeek]

As you may know, LabVIEW currently supports two primary techniques for being called by other languages. The first is to build your VI's into shared libraries (DLLs, etc) with a C interface. The second, available on Windows, is the ActiveX server interface. This allows you to load a VI into LabVIEW, read and write control/indicator values and run the VI.

The first technique has the advantage of being fast - in process with a custom calling API, but a disadvantage of restricting the data types you can expose and requiring a complete build step.

The second technique lets you access many of the LV data types, and to access any VI on the machine. However, it can be confusing on how to access complex types (arrays of clusters for example) and it requires a full copy of LabVIEW on the machine. Related to this, it also calls the VI out of process, meaning your application calls across to LabVIEW.exe. Not the fastest way to make a function call.

I'm very interested in either improving the ability to call the VIs or coming up with new techniques. Rather than start with my ideas, I'd like to hear from you about

• What you currently use and why?
• What languages do you call from?
• What you can't use or doesn't work for you?
• How you'd like to call VIs? What are the constraints you could live with?

[Lavezza]

I guess this is sort of related.

We have a LabVIEW program that has grown from a testing system into a control system. As a control system our program competes in an industry that has some developing standards. Under the standard, the different pieces of a control system are supposed to communicate via CORBA.

Maybe this is better viewed as a communication protocol issue. Still, there are standards for process communication that LabVIEW doesn't have native support for (CORBA, SOAP, JAVABEANS, JAVA RMI). I think inter-process communication is just as important as lower-level dll calls.

Pat

[Lycangeek]

Yes, the communication issue can be broken into two parts

1. Ability to access LV remotely and execute commands (load a VI, run a VI, get data to/from a VI).

2. Ability to use various network protocols for communicating between your VI and another process.

The problem with #2 is that many of the communication standards you mention make assumptions about implementations on the client and server. For example, RMI pretty much assumes you have a object remoting system - and basically that the system is Java. IBM did provide support for an IIOP protocol under the Java remoting (which replaces RMI) so that Java and CORBA could talk, but again it is object remoting.

It would be possible to allow you to be a client to such an object, similar to how our .NET and ActiveX nodes allow you to access remote .NET or COM objects. The inverse would require LabVIEW to expose a reference-based class model, which is much tricker - but very interesting.

----------

So, I'm assuming you are talking about #2. If not, please correct me. If so, if we allowed LV to be both client and server for Web Services be sufficient? I ask because WS do seem to be the network standard most people are moving towards.

[Lavezza]

So, I'm assuming you are talking about #2. If not, please correct me. If so, if we allowed LV to be both client and server for Web Services be sufficient? I ask because WS do seem to be the network standard most people are moving towards.

Yes, #2 is a bigger concern for us. Even if we are talking about two processes running on the same machine #2 allows us to easily distribute these processes if required in the future. Basically, #2 can do #1 slowly, but speed isn't the driving factor for us.

I guess our problem is that the standard for our software is CORBA. This isn't much of a surprise since the OMG (creators of CORBA) is also the body that created our industry standard. The only thing that is really saving us right not is that the standard is fairly new and hardly anyone is supporting it yet.

One of our other programs is doing a bunch of stuff with SOAP and XML in C# and then passing data to LabVIEW. Having better support for those things in LabVIEW would be a help.

Pat

[Ale914]

I realize a gateway from java and labview using UDP and it work fine but it was hard to write...
i suggest to implement the possibility to access to labview by DLL COM in this way i could create a Labview DLL with GUI

Bye,
Alessandro.

[batesbc]

ActiveX isn't restricted to just LabVIEW.exe, if you build an exe with the ActiveX server enabled, you can talk to that .exe just like LabVIEW.exe via ActiveX.

The goal for my LabVIEW <-> .Net interface code is to have Foo.vi be accessible through a MyProduct.Interop.Foo class in .Net, with properties for each control that call the vi.GetControlValue and vi.SetControlValue ActiveX functions. I'll do some speed tests on it once it's to that state.

[batesbc]

This isn't quite traditional interop stuff, but it would be very nice to be able to generate VI's from .Net. (or Python, or some text-based language) I would imagine this would take the form of being able to convert VI's to/from XML. Code generators are very handy for cases where you have a repetitive job to do, but it's not really something that can be made to fit generic code, or you want the speed of non-generic code. Imagine being able to take calculation code written in C# and generating a VI from it. Or vice versa, take a VI and generate C# / python code.

[Tomi_Maila]

LabVIEW is #1 language in instrumentation but it far from being #1 language in enterprise applications where JVM and .NET framework based languages dominate. If NI wants to see instrumentation to be better integrated into other enterprise systems, there must be a way to efficiently integrate LabVIEW with 1) JVM bytecode ran on top of any Java virtual machine and 2) CLR (.NET) bytecode ran on top of Microsoft CLR virtual machine. As JVM and .NET based applications normaly form the core of enterprise applications, the most important integration direction is such that JVM and CLR bytecode can call LabVIEW classes. This would require LabVIEW to support by-reference classes and some sort of NI written glue in-between different runtime environments. One glue implementation alternative would be to allow LV application to compile into JVM and CLR bytecode - this may be somewhat tricky as LabVIEW is not based on the same concepts as Java and .NET but I think it would be managable. Perhaps easier is to compile a kind of proxy in JVM/CLR bytecode for each exposed LV class that glues LV runtime code to JVM/CLR runtime code.

I see this issue very important and I cannot emphasis how important it will be for instrumentation to be integratable into enterprise application environment.

[Tomi_Maila]

I'd really like to see something like JNBridge http://www.jnbridge.com/ to be added to LabVIEW Pro. JNBridge allows .NET framework to communicate with Java framework. Similar solution should exists between LV/Java/.NET. Perhaps NI can license the JNBridge technology...

[Lockheed Autom…]

Hi,

We have developed a turn key LabView Adapter for CORBA.  We can provide a CORBA Client, Server, and/or DDS interface to LabView under Windows, Linux, and RT.  If you need to tie a CORBA interface to LabView, we have the mechnism, and is tested and maintained with the current CORBA releases.  We have 15 CORBA servers running on one PXI chassis processor and clients on other chasissis.  We are testing our port to cRIO as well.

Contact me at 410.924.1172 if interested.

Darren