LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

unsigned char* in dll becomes string

Hello, I have to import a DLL into labview.

 

The function prototype for the DLL is

 

bool GetDefects(unsigned char* image, unsigned char* image2, int rows, int cols);

 

And Labview's DLL Wizard gets this correct character-by-character. No mention of a string.

 

However when I try to wire up some data to the unsigned char* terminals, labview has now decided that this is a string and won't let me connect to its input (the input is the output of an unbundle box, the image of an 'image data'; which is reported by Labview as "The type of the source is 1D array of unsigned byte [8-bit integer (0 to 255).", ie exactly what my DLL's funtion prototype is designed to accept.

 

Memory for the unsigned char* array is allocated by the function that calls the sub functions and will change at run time depending on the image size.

 

So what do I do?

 

(There are some similar posts on this topic but none that help me.)

 

Sorry, not a labview programmer, only have to interface a C++ DLL every once in a while.

 

Thanks again,

 

Gunter

 

 

0 Kudos
Message 1 of 10
(6,689 Views)

It would help for you to upload the VI that calls the DLL, or at least a screenshot; it's hard to figure out what you're seeing.

 

A char * in C is ambiguous. It can be either a pointer to a single character, or a pointer to an array of chars - ie, a string. C has no native string type. LabVIEW doesn't know if you're trying to point to a single U8 value or to a string, so it picks the more common case, a string. You can change the Call Library Function Node configuration so that parameter is an array of U8 passed by pointer, which is the same thing so far as the DLL is concerned. Either way, you need to preallocate the string or array before calling the library function. The easiest way to do this is using Initialize Array, to initialize an array at least as large as the required size (too large is fine, too small may cause errors or crashes).

0 Kudos
Message 2 of 10
(6,668 Views)

Great thank you.

 

I switched to the Call Library Node vi and was able to get things to connect.

 

Thanks again.

 

(but I have another question on the forums as well - hoping you can help me there as well!!!)

 

Gunter

 

0 Kudos
Message 3 of 10
(6,636 Views)

GunterHauschildt wrote:

(but I have another question on the forums as well - hoping you can help me there as well!!!)


Another question relating to calling a function in a DLL, or something else? If it's related to this question, provide a link to it and I'll take a look. If it's on some other topic entirely, I'm not sure I can help. Also, are you using two different forum logins?

0 Kudos
Message 4 of 10
(6,620 Views)

Thanks again - didn't know you be so quick. Thought I'd do some more debugging first.

 

Thanks again,

 

Gunter

0 Kudos
Message 5 of 10
(6,615 Views)

Hello again all, 

 

Labview crashes when I call my DLL. Best I can tell I am following all the rules, in particular, memory is allocated.

 

The DLL takes three pointers (plus some other stuff).

 

The first pointer works fine (but doesn't modify the data). In fact the DLL does most of its work fine; I get the correct return in the "oofs" double*.

 

But its last step is to return data. But any attempt to modify the data pointed to by the second & third pointers causes a crash. 

 

The only code required to make the DLL crash is ...

 

{

objectNegThresholduc[0] = 10;

objectPosThresholduc[0] = 10;

return(1);

}

 

... objectNegThresholduc & objectPostThresholduc are the arrays / memory sent to the DLL by labview.

 

 

Attached is the .vi and some screen shots (to show valid data for the bits used to create the memory) (oofs disabled in the DLL, usually it reports the expected non-zero value).

 

Thanks again,

 

Gunter

0 Kudos
Message 6 of 10
(6,594 Views)

Hello again Nathan, 

 

I've uploaded a new question. I didn't get anywhere in my debugging. Best I can tell I'm following all the rules but labview still crashes.

 

The new post is called "Labview Crashes When I Call DLL" but it seems to be attached to this thread.

 

Thanks again.

 

Gunter

 

 

0 Kudos
Message 7 of 10
(6,590 Views)

Some more debugging.

 

I've made it work, or at least appear to work.

 

"Initializing Array" doesn't seem to have any effect on allocating memory (as all other examples show). The memory seems to get allocated, instead, via the "minimize size" text box in the pull-down config menu. (see attached: sizematters)

 

And doing that (and I have to do that), now the size of the initialized array doesn't matter at all. (see attached sizedoesntmatter). Works even if I randomly enter "10" (which is about 4000 times too small)

 

Is this correct?

 

Gunter

 

 

 

 

 

Download All
0 Kudos
Message 8 of 10
(6,580 Views)

Looks like your question was answered in your other thread.

0 Kudos
Message 9 of 10
(6,551 Views)

Well, when you configure a minimum size in the Call Library Node configuration for a parameter LabVIEW will resize the incoming array to that size IF it is smaller than that value and only after that resizing, pass the pointer to the DLL function. So if you use the "minimum size" configuration in the Call Library Node configuration it does indeed not matter If you use Initialize Array or not.

 

In older LabVIEW versions (<  ~LV2009) the Call Library Node did not allow this configuration and you HAD to initialize the array explicitedly on the diagram. I still prefer the explicit array initialization as it is clearly visible when looking at the diagram. The configuration in the Call Library Node is convinient but hides an important detail about the CLN handling in a dialog that has to be explicitedly opened to verify that it's correctly done.

Rolf Kalbermatter
My Blog
0 Kudos
Message 10 of 10
(6,538 Views)