global variable corruption

[slugger]

hi

im using labview 6.1.
i have a frame in a sub-vi that that reads 16 bytes from com7 (in my pc) into a global variable using a custom DLL. this variable is then used later to compare some data in another sub-vi.
this was working fine for a day, then this morning i started it again and ran it. when i got to the point where this "read" happens i got a dr watson exception message. (i am running the application on nt4 in the development environment). after this point the gloabal had rubbish in it whenever i did a read, although it did also hold the basic read data. after a reboot etc it still did it. the fix was to completely remove this global from the application vi and my file globals.vi , create a new one and then use that in the same manner.

everything was ok for an hour.

then the same thing happened again.

any ideas? this is really annoying.

[slugger]

sorry

ive bumped it as this is urgent !!

[Ben]

Post everything you have so we can have a look.

I suspect the dll.

Ben

[slugger]

the dll appears to be fine and has been used in a teststand environment for years. I dont think its that.
When i first probed this problem i did it without the global and just sent the data to a string indicator and got the correct 16 bytes every time, then i connected the global to the output of the dll (ie the buffer, as the dll is NI_comRD) and read it again and the data in the string was corrupted as well !!! showing 19 bytes in it. the dll count and return both said 16. the fix for the whole thing was to remove the global from everywhere and create a new one used in the same manner. this was ok for approx 100 reads (note that this was stopped and started a few times and not continuous operation) and then i dr watsoned again and it started all over.

once it even appeared to show a section of text from another file of some sort. the 485 device i send the data from correctly sends 16 bytes every time.

very very frustrating

[Ben]

OK, wild guess time.

Is the dll call node orange or yellow?

Ben

[Jarrod_S.]

It sounds like you're DLL is corrupting LabVIEW's memory. This doesn't necessarily mean you're DLL is doing anything wrong. It just means you have to be careful when calling external code in LabVIEW to make sure that it plays nice and doesn't stomp on LabVIEW's internal memory.

If you expect your DLL to output a 16-character buffer on every call, then you should be passing in a dummy string into the buffer input for your Call Library Function Node of at least 16 characters in length. This will help LabVIEW allocate the data correctly and pass it into the DLL to operate on. The DLL should not resize this buffer, because LabVIEW won't be notified.

Are you doing anything along these lines?

Message Edited by Jarrod S. on 03-01-2007 03:06 PM

[slugger]

Ben and Jarrod,

many thanks

it is in fact orange (as Ben asked) and no im not doing this when i use it.
being a noob i didnt realise i might have to...


i'll try this tomorrow and let you know what happens

i did wonder why the dll might have a buffer input, but it makes sense as it allocates the required memory (i now see).


thanks again

[slugger]

PS Ben


what does orange and yellow indicate?

[Ben]

Orange indicate the dll may not be thread safe and runs in the UI thread.

Yellow indicates thread safe and and can be called from more than one place at the same time.

Ben

[slugger]

ta
i assume what Jarrod stated is the problem then huh?