Jump to content

Recommended Posts

Confirmed the behavior in LabVIEW 2015 SP1 f3 and LabVIEW 2016.  An easy fix for this is to just add the Always Copy function on the error wire between loops.  But clearly this should be fixed since you can't always know when that is needed until an issue occurs.

Share this post


Link to post
Share on other sites

I dunno if you saw this, but if you move sub2 into the 2nd loop it actually does the right thing. Also, if you return to the original state and put a breakpt in sub2 (like just wire it to a case structure) then both loops will start but you hit the breakpoint after stopping loop 1 but while loop 2 is still running (ie putting code in sub2 doesn't fix the issue, but moving the basically code-free sub2 into the loop fixes it).

 

Kind of concerning since I've seen people do this for dialogs (I confirmed it also fails for event structures).

Edited by smithd

Share this post


Link to post
Share on other sites

Confirmed the behavior in LabVIEW 2016 on Mac.

Oh, it gets weirder... If you change the error constant so it has some values in it, you'll see that Sub2 runs and gets the correct value in its error control, as soon as you stop loop 1. Then loop 2 is still running but Sub2 already has executed! You can also fix the problem by just branching off the error wire between the two loops and connecting the wire to the second loop.

What seems to be happening is that the optimizer removes the error wire in the second loop as it is not needed there (and without debugging cannot be clicked on to set a probe) and connects the error wire around the second loop to sub2.

I don't see any justification for this behavior. LabVIEW users are taught and conditioned to use the error wire as an artificial dataflow to force execution order.

 

This reminds me a bit about the change in behavior of the For loop, many years ago. It used to be that if you wire something through the For loop (like the error cluster in the while loops here), the outgoing value was always the same as the incoming value. Made sense. But in LV 6 it was changed such that if the For loop counter was set to 0, all output values changed to "default", even the ones that were just wired through. This caused some of our system to behave strangely (I was a customer then). This behavior change was made without any warning and we were the victim. Our system at the time already consisted of around 20000 VIs and we had to find every For loop in the system where this could happen. Luckily NI really helped us out at the time and they gave us a utility that scanned the whole system. I guess that was a forerunner of scripting :-)

Share this post


Link to post
Share on other sites

hooovah, smithd and Dirk - Thanks to each of you for looking this over.  

I've also repeated this behavior when the error cluster is replaced with a boolean in LabVIEW 2014 32-bit on Windows 8.1   This suggests that the issue is not related to the use of the error cluster but is more of a compiler problem.

2 hours ago, Dirk De Mol said:

What seems to be happening is that the optimizer removes the error wire in the second loop as it is not needed there (and without debugging cannot be clicked on to set a probe) and connects the error wire around the second loop to sub2.

Dirk - I think the optimizer must be making the same decision in the first while loop.  Another oddity is that in my actual application, the error cluster passes through several real VIs in the equivalent of the demo VI Loop 1.

2 hours ago, Dirk De Mol said:

I don't see any justification for this behavior. LabVIEW users are taught and conditioned to use the error wire as an artificial dataflow to force execution order.

I completely agree.  Even though there are easy workarounds to this issue, the idea that dataflow seems to not define execution order 100% of the time is a bit disturbing to me.

As Dirk suggested to me off-line, I will submit a bug report to NI.  I'll post any updates on this issue here.

EDIT - jacobson beat me to submitting the bug report.  Thanks for your help and prompt attention to this matter jacobson.

-John Bergmans

 

Edited by Mechatroner
Fixed typo

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.