Control a distant vi from on labview generated DLL

[mattmatt]

Hello,

I have one vi (let's call it V) up and runing on computer A. (yes, math courses nether bothered me...)
I would like to have one C++ application (C) to retrieve values from V.
Of course, C can run on a different computer.

One solution would be to implement one tcp/ip server in V. I would like to avoid this, if possible: C is not mine, and it is always difficult or at least time consuming to agree on a protocol (usually, the size of the protocol grows a lot, only to check errors.)

What I did: A vi V2, that connects to V and retrieve datas.
V2 is distributed as a DLL, called by C.

Annoying problem: I did not find any way to keep one valid Application Reference between two function calls: as a result, on each data request from C, I have to (at about 10 Hz):

• open one new Application Reference,
• retrieve datas,
• and close the Application Reference.

The problem is that this is not very efficient : sometimes, the operation takes more than 3 sec instead of say 30 ms, or even worse never return.

Why did I not find any way to keep Application Reference living between two function calls?
because the Open Application Reference is automatically closed when the opening vi (that I would have liked to be one function of my DLL) ends

Any suggestion would be greatly appreciated.

Salutations

Matthieu Dubuget

[tst]

I don't have any experience with this, but how about this:

Make another VI (V3?) which will open the application reference to V (once) and will continually extract the data. Then, enable the ActiveX interface for the VI server and use ActiveX to get C to extract the information from the always running V3 using the VI server calls in C. Even if you can't do this, it might give you some ideas.

Obviously, if this is on a single computer, you can use the VI server ActiveX interface to extract the information directly from V without needing to write another VI. I don't think you can do this when the VI is on a remote machine without using DCOM, which is more complex.

The upshot of all this is that you don't have to write a protocol, because it already exists (the VI server exported through ActiveX).

I hope that this makes sense.

[mattmatt]

Thanks for that answer: it gave me some ideas.

I have know one vi of my DLL that launch one dynamic vi that loops forever and get the datas from the acquisition application (thanks for the idea).

And that's all: the other vis of the DLL only get and give backs datas in one global vi.

Problems: I wanted a third vi to stop my infinite loop. It seems to work when run as vi, but behaves strangely as a DLL. The small 20 lines C program I wrote to test this do not stop: I have to kill it...

I tried different solution to stop loop (signals, end a cadences for loop by name, unload the vi itself...)

Maybe this part work but the problem is elsewhere ?

Salutations

[tst]

It will be easier to check if you attach your code.

You should also test it by compiling the LV DLL and then calling it from LV.