Fastest way to exchange string between a Labview DLL and Labview program

[madskg]

I'm using a Labview Shared Library (DLL) to comunicate between a C# program (made by another company) and a labview Executeable (which means different processes) on the same PC. Currently i'm using network published shared variables, to communicate between the Labview DLL and the LABVIEW program (both made by me) which works well, except for the performance.

 

Each time the DLL is called it needs to connect to the shared variable, which takes between 50 and 300 ms. When it is connected, the data transfer is instant. I have tried to use the PSP "Open Variable Connection In Background", which is a bit faster, because it doesn't wait to verify the connection. But it still adds some overhead.

 

I have also tried to use notifiers from this example: https://lavag.org/topic/10408-communication-between-projects/ . Opening connection and sending the notifier takes 50 - 100 ms.

 

I guess both the notifier and the shared variables are "slow" because they use the network communication, even if it is the same pc both programs are running on (localhost).

 

Does any of you know of a faster method of communicating between a program that is running continuesly (connection open constantly) and one only exectuted when new data is ready (connection "re"-opened on every instance)?

 

Thanks in advance.

 

Best Regards

Mads

 

 

 

 

 

 

[ned]

This sounds like a good application for UDP. You won't lose data transferring between two applications on the same machine. I've done exactly this - built a DLL in LabVIEW that acted as a plugin for another application and provided minimal UDP communication, then sent and received data from a separate LabVIEW application. Of course, you can also use UDP directly from C#. Another option might be ActiveX.

[Tim_S]

I've not tried using shared variables in a DLL. Is it not possible to keep the shared variable open between calls to the DLL? I would normally open the reference and putting it in a shift register for the next call.

[madskg]

Thanks for your inputs. I will give UDP a go. Maybe Active-X is the way to go, i've never used Active-x myself, so that can be plan b.  

 

I don't know how the C# program is made, but i suppose that the C# program maybe can keep the DLL in memory, and the shared variables would remain connected (and saving the reference in a functional global)... 

[Zyga]

As far as I know ActiveX should be plan "z". It might cause unexpected problems, just like .net. It's hard to imagine how you can exchange data with compiled code without exact knowledge how it's made. I'm not experienced it this kind of things but it sounds hardly to be done. Shared variables are used to communicate e.g. with PLC systems, so it suggesting this should work way faster than mentioned 50-300ms (for sure more stable).
You can also take a closer look on shared memory. I have seen some LV implementations, not only for RT targets on which it is native LV functionality.