[BUG]: Dll modifies input array constant

[Wiebe@CARYA]

Hi,

Not really an important one, but some of you (Ben 😉 might like it... Tested
in LV6, 6.1, 7.0 and 7.1.

When a dll function modifies more (1d or 2d) input arrays, one constant is
used to initialize them and less then all indicators are wired, LV
overwrites the constant values...

To reproduce this, I created a two dlls (one in assembler and one in
LabVIEW, assembler one is attached). The dll fills the array with the number
2.

Run the VI, update the diagram (close and open again, or scroll). The values
in the constant array now have the same values as the output array!

This behavior is reproducible with (at least) 1d and 2d arrays, and (at
least) U32 and DBLs.

I'm sure other array data types (SGL, U8, I8 etc.) s
how the same behavior,
but pointers to scalar values do not. Perhaps strings also do this?

Try putting a flat sequence frame around it, and put a few seconds wait
before and after it. You can see the constant changing while the vi is
running.

Regards,

Wiebe.



[Attachment Callbug.dll, see below]


[Attachment Callbug.vi, see below]

[Ben]

Hi Wiebe

Your question reminds me of a phrase from proverbs

"A wise man goes into his store house and brings forth treasures both old and new".

I was not able to find documentaion on the the call library function that talks about this issue but I did find the following in the "LabVIEW Advanced 1 Course Manual, August 1998 Edition, part number 321366C-01 page 242".

"If you do not wire an indicator to the output terminal of a terminal pair, LabVIEW assumes that the CIN will not modify the value you pass to it. If another node uses the input data, LabVIEW does not make a copy of the data.

Note: If you don't wire the output terminal, the source code should not modify the value passed into the terminal. Nodes connected to the input terminal wire may recei
ve the modified data.
"

This topic brought our class to a stand still when we(those who were still awake) realized that data could flow backwards through a wire!

I believe the behaviour you have observed is correct and the quote I cited above.

I will venture a guess that the requirement from the CLA exam
"CLD-VPP-03-04 ...Review a LabVIEW application for run-time behavoiur and memory management issue, ....Destructive and non-destructive buffer reads on branched wires"

had the behaviour in mind.

I posted a Q re:this req years ago but never got a definative answer.

All of the above is just my opinion.

I would love to hear from others.

What do you think?

Ben

BTW: I do not think they teach that anymore.

[Wiebe@CARYA]

Ben,

The topic from the advanced course does seem to be describing this. So this
behavior doesn't seem to be a bug. I couldn't find anything about this in
the "Using External Code in LabVIEW" manual.

When pointers to values are used, the constants are not updated, so that is
inconsistent, but it does say "may receive", so that is covered...

Perhaps the only bug is the fact that the block diagram is not refreshed
properly, after the values are changed... Just kidding...

Next question is how to make use of this?

Regards,

Wiebe.


"Ben" wrote in message
news:50650000000500000078D30100-1079395200000@exchange.ni.com...
> Hi Wiebe
>
> Your question reminds me of a phrase from proverbs
>
> "A wise man goes into his store house and brings forth treasures both
> old and new".
>
> I was not able to find documentaion on the the call library function
> that talks about this issue but I did find the following in the
> "LabVIEW Advanced 1 Course Manual, August 1998 Edition, part number
> 321366C-01 page 242".
>
> "If you do not wire an indicator to the output terminal of a terminal
> pair, LabVIEW assumes that the CIN will not modify the value you pass
> to it. If another node uses the input data, LabVIEW does not make a
> copy of the data.
>
> Note: If you don't wire the output terminal, the source code should
> not modify the value passed into the terminal. Nodes connected to the
> input terminal wire may receive the modified data.
> "
>
> This topic brought our class to a stand still when we(those who were
> still awake) realized that data could flow backwards through a wire!
>
> I believe the behaviour you have observed is correct and the quote I
> cited above.
>
> I will venture a guess that the requirement from the CLA exam
> "CLD-VPP-03-04 ...Review a LabVIEW application for run-time behavoiur
> and memory management issue, ....Destructive and non-destructive
> buffer reads on branched wires"
>
> had the behaviour in mind.
>
> I posted a Q re:this req years ago but never got a definative answer.
>
> All of the above is just my opinion.
>
> I would love to hear from others.
>
> What do you think?
>
> Ben
>
> BTW: I do not think they teach that anymore.