For the complex data type,How to build the Dll with C/C++ compatible interface

[Ivan.Chen]

Hi,

I have used Labview FPGA module to develop a test equipment. Now, I need to write a driver which required to be a Dll with C/C++ compatible interface for this equipment. So that my customer who is familiar with C/C++ can call the driver without any study on labview. But I got some problem on how to convert the complex labview data type to the C/C++ data. In order to explain my question clearly, I attached an simple example.(see the attachment) I try to build a Dll for the attached example VI and get the the function prototype in the head files as below:

"void OpenFpgaReference(LStrHandle *RIODevice, TD1 *errorIn, LVRefNum *FPGAVIReferenceOut, TD1 *errorOut) "

As you known, the data tpye "LStrHandle *RIODevice" and "LVRefNum *FPGAVIReferenceOut" are Labview data format. C/C++ don't have these kind of data type and can't reconige it. it results in that I can't call the Dll by C/C++ programing language. How to convert these two labview data type to the C/C++ compatible data format and then build the Dll? Anyone know about this?

The reply is truely apprecaited! Thanks in advancd.

[Ivan.Chen]

As I found in the following article:

http://digital.ni.com/public.nsf/websearch/FB001AA027C8998386256AAD006C142D?OpenDocument

LVRefNum is LabVIEW VISA resource name or refnum,and "it's impossible to convert the LabVIEW VISA resource name or refnum to a valid VISession ID."
It means that external code modules can't access&control the VISA session wich is open by labview. But for my application, I will not attempt to access that VISA session by extenal code(C/C++). I just hope to save this VISA session in the external code after I opened it in Labview dll; and pass it back to the labview dll once needed. So that I don't need to open that session again when I need to control the device. Is it possible to make it?

[rolfk · Accepted solution]

---

Ivan.Chen wrote:

As I found in the following article:

http://digital.ni.com/public.nsf/websearch/FB001AA027C8998386256AAD006C142D?OpenDocument

LVRefNum is LabVIEW VISA resource name or refnum,and "it's impossible to convert the LabVIEW VISA resource name or refnum to a valid VISession ID."
It means that external code modules can't access&control the VISA session wich is open by labview. But for my application, I will not attempt to access that VISA session by extenal code(C/C++). I just hope to save this VISA session in the external code after I opened it in Labview dll; and pass it back to the labview dll once needed. So that I don't need to open that session again when I need to control the device. Is it possible to make it?

---

A LVRefNum is really just a simple int32 value. Its meaning is useless for other environments than the one that created it so you can ideed not do anything in your C/C++ caller but pass it back to other functions in your DLL but that is often not a problem at all.

You can take the following declaration from the LabVIEW extcode.h headers and add them to your delabviewed header files to make it work in such a way.

#define Private(T)    typedef struct T##_t { void *p; } *T

Private(LVRefNum);

For the LStrHandle you should define a standard C string instead in your DLL export and document what size the string buffer should have if it is an output parameter.

The error clusters TD1 should also be split into their separate (C compatible) parameters for all elements or just left away entirely.

Rolf Kalbermatter

[Ivan.Chen]

Thank you very much!
I finally use "type cast" VI to convert the LVRefNum to a int32.

[achalsaraiya]

Hi Ivan,

I am also facing same problem. Can you please elaborate exactly what you did in your vi, and if possible can you please send me your labview vi/project as it would be very much. You can either upload on this thread or send it on my email id : achalsaraiya@yahoo.co.in

Thanks

Achal

[Ivan.Chen]

Hi,

Here I attached the example.

[mishklyar]

rolfk 

"The error clusters TD1 should also be split into their separate (C compatible) parameters for all elements or just left

away entirely."

It is possible to pass a whole clusters to DLL's, or I miss something here?

[rolfk]

---

mishklyar wrote:

rolfk 

"The error clusters TD1 should also be split into their separate (C compatible) parameters for all elements or just left

away entirely."

It is possible to pass a whole clusters to DLL's, or I miss something here?

---

It is possible by choosing Adapt to Type, BUT!!

This will pass a LStrHandle as the error source and that is a LabVIEW data handle that can only be manipulated by LabVIEW memory manger functions. This has quite a few implications:

If the DLL is a LabVIEW DLL it must be created in the same LabVIEW version as the LabVIEW version used to call it. If they do not match exactly, the DLL will be executed in the context of its own LabVIEW runtime resulting in two different LabVIEW processes with their own memory manager trying to deal with that handle which will without doubt cause crashes.

It won't be possible to call such a LabVIEW created DLL from non LabVIEW callers since they do not know how to create such data handles and even if they would be programmed specifically to do the right thing they could not really get at the necessary memory manager calls of the runtime engine the DLL is executed in.

If the DLL is a C DLL it must link with labview.lib and use the memory manager functions documented in the External Codes Reference Manual to deal with such a handle. Such a DLL can also only be called in the context of a LabVIEW system or runtime application.

Rolf Kalbermatter

Message Edited by rolfk on 06-11-2009 10:24 AM

[mishklyar]

Now I remember that it was a headake for me to pass a string from dll to LV without using extcode.h,

finaly there was some solution, but I didn't like it.

   But do you mean that there is no way to use robust string passing to/from dll's without using labview

extcode.h?

   I mean some casting to C/C++ type of function parameters, even *void,and then to use some manipulations

with raw memory? It's time-demanding, but IMHO gives you a control of what's going on there.

michael

[rolfk]

---

mishklyar wrote:

Now I remember that it was a headake for me to pass a string from dll to LV without using extcode.h,

finaly there was some solution, but I didn't like it.

   But do you mean that there is no way to use robust string passing to/from dll's without using labview

extcode.h?

   I mean some casting to C/C++ type of function parameters, even *void,and then to use some manipulations

with raw memory? It's time-demanding, but IMHO gives you a control of what's going on there.

michael

---

Casting is not really a good idea in C land unless you know EXACTLY what you are doing. Of course you can read the information in your DLL with normal C but don't try to change the information in any way that would require a resizing of the string handle. Resizing, allocation and deallocation of string (and array) handles can onlybe doen with the LabVIEW memory manager functions and you need to make sure that you use the same memory manager that is used by the calling LabVIEW process and linking to labview.lib in you DLL project is the only way to guarantee that without having very intimate (and LabVIEW version dependant) information about how this is all handled in LabVIEW land.

Rolf Kalbermatter