share DLL reference between LV and TS

[mitulatbati]

Hello,

I have a dll, which I want to access under LabVIEW and TestStand too. When I open the .dll, it returns a reference number, let´s say handle or reference. This is a reference to a VI, in which I want to modify the indicators on the front panel, a kind of monitor. This number I have to feed each time to the .dll, when I access it.

So, it is working, if I use the dll only in TS, or only in LV. But if I save the reference number in a global variable in TS, then it doesn´t work anymore in LV. I feed the refnum (numeric) from TS to LV, and I get "Invalid reference" error message.

Has anyone an idea, how should I solve it?

Mitulatbati

[rolfk]

Not by sharing VIs but by proper interprocess communication. Your DLL is once executed in the TS process and once in the LabVIEW process. They do not share any data between the two, since the memory from one process is not accessible by the other. By using interprocess communication such as TCP/IP, shared memory, files or similar you can work around this limitation of modern OSes.

[SFK]

Rolf is right.

A simple approach to resolve the issue might be a Functional Global Variable VI, which handles all DLL calls and stores the handle/reference in a shift register. This VI could then be called by both your LabVIEW application and TestStand.

Best regards,

Sebastian

[rolfk]

How would a functional global VI be shared between the LabVIEW and TestStand process? Maybe I'm missing some featuers in newer versions of TestStand but as long as the two contextes are in a different process, there is no way a global VI would share its information between the two.

[SFK]

Hi Rolf,


as long as you are running the "application" VIs directly in LabVIEW, the execution context is the same as in any VI called from TestStand - therefore, a shared FGV subVI can be called by both "sides".

You are right though that this will not work with a ready-built LabVIEW executable - unless you would try to reconfigure the LabVIEW adaptor to the runtime engine...

Best regards,
Sebastian