LabVIEW as ActiveX client

[dotan]

I am trying to transfer data from application written in Borland C++ to LabVIEW (such that LabVIEW will graph the data in real-time). I thought of using LabVIEW as an ActiveX client while creating a ActiveX server in my C++ application. I could not find any info or example how to perform that, though I found an example for LabVIEW/CVI (for both client and server).

Any idea?

[parker]

Can you exploit a code interface node and achieve the same result? Instead of using a surrogate, I think you will be talking directly with your C code.


Parker

[Lycangeek]

CINs are definately possible, although I would recommend the DLL interface node first as it is much easier to work with. It all depends on the type of data you want to exchange.

Using ActiveX is another possible solution, especially if the C++ code is an EXE rather than a DLL. Whether to turn your C++ code into an ActiveX server, or call LV's ActiveX server from your C++ code, depends on how you want the system to behave.

Could you give a little more information about your system - and what version of LV you are using?

[dotan]

I am using LabVIEW 7.1.1 and I have a program written in Borland C++ that acuqires AI signal through a DSP card. The C++ program just processes the signal and log that into the disk in real-time. I am trying to have LabVIEW plotted the signal, since LabVIEW's graphical interface is by far superior to what the C++ environment can offer. My plan is to create an ActiveX server in the C++ part, saving the averaged signal, and use LabVIEW as ActiveX client to read and plot the averaged signal.

Another alternative that I thought is to make the LabVIEW program as a DLL and incorporate that into my C++, however for that I will need the LabVIEW application builder.

[Lycangeek]

Personally I would recommend turning it around. It sounds like the C++ code is primarily acting as a device driver with some advanced processing. In that case, you could do the following...

1. Build the C++ code into a DLL.
2. Expose a set of extern C functions to configure the card from LV.
3. Expose extern C functions for "start" and "stop". These could spin off the acquire/process/log in a background thread inside the DLL.
4. Have this background thread update a data block (need some thread protection)
5. Expose a set of extern C functions that read from this data block.

Now you can use the Call Library Node from LV to call these various extern C functions (very easy to do). Also, your UI can provide the knobs, buttons, etc. that allow the user to configure the card to acquire the way they want. Then LV calls down into the DLL to get the data as needed and display it. You could even have LV display the logged data if you want.

What do you think? I'd be happy to go into more detail on any of this if you want.

[dotan]

I would love to get more info in regard to that. My expertise is mostly LabVIEW with some knowledge of Borland C++. The application is indeed a device driver, but it generates a user interface and I am not sure how I can get rid of that and just expose the relevant functions to operate the daq from LV. I could not find any useful tutorial how to crate a DLL from Borland C++, this why I thought it will be more easy to incorporate LV as a DLL in my C++ program.

If you can get me through the steps, that will be very nice.

THanks

[Lycangeek]

Well, there is a limit to what I can do from here - I'm not sure how the code is all put together. Is the UI code important? If not, it would be best to see if you can remove it (comments, #if, delete, etc) and recreate the UI in LV.

I'm not a Borland user but creating a DLL usually involves creating a DEF file to define the functions you want to export from your DLL and configuring the project to build a DLL instead of an EXE. You'll also need to make sure any functions you want to export are wrapped in extern C, like this...

extern "C" {
void foo();
}

Otherwise the C++ compiler mangles the name.

I don't know how hard that will be for your application.

The other thing to consider is to recreate the parts in LV. It sounds like the card already has a DLL device driver that your EXE is calling. If so, then you could create some VIs that just call the driver DLL and have LV do the data logging and display. You might also check with the manufacturer of the card to see if they have a LV interface already built for it. What is the card, by the way?