importing cvi instrument driver and c string pointer

[test_man]

Hi,
Here is my problem.

I created function panel in cvi with one function.
int __stdcall f1(char *char_pointer)

then I created dll and imported to labview. Fine.

when I place this function from instrument driver pallete on block diagram (main.vi),
it had char_pointer as input, error in as input, return as output and error out as output.

How do I get my string pointer value back from dll?

When I opened f1.vi (instrument driver vi) block diagram there was library call and I also saw string pointer output but it was not connected anywhere. I added this output (string pointer) from f1.vi connector pane and now I have that output in my main.vi.
Is this something I have to do for all the functions or am I missing something?

Please help.

Sheetal

[test_man]

any Labview/CVI expert out there?
Please help.

Sheetal

[Travis_M.]

Sheetal,


When you are creating your instrument driver in CVI include extra "output" indicators on the fp. This will add parameters to your function call that LabVIEW will interpret as output wires when you "Import CVI Instrument Driver".

[test_man]

Hi,
What should be my prototype if I want to pass a string pointer and want modified value back?

int __stdcall my_function(char *string); //????

do you have any fp example?
Thanks.
Sheetal

[Johnner]

Here's a great example that shows you exactly how to do this, both from the LabVIEW and the C side of things:

Passing a Variety of Data Types from DLL to LabVIEW

--John

[test_man]

John,
Here is what I am trying to do.
I have included my cvi project from where I am exporting function panel.
I have written my comments in temp.c file.

Thanks.
Sheetal

[Johnner]

Sheetal,

I think I got the project tweaked to do what you want--see attached. Bear in mind that I think I'm more of a novice with CVI than you are with LabVIEW. I added to your comments in temp.c to explain the changes I made.

The biggest change was that I had to add an additional string buffer in order to accomplish the function's aim of taking an input and concatenating additional characters. When you pass a string from LabVIEW to a DLL, you can't add to its length unless you make use of the LabVIEW Memory Manager functions. If you don't want to use those functions, then you have to do things like use a secondary buffer from LabVIEW that is preallocated to be long enough to hold the string you generate in the DLL.

I strongly encourage you to examine and practice with the functions in the example found at the "Passing a Variety of Data Types from DLL to LabVIEW" link I provided above. That example isn't CVI-specific, but it demonstrates the fundamentals of LabVIEW/DLL interaction that apply with any C development environment, including the Memory Manager functions I mentioned.

A final thought: many people who work with LabVIEW, CVI, and DLLs and aren't doing large projects presumably don't bother to create function panels and use the Import FP tool in LabVIEW. Instead, they just create a DLL with the exported function(s) they want and then manually build a VI with a Call Library node and configure the node appropriately. I don't know which method is more straightforward, but I found that I learned a lot about the FP conversion process by downloading a CVI-based instrument driver (I used the Fluke 45) from the NI Web site, converting it, and examining how the function panel structures mapped to the various VIs that resulted. Maybe you could try the same thing.

Regards,
John

[test_man]

Thank you very much for time and response. So I can not have same parameter doing both jobs of input and output.

For example,
if I want to pass pointer to int and pointer to string in c my function would be"
int __stdcall my_function(int *number, char *string)
{
number = number + 100,
strcat(string, "hello");
}
if input for above functions are 100 and "hi" outout would be 200 and "hihello".

Now if I want to do same thing in labiew my function would be

int __stdcall my_function(int *number, int number_out, char *string, char string_out[])
{
number_out = number + 100,

strcat(string_out, "hello");
}

[test_man]

Thank you very much for time and response. So I can not have same parameter doing both jobs of input and output.

For example,
if I want to pass pointer to int and pointer to string in c my function would be"
int __stdcall my_function(int *number, char *string)
{
number = number + 100,
strcat(string, "hello");
return 0;
}
if input for above functions are 100 and "hi" outout would be 200 and "hihello".

Now if I want to do same thing in labiew my function would be

int __stdcall my_function(int *number, int number_out, char *string, char string_out[])
{
number_out = number + 100,
sprintf(string_out, "%shello), string);
return 0;
}
anaother word input parameters for labview would be double for every pointer use.
is this right?
Thanks.
Sheetal

[Johnner]

Sheetal,

There's no rule that says you can't pass in a pointer to an object from LabVIEW and modify the underlying object in your DLL. So no, you don't have to do things in the way you described.

There are two big issues to deal with when passing LabVIEW data structures to a DLL:
1. Resizing dynamic objects like strings and arrays
2. Getting the appropriate structs defined in the DLL to handle complicated objects like arbitrary LabVIEW clusters.

The only reason I suggested using a second buffer to do your hi -> hihello example was that your version required a resizing of the input string ("hi"), which will crash LabVIEW unless you use special memory manager functions to do it. That's it. My version simply accepted a second string which was already long enough in LabVIEW to handle the concatenated output that you wanted.

I'm a broken record at this point, but you simply have to thoroughly digest the example I mentioned, which demonstrates both the "pass in a larger buffer" approach and the "use the memory manager functions" approach to dealing with dynamic LabVIEW objects in a DLL. That, and make sure to read the "Using External Code in LabVIEW" PDF that comes with every LabVIEW installation.

Good luck,
John