LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW 2009 Crashes

I have a intermittent crash problem with LabVIEW 2009 and I am unable to determine the source.  It is very infrequent but when it crashes LabVIEW disappears and I do not get any debug information, even upon re-launch.

 

I have a suspicion that it is being cause by a DLL call to an internally developed DLL.  I found the following knowledge base here where it recommends to "Make sure that you wire all inputs and outputs of your Call Library Function Node".  I have gone over all the DLL calls and I am focusing my suspicion what determines an "output".  There are a few cases where I need to pass data in as an "Array Data Pointer" but I do not wire the output because I do not need the data.  Are "Array Data Pointers" considered outputs? Should I be wiring this to something?  What should it get wired to so not to: "LabVIEW assumes that the DLL function does not need the allocated memory passed on the input side and will use it for something else."...

 

I have attached an example of a piece of code where I do not wire the output.  The top input node passes an array of U8 via the "Array Data Pointer".  Should the output be wired to "something"?  Could the be the cause of intermittent crashes?

 

 

0 Kudos
Message 1 of 7
(3,198 Views)

I think you didn´t give a minimum size for the Arrays on the parameter tab.

0 Kudos
Message 2 of 7
(3,172 Views)

@McBrain wrote:

I think you didn´t give a minimum size for the Arrays on the parameter tab.


I don't think that is the problem in my case.  According to LV help: "If you pass in an array that is smaller than the minimum size, LabVIEW enlarges the size of the array to the minimum. If you pass in an array that is bigger than the minimum, the array retains the larger size."  I always preallocate an array of proper size, so no need to set the minimum.

 

But, as I was thinking in the origional post, that first parameter is not wired to anything as an output (not too easy to see with the other vertical wire in my one example).  I think I will wire it to the edge of a structure element (I do not need it as an indicator).  Will this prevent - "LabVIEW assumes that the DLL function does not need the allocated memory passed on the input side and will use it for something else."?   [-Quote from knowledge base link above.]

0 Kudos
Message 3 of 7
(3,160 Views)

I don't know the answer to your question but what I do know...

 

the wires on the input are the same buffers used for the output. years ago I witnessed the data on the input side changing after the call completed. It is one of those rare conditions in LV where data can travel backwards through a wire (it blew my mind when I saw it).

 

I hope you figure this out.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 7
(3,146 Views)

So, I've decided to go ahead and wire these "outputs" to something since it can't hurt, right?  But, I don't want to wire it to any new indicators because I don't want to change the connector pane.  Any recomendations?

Some things I was thinking...

- Wrap the Dll call in a flat sequence structure and wire the outputs to a tunel (nothing on the other side of the tunnel)

- Wrap the Dll call in an "in place element structure" without any elements and wire the outputs to a tunel (nothing on the other side of the tunnel)

- Wrap the Dll call in a single iteration loop and wire the output to a tunnel or shift register (again nothing on the other side)

- Connect the individual outputs to an "Always Copy" with nothing on the output of the "always copy"

 

(where was that april fools about the wire nuts,  I think I need one...)

0 Kudos
Message 5 of 7
(3,122 Views)

I just got done looking at the "Call DLL.vi" example and noticed that for array data pointers (and/or strings) in those examples where the data was an input the "Constant" setting was checked for that particular parameter.  Could this be my problem, not making those array data pointers as constants?

0 Kudos
Message 6 of 7
(3,111 Views)

Is your DLL thread-safe? According to the image you've provided, the Call Library Node is configured to run in any thread. Depending on how the calling VI is set up (e.g. is it reentrant), virtually any thread could call into your DLL at any time. That, of course, all depends on how your application is written.

 

Also, does the DLL stash the array data pointer inside by doing a shallow copy to a global variable or static variable within the function? That is, just keeping the array pointer rather than making a deep copy into a new buffer? When passing array data pointers to a Call Library Node, assume that the pointer is valid only for the duration of the call to the library.

 

The best approach, if feasible, is to connect a debugger to LabVIEW.exe after you've launched LV and are ready to run your program. Then you can catch the crash in the act and hopefully get a better idea about what's gone wrong.

intvsteve
LabVIEW R&D
0 Kudos
Message 7 of 7
(3,090 Views)