LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW encounters a problem and needs to close

Hi all,

I have a quite large project in LabVIEW7.1,  which includes some 20 calls to different dlls. This started to cause some problems a few day ago: http://forums.ni.com/ni/board/message?board.id=170&message.id=183945#M183945
where LabVIEW claims to miss external code.
Now that I have gone through all of the dll-calls, have pointed LV to the actual DLLs, have re-chosen the respective functions, and saved all those VIs, LabVIEW 'encounters a problem and needs to close'.
And this is reproducable even after a restart of LV, of XP and a repair-installation of LV.

In fact this seems to be a problem related to search & load these dlls, as they worked flawlessly for some days and I have not changed any data types or sizes. And the original statement of LV was "LabVIEW: External code not present. VI "Main.vi" was stopped at node 0xD60 of subVI ...". And those problems could than be repaired by re-configuring the respective call, re-browsing to the dll and re-choosing the respective dll-function. Now that I did this for all those calls, this  was not a repair, but a killer ;-((

Any ideas if this could be caused by not finding the DLL?
Any hints on what I could do?
Any background info on LV search strategy, especially related to locate & load those libraries?

Any help would be apreciated!
Greetings from Germany!
--
Uwe


0 Kudos
Message 1 of 6
(2,627 Views)

Uwe,

the problem you are describing sounds like a memory corruption to me. this can happen in your case most propably by two facts:

a) you use DLLs which corrupts the memory on their own affecting LV by it (can happen for instance with thread-unsave DLLs)

b) you create pointers to data within the DLLs which are passed back to LV but not handled properly there (e.g. closing them).

if i had to guess, i would more likely tend to possibility a).....

can you test the functionality of the functions from the DLLs not using LV? can you find out WHICH DLLcall creates the problem? if yes, did you try changing calling convetion/datatypes for the cll?

 

Norbert B.

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 2 of 6
(2,623 Views)
Norbert,

thanx for your quick reply.
Those dlls are used by a C-programmer as well. In fact, this is the same person that wrote the dlls. He just fixed some miror bugs recently. Maybe in his other app, he uses an older version, but I have tried exchanging the dll with some older versions as well with no success. (In fact, I have just renamed those dll versions to, say 'bll.dll.old001', 'bll.dll.old002' and so on.)

So the chance of a new memory-related bug is there but not very likely.
Due to another bug I changed the calling conventions from 'reentrant' to 'Run in UI thread' about two weeks ago. That did not solve the original bug, but started those 'external code not found' stops by LabVIEW. AND, due to the fact, that some calls last more than a second, this made it impossibel to operate my UI. So I  rechecked reentrancy with the C-develloper and changed it back. The UI was operabel again, but those '..not found' stops did not go away.

The craziest thing is, in fact there are just 3 dlls _I_ call. And a 'bl.dll' is the one that is called mostly. And this one is found, say, in 18 out of 21 different calls (e.g. calls to different functions of that dll), but fails when I call the, say, 19th function.

Greetings from Germany!
--
Uwe

0 Kudos
Message 3 of 6
(2,619 Views)

Uwe,

 

there can be several reasons why calls do not work as intended. first of all the question:

is it always the same function that fails or does it change? Another question: Did you change the calling convetion as well (C/stdcall)? What about the parameters: is it possible that there are datatypes used which lead LV to the errors?

Theres something else you might to check: it sound a bit like LV gets messed up with the entry points of your DLLs. Is the information on the exported functions included in the DLL? When configuring the CLFN, do you see all exported functions immediatly?

 

Norbert B.

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 4 of 6
(2,609 Views)
Norbert,

thanx again for your assistance.
> is it always the same function that fails or does it change?
There are about 20 different functions and I have a wrapper vi for each of 'em. I have the impression that the 'code missing' happens just a the first call of that vi. Afterwards it works as expected, until the next wrapper vi calling the same dll with a different function, is called.

>
Did you change the calling convetion as well (C/stdcall)?
Not that I am aware of nor have recognised. I'll re-check that, allthough I'd expect that the call would not work at all than.

>
What about the parameters: is it possible that there are datatypes used which lead LV to the errors?
Those have not been changed and have worked for several months, if not years now. The only knon difference between the working and the non-working machine is the first runs W2k, while the latter runs WXP.

>
Is the information on the exported functions included in the DLL? When configuring the CLFN, do you see all exported functions immediatly?
Yes.

Greetings from Germany!
--
Uwe

0 Kudos
Message 5 of 6
(2,602 Views)
Just a follow-up:

I seem to have it fixed now, allthough I feel like magic, somehow. This is the solution:
Finally I replaced all wrapper VI (those that actually call the dll) with a backuped version that was about 10 days old.
And I replaced the dlls, which had been debug version up to now, with release versions.
I am not clear which action did the trick, but now my system is running again :-))

Greetings from Germany!
--
Uwe
0 Kudos
Message 6 of 6
(2,591 Views)