Why no Highlight Execution dots on Call Library Parameters?

[JohnA]

In trying to determine why a Call Library invocation of a function in a DLL crashes, I have turned on Highlight Execution and placed a breakpoint on the Call Library block. Prior to calling the DLL, many of the parameters have colored dots placed on their input sides, but some do not (all inputs are wired). What does this mean? Also, are there any restrictions on the use of both the input and output connections of a parameter that is passed by pointer? All of the parameter types, sizes, and values appear to be correct, but calling the function in the DLL causes an illegal memory access.

[Wiebe@CARYA]

Hi,

If you get an illegal memory access, you probably have to make one or more
inputs a pointer. A pointer to a value is passed to a routine if the routine
has to change it. So, if a parameter needs a pointer to a value, it needs an
input (all parameters need an input) and the output has the new value.

If you tell us the prototype of the function (or even a function name), we
should be able to tell you how to call it from LabVIEW.

Regards,

Wiebe.


"JohnA" wrote in message
news:506500000008000000C5B20000-1068850981000@exchange.ni.com...
> In trying to determine why a Call Library invocation of a function in
> a DLL crashes, I have turned on Highlight Execution and placed a
> breakpoint on the Call Library block. Prior to calling the DLL, many
>
of the parameters have colored dots placed on their input sides, but
> some do not (all inputs are wired). What does this mean? Also, are
> there any restrictions on the use of both the input and output
> connections of a parameter that is passed by pointer? All of the
> parameter types, sizes, and values appear to be correct, but calling
> the function in the DLL causes an illegal memory access.

[JohnA]

Wiebe,

The function prototype from the vendor's .h file is:

EXPORT32 long FAR EXPORT rzrfit(float FAR *,long,long,float FAR *,long,long,float FAR *,float FAR *,float FAR *,float FAR *,
long FAR *,long FAR *,long FAR *,float FAR datmat[][40],float FAR *,float FAR *,long FAR *,float FAR *,long);

and the code generated after configuring Call Library is:

long rzrfit(float ydata[], long n2, long m, float shape[], long nl2, long ml,
float yout[], float vnoise[], float baslin[], float w[], long *n,
long *ifast, long *istat, float datmat[], float covar[], float hess[],
long iwork[], float work[], long mmax);

If rzrfit modifies a value through a pointer, I have wired both the input and output parameters in Call Library. Is this correct?

Tha
nks,
John

[Jeremy Braden]

If one of the parameters returns an array, you may need to pass an array of the same size (or larger) to the left input terminal of the call library node. This creates dataspace to store the new array so the dll can modify it for the output terminal.

[Greg_McKaskle2]

> EXPORT32 long FAR EXPORT rzrfit(float FAR *,long,long,float FAR
> *,long,long,float FAR *,float FAR *,float FAR *,float FAR *,
> long FAR *,long FAR *,long FAR *,float FAR datmat[][40],float
> FAR *,float FAR *,long FAR *,float FAR *,long);
>
> and the code generated after configuring Call Library is:
>
> long rzrfit(float ydata[], long n2, long m, float shape[], long nl2,
> long ml,
> float yout[], float vnoise[], float baslin[], float w[], long
> *n,
> long *ifast, long *istat, float datmat[], float covar[], float
> hess[],
> long iwork[], float work[], long mmax);
>

That's a lot of parameters. As the other response pointed out, you need
to be aware of any sizing assumptions the call makes. Sometimes these
functions expect y
ou to make a first call to learn the sizes of the
parameters, then size your arrays, then make a second call passing in
the sized arrays. Other times, the size is agreed upon in the
interface, and both sides just know that it is 256 elements or such.

Be especially careful about the datmat parameter as not only do you need
to get the buffer sized correctly, but you need to get the shape
correct, and you may even need to transpose it.

Greg McKaskle

[JohnA]

OK, here's my understanding of what goes on when an array is passed by pointer reference, with array "A" wired to the input terminal and array "B" wired to the output: "A" is copied to a temporary array. A pointer to the temporary is passed to the library function. The library function can read or write values by referencing the pointer. When the library function returns, LabVIEW copies the temporary into array "B". Is that right? Also, does LabView care if array "A" is a control, indicator, or local variable?

Thanks,
John

[Greg_McKaskle2]

....
> array "B" wired to the output: "A" is copied to a temporary array. A
> pointer to the temporary is passed to the library function. The
> library function can read or write values by referencing the pointer.
> When the library function returns, LabVIEW copies the temporary into
> array "B". Is that right? Also, does LabView care if array "A" is a
> control, indicator, or local variable?

Your description is the way it works in pretty much the worst case. The
input signal to the DLL may be needed by another node, or it may need to
be protected, a constant is a good example of something that can't be
written on since the next run needs the value again. But in a good
number of cases, the input A is no longer need
ed by anyone, and a
pointer into A is passed into the DLL. The DLL can legally write
anywhere within A, but it can't grow or shrink it as it didn't allocate
it and has no way to return the new pointer if it has to be moved.

Upon return, the output is already in a buffer, and that signal can
usually point to A or to the temporary passed in.

So, in the best case, there is one buffer. In some cases there are two,
and in a few rare cases where the DLL node is followed by a special
node, I suppose there could be three, but this is the rarity.

Greg McKaskle