From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
03-09-2015 11:07 AM
Hello,
I encountered following strange behavior: when run in LabVIEW development, following error ring does its expected job as it also acts as a control flow control so that the reference is not destroyed before the loop terminates (see picture).
Strangely, when I build an executable and execute the VI via run-time, I the reference is destroyed WHILE the loop is still running. As if the error ring was not compiled into the executable.
Is it a LV bug?
Thanks,
Peter
03-09-2015 11:24 AM
While it might be possible that this is the case (the ring is an XNode and I suppose it is theoretically possible that there are some holes in that department), I would say it doesn't seem to be likely for something as basic as this. I would suggest making sure (e.g. by adding logging to see whether the loop is still running, whether the code to destroy the DVR was actually called, etc.). You could also try replacing the ring with a constant or a clear errors VI.
Other alternative explanations would be that you destroy the DVR elsewhere, that the DVR isn't destroyed and you're misinterpreting the behavior or that the DVR is destroyed automatically because the hierarchy it was created in has gone idle.
03-09-2015 11:35 AM
I see you are already passing out another error cluster from the loop. Why not use that error cluster? The Destroy DVR function will still work if there is an error (or so the help file for it claims).
03-10-2015 07:22 AM
I managed to reproduce the problem in LabVIEW development if I disable debugging for this VI.
It seems to me that the compiler moves this part of the code outside the loop as static content. In this case, I would consider it as a bug, as the compiler shouldn't change the semantic of the program.
What do you think?
03-10-2015 08:12 AM
@Bokor wrote:
I managed to reproduce the problem in LabVIEW development if I disable debugging for this VI.
It seems to me that the compiler moves this part of the code outside the loop as static content. In this case, I would consider it as a bug, as the compiler shouldn't change the semantic of the program.
What do you think?
I don't see this as a bug. There are some in LabVIEW R&D that say that using the error wire to force a data dependency is a hack.
I still go back to the fact that you should just be using your other error wire or wire your DVRs through your loop.
03-10-2015 08:37 AM
@crossrulz wrote:
I don't see this as a bug.
I would. Hack or not, the paradigm we rely on is that wires determine execution order and I'm not aware of any change that NI made to that rule (notable kind-of-exceptions - inputs into later frames of a flat sequence not affecting the earlier frames and iteration order in a parallel loop, but tha's not really wires).
That said, we would need to see some actual code demonstrating the behavior.
03-10-2015 09:22 AM
Here you go (LabVIEW version 2014).
Just by enabling/disabling debugging for main.vi can you switch between "I'm alive" (valid DVR) and "Dereference error" (destroyed DVR).
There may be different views whether or not it's a bug (I tend to agree that it is), but at least it should be documented..
03-10-2015 02:44 PM
I agree that it looks like a bug and I'll report it.
Also, here's a simpler version of the behavior (2013).
03-10-2015 03:34 PM
I agree that this is a bug with a capital 'BUG'.
It is a compiler optimization run amok.
Any node which ignores input errors (Release Queue, Close Reference, etc.) will do the trick.
The error ring is also fungible. Create a Diagram Disable structure with an error output (use a constant if you want) wired in the disable case. In the enabled case simply use the tunnel with the 'Use Default if Unwired' option.
Snippet mangled the simpled 'This VI constant, but this also shows the bug.
03-10-2015 03:40 PM
And the error ring has nothing to do with it really. But lets look at what we did that is a bit odd
Dropping back to the concept here
Shows how to correctly use the DVR functions thusly:
Go read it yourself and compare to the simplified example attached above.
Finally Modifying the example to:
CURES the unexpected behavior!
DVR Write DVR output unwired should probably have thrown at least a compiler warning.
I'm fairly certain that one should not wire a DVR Ref Around a parallel DVR Access that may modify the data (Something scares me there).
So Bug? Yes, I think the behavior is not as intended. Workaroud? Don't wire a DVR Ref around a parallel DVR Access that may modify the data