LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Make sure that you wire all inputs and outputs of your Call Library Function Node?

Solved!
Go to solution

This document says "Make sure that you wire all inputs and outputs of your Call Library Function Node"

 

http://digital.ni.com/public.nsf/websearch/7253D2F0D91F68058625752F005AB672?opendocument&Submitted&&...

 

But are all the terminals on the right side of the call-library node considered to be the "outputs" to which the foregoing statement refers?

This same document goes on to show the proper way to allocate memory space with this illustration and in the illustration the right-side "outputs" are left without any connections.

 

Clipboard01.png

 

Am I correct in assuming that the only terminals that count as outputs, the ones which the DLL code will use (write to) as outputs?  If true, then all other output terminals associated with input-only values therefore do not really count as outputs, correct?

 

Within the call-library parameter configuration screen there is a "Constant" checkbox and the help for it says "Indicates whether the parameter is a constant."  What does checking this box do for me in the setup of the DLL call?

 

Finally, assuming a DLL call which expects to write to these five outputs, is it legitimate to use constants like this to reserve memory space for the output values?

Clipboard02.png

How about if local variables associated with the output terminals are used instead?

Clipboard03.png

 

 

 

0 Kudos
Message 1 of 5
(3,313 Views)
Solution
Accepted by topic author WNM

Despite the linked document, it's no longer necessary to wire the corresponding input for simple scalar output parameters (such as a numeric). LabVIEW will automatically allocate memory for them. If you do want to wire the inputs for all the outputs anyway, there shouldn't be any difference between using a constant and a local variable; I'd use a constant to avoid unnecessary local variables.

 

For parameters that are only inputs, there's no need to wire the output side. This is a bit of an oversimplification since all parameters are input-only, and to get an output (other than the return value) you pass a memory address and modify the contents at that address, but LabVIEW handles this pointer dereferencing for you. If you really want to get into the details, learn about pointers in C.

 

The "Constant" checkbox acts like the "const" qualifier on a function parameter in C. It tells the compiler that the function you're calling won't modify that parameter. If you are calling a function whose prototype includes a const parameter, then you should mark that parameter as a constant when you set up the Call Library Function Node. Otherwise I wouldn't worry about it.

Message 2 of 5
(3,288 Views)

@nathand wrote:

Despite the linked document, it's no longer necessary to wire the corresponding input for simple scalar output parameters (such as a numeric). LabVIEW will automatically allocate memory for them.

 

    :

 

The "Constant" checkbox acts like the "const" qualifier on a function parameter in C. It tells the compiler that the function you're calling won't modify that parameter.


If it is "no longer necessary"  then do you know with which version of LabVIEW it ceased to be necessary?  I would suppose that a constant value should as good practice be included on the input side anyway if there is a chance that "save for previous version" will ever be used.

 

I know about the "const" qualifier on the "C" side of things but do you have any idea what it means on the LabVIEW side of the call? I can see that it would feed into the right-click context menu option to "Create C file" but will it impact how LabVIEW handles a call to an already-existing DLL function? What might break if it is marked wrong in setting up a call to an existing DLL function?

 

Thanks for taking the time to offer an answer!

0 Kudos
Message 3 of 5
(3,278 Views)

@WNM wrote:

If it is "no longer necessary"  then do you know with which version of LabVIEW it ceased to be necessary?  I would suppose that a constant value should as good practice be included on the input side anyway if there is a chance that "save for previous version" will ever be used.


No idea, I'm just paraphrasing RolfK here (http://forums.ni.com/t5/LabVIEW/Resetting-a-pointer-in-DLL-node/m-p/2941964#M849595). I've been leaving inputs unwired in DLL calls for years without problems, and I don't ever remember seeing a post here about a DLL call that was solved by adding such a constant.


@WNM wrote:

I know about the "const" qualifier on the "C" side of things but do you have any idea what it means on the LabVIEW side of the call? I can see that it would feed into the right-click context menu option to "Create C file" but will it impact how LabVIEW handles a call to an already-existing DLL function? What might break if it is marked wrong in setting up a call to an existing DLL function?


Nothing will break, you just might lose out on some optimization, although I have no idea if LabVIEW actually attempts any optimization based on whether a parameter is marked as constant. If you mark a parameter as constant and it isn't, possibly LabVIEW could generate an error when the DLL tries to modify the value that's supposed to be constant, or you could get unexpected data somewhere, but I think this is unlikely.

Message 4 of 5
(3,270 Views)
Solution
Accepted by topic author WNM

WNM wrote:

 

If it is "no longer necessary"  then do you know with which version of LabVIEW it ceased to be necessary?  I would suppose that a constant value should as good practice be included on the input side anyway if there is a chance that "save for previous version" will ever be used.

I personally prefer to be explicit and use constants most of the times, even if it isn't strictly necessary anymore. Not sure when that requirement was removed but I guess it is somewhere around LabVIEW 7.x or 8.0


nathand wrote:

Nothing will break, you just might lose out on some optimization, although I have no idea if LabVIEW actually attempts any optimization based on whether a parameter is marked as constant. If you mark a parameter as constant and it isn't, possibly LabVIEW could generate an error when the DLL tries to modify the value that's supposed to be constant, or you could get unexpected data somewhere, but I think this is unlikely.

Actually yes, LabVIEW does use that information. The scheduling of code when you branch wires for instance uses this information to decide if there should be a copy or if rescheduling the code such that the "read-only" consumers are executed first is enough. If your wire isn't branched it shouldn't make a difference, but if you have branches LabVIEW has to allocate a new copy of the variable for each consumer for which it can't know if it will modify the value. Obviously skalar parameters passed by value are by definition const parameters so I'm sure LabVIEW will deduce that anyways for such parameters, but for parameters passed by reference and especially strings and arrays, this can make a significant difference in performance.

Rolf Kalbermatter
My Blog
Message 5 of 5
(3,239 Views)