ActiveX / COM control to LabVIEW application

[MrQuestion]

I have developed an application with LabVIEW. I would like to expand this application with an API so that external software can interact and control my application.

I have searched extensively and found solutions such as an Ethernet command interface, DataSocket binding, psp variables, extra. All of these solutions are not exactly what I’m looking for.

I have a wide range of customers and they are accustomed to making DLL and ActiveX/COM calls.

My customers could use any selection of languages and scripts such as c#, python, vbscript.

I would like to create to expand my LabVIEW application to have an accessible COM object. Is it possible to expose COM components in LabVIEW?

I want my users to use a command such as this: (vbscript example)

SET objLabVIEW = CreateObject(“LabVIEW.Application”)

SET objMyApplication = objLabVIEW.Applications.Open(“c:\someDIR\myLabVIEWApplication.exe”)

Is this possible?

I’ve seen some examples in the neighborhood of this using VI Server. Unfortunately I haven’t seen a design pattern or clear examples of how such an interface would work.

I dont' mind creating a seperate dll, for the COM object. 

Almost everything I found on this topic is for the other direction; as in LabVIEW controlling COM objects. I want my LabVIEW application to be controlled by an external program prefferable via a COM interface or DLL.

The DLL could act as a wrapper to VI Server calls. But, once again I haven't seen any clear examples or design patterns to do this.

Regards,

[pangvady]

In the Build Specifications of your LV project, you can build DLLs (shared libraries) or even .NET interop assemblies that can be called by text-based code. For DLLs, you can specify what VIs to export to your DLL interface. More info here:

Using Build Specifications

How Do I Create a DLL from a LabVIEW Project?

[MrQuestion]

Thank you for your response.

Just to clarify I already have an application *.exe defined in the build specification.

I want to run this application with the GUI and have it controlled via an API externally.

For example I have several functional globals in my exe that I would like to expose to the world. 

Creating a DLL build specification would not grant access to the functional globals in my exe, because the DLL would be a separate instance of all data.

For example you might have Excel open and you want to manipulate the data in your application. You can run an external script that would manipulate the data in your Excel document while you have it open.

I'm looking for this same type of behaviour from my LabVIEW application.

[Alexander_Sobolev]

My solution was to modify application to expose data by LabVIEW means (shared variables, reply to tcp/ip or udp calls, etc) and then build a DLL (.net assembly, etc) that will translate user-accessible functions to application commands.

Functional globals are usually packed into application file and not available from another application.

[MrQuestion]

**UPDATE**

I did come accross this example:

LabVIEW-Executable-Used-as-ActiveX-Server

It looks promising.

I can asycrinously access the LV front panel server element from the other VI.

But the client VI uses an LVActiveX _Application function to get a reference to the VI, and then uses a standard VI server function to pull the front panel value.

I'm not sure if I can do this from other languages. 

I would be happy with any type of example in a different language for the client. ANSII c, python, VBScript, c#, anything,,,,

If somebody could show me how to do what they did on LabVIEW-Executable-Used-as-ActiveX-Server but instead use an external language for the client; I could take over the world.

I will be addinging to that post as well. (it's old, but right now i feel like i'm fishing)

Thank you,

[rolfk]

Actually, the VI that is shown in the first post of the other thread should be easily implementable in any other language that provides a proper ActiveX interface.

Depending on your application language you may have to write an include file or equivalent that defines the LabVIEW methods for the two exposed classes LabVIEW.Application and LabVIEW.VirtualInstrument.

Until LabVIEW 2012, there was an example as pointed out on this page that did provide a VB 5 example how to connect to LabVIEW and access the VI server interface from a VB 5 app.

In VB5 code this looks something like this:

'Declare the object type of a lvApp and VI
Dim lvApp As LabVIEW.Application
Dim VI As LabVIEW.VirtualInstrument
Dim VIPath As String

'Create a reference to LabVIEW
Set lvApp = CreateObject("LabVIEW.Application")

'Determine the path to the VI
VIPath = lvApp.ApplicationDirectory + "\Examples\General\Strings.llb\Parse Arithmetic Expression.vi"

'Assign an object reference to VI
Set VI = lvApp.GetVIReference(VIPath)

As you can see the CreateObject("LabVIEW.Application")  corresponds to the Automation Open call in that other thread and the lvApp.GetVIReference(VIPath) corresponds to the GetVIReference() method call in there.

VB could directly see the class datatypes LabVIEW.Application and LabVIEW.VirtualInstrument from pointing it at the LabVIEW provided ActiveX type library <LabVIEW>\resource\labview.tlb. I'm not sure if for instance Python could make use of such a type library or if you rather have to define that interface yourself using something similar to "ctypes", which is used when interfacing to functional DLLs. A quick check would indicate that you probably need to use pywin32 or whatever is the current incarnation of that package and then define the interface to your ActiveX server (here your LabVIEW application) using that package.

First you will need to create the bindings for all the ActiveX methods and properties that you need from the LabVIEW ActiveX VI server interface and then maybe write specific wrappers around your specific VIs in your application, that you want your users to be able to access. 

The example has been removed since ActiveX is nowadays considered a legacy interface and also because VB5 hardly can be expected to be installed on any users computer nowadays. And newer VB versions have changed various things, so the example isn't directly usable in a modern VB installation without modifications. But the Type Library is still present in the <LabVIEW>/resource directory and if your environment supports parsing tlb files, you could get everything working very quickly. Otherwise you have to define the bindings somehow like by using pywin32 or whatever is the equivalent functionality for the other languages you want to provide an interface to.

If you create a LabVIEW application and enable the ActiveX server setting in the build options, you would use the specified name in there in your CreateObject() call instead of "LabVIEW.Application". And of course for the ActiveX registration to happen you do need to run the Installer that you build from the LabVIEW Build Specifications.

[MrQuestion]

Thank you so much for the detailed explanation. I will test this out soon.

You mentioned that ActiveX is considered a legacy interface. I've read this before on other support sites.

What is the suggested (more modern) way of creating an API?

[rolfk]

Well, Micorosft would love to push everyone in using exclusively .Net. Aside that this currently still smells a lot like a platform lockin to make sure that software only can run on Windows it also is a pretty heavy resource hog for simpler forms of inter application communication. Also ActiveX does have various limitiations in respect to modern multitasking/multithreading operations.

.Net together with the Windows RT system promises that the software can run on any modern Windows RT compatible system, independent of the underlaying hardware platform. Problem is that LabVIEW is not a Windows RT application, and likely never will be due to its own built in compiler that directly goes to the bare metal. I'm not sure how feasable it is to try to have the llvm compiler that LabVIEW uses, target the Windows RT virtual  machine. While there exists a http://compiler-rt.llvm.org/ project that could allow this, I'm pretty sure that it is much more complicated than just to plugin this compiler backend into the LabVIEW llvm system.

[MrQuestion]

I have fell so far down the rabbit hole I forgot my original problem statement.

When developing my application I paid special attention to my data types and made sure that most data could easily match up to an equivalent ANSI c structure.

I did this because when I started development (years ago) I always expected that my customers would want such capability.

I'm only now researching IPC in LabVIEW.

Most of our customers use python, and they are comfortable with using Windows Named Pipes for larger data transfers.

But, you bring up an interesting point regarding real time targets. I would like to create a solution that would work with both real time targets and windows. 

There seems to be so many choices, but yet so few solutions. 

For people researching IPC on Windows this seems to be a good starting point.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365574(v=vs.85).aspx

[rolfk]

All the techniques described in the IPC article you quoted are in fact Windows only, so they fail the usability with real time targets, smartphone, tablets and wearables completely.

If you really don't want to get locked into one platform only, be it Windows (ActiveX, .Net, Windows named pipes, Microsoft RPC), Linux (pipes, mailslots), or MacOSX (with its own techniologies in addition to the BSD parts, which don't need to be compatible with Linux at all), then you should consider a network interface. If you write a TCP/IP interface in your LabVIEW application, then you can write any number of client libraries that fairly easily can connect with your system. And you don't even need to convert everything to strings. If you made sure to use basic types, flattening them to a string on the LabVIEW side and sending them off to the client and unflattening any received data is all that is needed.