How to add a simple API to my C++ application for access by LabView?

Question

I have a data acquisition program written in C++ (Visual Studio 6.0). Some clients would like to control the software from their own custom software or LabView. I would like to come up with a simple API with a dll I can distribute to them and would like some tips on how to get started. This is going to be VERY basic, maybe 4 or 5 commands. My DAQ program will still be running in its own window on the same machine, I would just like to set it up to be controlled from another program.

Answer 1

You are on the right track with a DLL. The real trick, it sounds like, will be deciding what sort of inter-process communication (IPC) you want to use. Options are: sockets, pipes, shared memory, synchronization objects (events, etc.), files, registry, etc.

Once you decide that, then implement a listener within your executable to wait for incoming IPC messages from whatever software is using your DLL.

As far as the API is concerned, you can keep it simple just like you were wanting. Have the DLL expose your 4 or 5 functions (make sure you only use native data types, like char* and long, to avoid module boundary issues), and then those will use your IPC mechanism to communicate with your executing app.

Answer 2

Things that start simple like this have a habit of growing over time, so you may be better off doing a little more work up front and using a technique that will grow with you.

Implementing a COM interface to your program would give the clients are lot of freedom in how the interface with it, and you wouldn't have to worry about the mechanics of IPC, etc since COM is designed to hide all that from you.

In the future COM already has well define idioms for things like events that are well support by scripting languages, etc should you need them.

Update: there are a lot of ways of implementing COM. You can build it from the first principals with the guide of a good COM book, or use of framework like ATL to save some of the boiler plate. There are a lot of good samples, for example see MSDN.

Answer 3

The big advantage of COM is that you don't need a DLL! Your application would always be running, you say. That means that it can act as the COM object creator ("local server").

If someone would want a "stdcall" DLL instead, you could give them a DLL that internally just forwards all calls to the COM interface. Writing it would be quite trivial. You only have 5 functions, you say. That suggests you have one COM interface, with those 5 methods. When the wrapper DLL loads, it asks your EXE to create its COM object. The DLL in turn exposes 5 stdcall methods, each of which calls one method on the COM object.

Answer 4

You could use a dll. I'd consider it. But I'd also consider whipping up a simple http-based API, preferably RESTful.

Advantages: Easy to port. Can write a client app from any language trivially. Can work across a network. Testing becomes easier (use a scripting language or your browser).

Disadvantages: Performance is going to be slower. Significantly more plumbing to set it up in C++. I'm not sure if LabView can make http calls.

Something like:

http://xxx/data [GET, maybe POST for testing]

http://xxx/data/start [POST]

http://xxx/data/stop [POST]

http://xxx/data/parameters [POST]

Given your requirements it may be slightly overkill but then maybe not. Many apps I've worked on have had to be ported and would have been quicker to extend if we could have used a faster dev language to test and extend it.

Answer 5

LabVIEW supports making DLL calls, but this is one of the weaker spots in LabVIEW development. Done incorrectly, this can lead to an application that is more prone to crashes. As a LabVIEW developer, I like MattyT's suggestion of creating an HTTP service. Every language on every platform that can make a TCP/IP port can access it then. I think you could use your own custom TCP/IP protocol instead of full bore HTTP, but either way the compatability issue is solved.

If you do use DLLs, here are some tips. Don't use structs or pointers to structs in your function call argument list. Don't allocate memory in the DLL to be passed back to LabVIEW. LabVIEW has built in memmory management and won't play well with others. This may apply to other languages that have memory management such as Java. LabVIEW will work better if it allocates the memory and passes a pointer to the DLL. Avoid pointers, arrays and strings where possible. LabVIEW can pass these to DLLs, but it is an advanced topic and works best when the LabVIEW developer also knows C, which will not always be the case.