Call Library Node function mismatch problem

[LuI]

Hi all,

This is a strange problem related to the Call Library Node in LabVIEW 7.11. Maybe a problem for Rolf Kalbermatter? ;-))

I have a rather large test app that is still in LV 7.11. It connects to a unit under test (UUT) via a dll, calling some of its functions. Most of those functions have the very same prototype a la long myGetDat(long hDev, unsigned char *pcBuf, unsigned long *pDWBSize);
Al the different calls are wrapped with VIs that sit deep in the apps hierarchy, so the calls are done in the required logical and timed sequence. This all worked for years...

Some months ago I had to change something much higher in the hierarchy and I can not imagine having changed anything related to those DLL calls. Anyway, the app got instable, in some attempts the UUT did not return data. Drove me nuts and bolts to find the source of the problem.

More or less when explaining the problem to someone else, I found out that the results of a call of function1 was not as expected and as such abandoned, returning an apropriate error code for 'NoData'. Instead the results have been similar to those of function2, allthough the node was still correctly configured to call function1. When I reconfigured that node to call function2, ran it once and than reconfigured it to function1, than it did what expected. This made me loose my faith! Looked like the Call Library Node did call function2 instead of function1... And I believe it is doing well in some calls and not in others.

Anyone having an explanation for such behaviour. And, even more important, what to do in order to avoid such misbehaviour or how to handle it?

-- 
Greetings from Germany!

[rolfk]

I'm sorry I can't really think of any way the behaviour as you describe would happen, other than that your VIs somehow got corrupted and indeed changed the function name they are trying to link to. However if that would be the case I would expect the Call Library Node configuration dialog to also show the new wrong name when opened. It does not make much sense that the VI would show one name but internally refer to a different function name eventhough I can't say for sure that the information showed in the dialog is not somehow stored and compiled into the compiled binary code.

One thing you could try is to create a dummy VI that contains all your Driver VIs, then press the run button while you hold down the Ctrl and Shift key. This will recompile the entre hierarchy of VIs in memory and in that way make sure, that any eventually stored reference to a DLL function name should be equivalent to the name shown in the configuration dialog.

This Ctrl-Shift recompile step is something I regularly do in my projects (not without first committing everything to a version control system) mostly to clean out the disk hierarchy of  old and stale VIs afterwards (everything VI or CTL like, not having the current date and time is simply not part of the project anymore) but also recovered from strange errors sometimes that seemed to come from corrupted code doing definitely not the same as the diagram was showing it should do.

Message Edited by rolfk on 02-07-2010 10:44 AM

[smercurio_fc]

I had this happen to me on one occasion, but in that case it was due to opening a VI written in an older version of LabVIEW with a newer version. It only happened once, so at the time I suspected the original VI was just a "little" corrupted.

[LuI]

Rolf & Smercurio,

thx for your replies and guesses. Apreciate it and will check that tricks out.

After a weekend of re-thinking I will also check (or let the respective develloper of the dll do it) if the respective functions can switch into a bad behaviour where the kind of switch their behaviour. E.g. function 1 performs action of function 2 than. May take some days though.

Thank you again!

Greetings from Germany!
--
Uwe