I am having some issues with access violation errors that shuts down LabView when running some tests. I have found this link http://digital.ni.com/public.nsf/allkb/7253D2F0D91F68058625752F005AB672 where it says that all inputs and outputs of the call node have to be connected in order to not get any memory access issues. My question is, how correct is this? I see for example that some of the vi's that we've got from National Instruments doesn't comply with this, e.g DAQmx Create DO channel (sub).vi or DAQmx Start Task.vi, see attached pic. Seems reasonable by the explanation in the link but strange that it is not followed by some of the vi's that I've received and which I can't change.
Solved! Go to Solution.
Well, there are several things to consider here. Not all DLLs are the same under the LabVIEW ecoverse. Generally Standard C is completely unmanaged (to use a term quite familiar to many since .Net). That means nobody is holding the programmers hand when performing memory allocations or deallocation, or passing parameters from one component to the other. If the function expects a buffer to write into, and the caller has forgotten to allocate that buffer or allocated it even one byte smaller than the function wants to write into, VERY BAD things can and usually will happen.
In managed environments there are specific contracts that callers and calles have to fullfill. That goes about who has to allocate memory, and just as importantly with what memory allocator, and quite a few other things. .Net has one specific way of managed contract, but LabVIEW has that too, albeit not the same as .Net.
With an external DLL you can have a DLL that is simply written by a C programmer and has its own way of management (usually non, which means the caller is always responsible to allocate any possble buffer that it passes to a callee). But you can also write a DLL that is fully aware of the LabVIEW managed paradigma and knows how to resize any buffer that is passed into it in a way that is compatible with LabVIEW. These DLLs are linked to the labview.lib import file and make use of very specific LabVIEW manager functions that are exported by the LabVIEW executable. By using these LabVIEW manager functions in a very specific way, the DLL can be made to directly deal with the native LabVIEW datatypes in a way, that won't cause LabVIEW to go belly up after the function returns control back to LabVIEW. It is not surprising that NI uses in its own LabVIEW support DLLs exactly these techniques. That has certain performance advantages since LabVIEW does not have to convert its native datatypes into standard C datatypes with a fixed (and potentially way to big data buffer just in case the function may feel tempted to return a megabyte long String in the case of a special condition).
The disadvantage of such a DLL is that it is only callable from a LabVIEW VI and nothing else, since no other programming environment knows about LabVIEW native datatypes and consequently won't provide any LabVIEW manager functions that the DLL could link to on load. Because of this there are very few non-NI programmers who go to the hassle to write DLLs that make directly use of LabVIEW native datatypes for its function parameters.
With normal DLLs not specifically written for LabVIEW, the original comment in your link holds fully true.