global variable corruption

[Jarrod_S.]

It's definitely a first thing to check. This is good practice with any data type of variable length (strings, arrays, etc). If the input is just a single integer, then LabVIEW will of course know how to handle the memory allocation correctly. The problem is that DLLs in general are black boxes, and LabVIEW usually can't know what to expect to come out of it. It might therefore accidentally deallocate parts of memory that the DLL was using for output values.

[rolfk]

---

@slugger wrote:
ta
i assume what Jarrod stated is the problem then huh?

---

In 99.99999999% of the cases where LabVIEW memory gets modified magically either in causing random data as you have seen or causing crashes at random moments such as when closing a VI or LabVIEW altogether, it is indeed a DLL overwriting memory it should not have done, and in about 95% of those cases it is because the person implementing the Call Library Node VI forgot to allocate one or more buffers in the LabVIEW diagram for a DLL function array or string output parameter. The other 5% are because of bugs in the DLL.

Rolf Kalbermatter

[Jarrod_S.]

You might also note, slugger, that LabVIEW 8.2 took some steps towards helping users deal with this exact issue. When you configure a string parameter for your DLL, there's a new setting you can configure called Minimum Size. Here you can make your allocation directly in the Call Library Function Node, instead of having to write G code to do the same. The good and bad thing is that your problem is very common, so it's always a goal of ours to try to help out!

Message Edited by Jarrod S. on 03-02-2007 03:54 PM

[slugger]

it apperas to be fine now


much appreciated all

[rolfk]

---

@jarrod S. wrote:
You might also note, slugger, that LabVIEW 8.2 took some steps towards helping users deal with this exact issue. When you configure a string parameter for your DLL, there's a new setting you can configure called Minimum Size. Here you can make your allocation directly in the Call Library Function Node, instead of having to write G code to do the same. The good and bad thing is that your problem is very common, so it's always a goal of ours to try to help out!

---

Nice feature indeed Jarrod! But, yes there is a but, or maybe not!

How about "Save for previous version"! The resulting VI could be plainly wrong but no error/warning or broken arrow is generated for such a thing. When I tried it I got an error code from the function that probably did some exception handling around that. Guess that is an oversight by whomever implemented this feature since a normal CLN always generated an error when C type pointers are configured and the left terminal is not connected. So bad, bad, bad!

Rolf Kalbermatter.