LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Compiler is Too Smart for My Own Good

Solved!
Go to solution

@Dataflow_G wrote:

The code in the first post isn't correctly wired. I downloaded the snippet... only to discover the reference wire out of the case structure is NOT connected to the FP.Close VI method. It simply passes behind it... a good reason to use VI Analyzer!


VI Analyzer is one way to go.

Another would be something more structured:

 

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Save-us-from-ourselves/idi-p/1518518

 

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/LabVIEW-should-break-VIs-which-have-hidden-code/idi-p...

 

Warning: the second idea is a bit of rabbit hole of comments and related ideas.


___________________
Try to take over the world!
0 Kudos
Message 51 of 55
(1,143 Views)

@Dataflow_G wrote:

The code in the first post isn't correctly wired. I downloaded the snippet and tried to reproduce the error, only to discover the reference wire out of the case structure is NOT connected to the FP.Close VI method. It simply passes behind it and straight into Close Reference. So FP.Close runs in parallel and can execute at any time, in classic LabVIEW race condition style.

 

So this thankfully isn't a LabVIEW bug. And is a good reason to use VI Analyzer!


That's a relief. But what does the willingness to entertain the idea of such a bug tell us?

0 Kudos
Message 52 of 55
(1,134 Views)

@Dataflow_G wrote:

The code in the first post isn't correctly wired. I downloaded the snippet and tried to reproduce the error, only to discover the reference wire out of the case structure is NOT connected to the FP.Close VI method. It simply passes behind it and straight into Close Reference. So FP.Close runs in parallel and can execute at any time, in classic LabVIEW race condition style.

 

So this thankfully isn't a LabVIEW bug. And is a good reason to use VI Analyzer!


That was immediately my first thought when I saw the post, but being on vacation and without access to a computer that had LabVIEW installed I could not verify it. I have been to often bitten by such bugs to not automatically have this muscle memory: Select the wire, nudge it a few pixels and see where the bends occur. If they don't occur about halfway of the two nearest connection points, the wire is not wired as it appears to be.

This of course assumes that LabVIEW 2021 auto wiring is not present 😀

 

But the many affirmative and upset posts really started to make me doubt my theory. It couldn't be possible that no-one tried the obvious, could it?

Rolf Kalbermatter
My Blog
0 Kudos
Message 53 of 55
(1,112 Views)

@crossrulz wrote:

@paul_cardinale wrote:

@crossrulz wrote:

@billko wrote:

So you're trying to be cute (but also correct) by wiring the reference through the case structure to create an "artificial" dataflow dependency, and the compiler outsmarts you by compiling as if you had the reference wire outside the case structure.  So how did you fix it?  Error cluster inside the case structure going to error in on front panel close?


Synchronize Data Flow.vim could be used (one input being the panel reference, another being the error).


That should be a growable XNode.


Many would agree with you.

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/The-quot-Zero-Frame-Flat-Sequence-quot-aka-quot-Synch... 


Here.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 54 of 55
(1,072 Views)

@Intaris wrote:

But what does the willingness to entertain the idea of such a bug tell us?

Well, if memory serves, there was exactly that kind of bug (code placed after a structure executes independently of it) reported in the forums some years ago, so it's not impossible. I'm fairly sure back then it was an actual compiler optimization bug, but I really don't feel like trying to look it up now, so in theory it's possible it was also something like what we have here.


___________________
Try to take over the world!
Message 55 of 55
(1,033 Views)