LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VIs containing DLL close Labview abruptly when I close all VI windows

I've written a DLL that interfaces with Labview (and am still struggling through that process). However, I've noticed that irrespective of if I run the VI containing calls to the DLL or I don't, when I close the VI, and expect the LV home screen to load, it instead quits entirely. VIs without my DLL references don't close LV preemptively, just those with references to my DLL. I don't get a indication when rebooting Labview that it crashed. It just starts up like new.

 

Is this sympotmatic of any particular DLL ailment? Posting my code is rather cumbersome, so I'm instead wondering if anyone would know how such a problem could occur. Perhaps it could help fix some of my other issues (which all deal with the stability of Labview, and are undoubtably tied to the DLL doing something it shouldn't.)

0 Kudos
Message 1 of 10
(3,615 Views)

majoris wrote:

Posting my code is rather cumbersome, so I'm instead wondering if anyone would know how such a problem could occur.


  

I faced the same issue sometime before. I don't know exactly how it was solved. But if you post your code without feeling cumbersome, you can get your apple.



0 Kudos
Message 2 of 10
(3,603 Views)

i still doubt on that dll that you have written....

 

They usually crash out if some reference pointing to some memory are not cleared properly...and appear in labVIEW when you try to close them...

Regards
Guru (CLA)
0 Kudos
Message 3 of 10
(3,594 Views)

Attached is much of the code so far.

 

IMAQpx TEST (in the IMAQpx folder) is the VI where I build a sample program of my DLL functions. Right now, I'm only calling the first and the last. All this stuff will be unrunnable as a result of library and path issues, but you can at least see what's going on.

 

The DLL code is in PIXIS DLL \ PIXIS DLL . h and . c

 

The current build of the DLL only includes the init and uninit functions (and all the helpers which are not DLL functions). I couldn't include the entire project due to size constraints, so I just included some of the source.

 

If you see anything funny let me know. I'm not super up on how the LV Memory Manager really works, and my general feeling is that is where the issue is.

 

The full code does often run to completion in LV even with all the functions included and wired properly. But sometimes LV crashes during execution of my code or after execution, leading me to believe I'm not cleaning stuff up or I'm overwriting important LV code or variables in memory by accident.

Message Edited by majoris on 12-18-2009 09:18 AM
0 Kudos
Message 4 of 10
(3,576 Views)
I still haven't been able to figure out this issue and am instead going to create an executable that does much of what I want from the command line. This seems like a really silly workaround though, as it destroys the flexibility of having the VIs.
0 Kudos
Message 5 of 10
(3,507 Views)

Hi majoris,

 

You may have seen this KB: http://digital.ni.com/public.nsf/allkb/7253D2F0D91F68058625752F005AB672?OpenDocument

 

My best guess is it is what you say that there is some memory being corrupted or something. From a quick look through the DLL code it doesn't seem unreasonable so I will run it past some others.

Jeff | LabVIEW Software Engineer
0 Kudos
Message 6 of 10
(3,482 Views)

Hi,

  The same thing happen to me when I use Labview build dll in VC++ or Labview itself. Only thing I have done is redeclare all the string input and output of the dll. Just initialieze string array(of size equal to length of output string) for all the string input and output of the dll, then that problem get solved

 

Regards

Assumptha

0 Kudos
Message 7 of 10
(3,469 Views)

Hey majoris,

 

If you write a quick wrapper in C or C++ for the DLL, do you hit any problems?

 

The other thing is you can try changing it from running in the UI thread to running in any thread.

Jeff | LabVIEW Software Engineer
0 Kudos
Message 8 of 10
(3,443 Views)

So I made a copy of my project and started widdling away at so that there were fewer and fewer elements to it. Eventually I got to the point where I was juggling which header files I included.

 

nivision.h and it's libraries, perhaps, are my culprits (for this specific instance of this specific problem which is hardly the only one).

 

I essentially stripped all my code out and removed the 3rd party libraries I'm using, and with only NI libraries linked (and not explicitly calling any NI functionality), Labview will crash after loading and closing a VI containing the Call Funtion Library Node.

 

I'd add the code, but it isn't much more than a function that multiplies two numbers (which runs properly).

 

Hopefully the bug found in this post has been addressed.

 

I've been double checking silly things like calling conventions and the UI Thread/Any Thread option with little change in functionality.

 

Guess I'll continue on making a C only solution for this until I can work through these issues.

 

Thanks for your help so far. Any more help would be greatly appreciated.

0 Kudos
Message 9 of 10
(3,393 Views)
Ok forget the previous remark. The code is more involved than what I thought at first. Not really easy readable for my idea either.
Message Edited by rolfk on 01-04-2010 09:52 PM
Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 10 of 10
(3,380 Views)