Dataflow Quirk?

[Mechatroner]

Hi.

I’ve discovered what appears to me to be a quirk in the behavior of dataflow in LabVIEW.  This discovery occurred while working on an application that contains a main while loop and housekeeping code that runs after the main while loop.  I’m enforcing the order of execution in the VI by wiring the error cluster through the main while loop and over to the housekeeping code.

Attached is a zip file containing a VI that reduces the application to its key components.  The VI contains two while loops connected by an error cluster.  The cluster passes through a subvi and sequence structure in the first loop, then passes through the second while loop and finally enters another subvi.  A screenshot of the VI block diagram is also attached.

When the VI execution property “Allow debugging” is selected, the VI operates as expected - the second loop will not start until the first loop stops.  The quirk occurs when “Allow debugging” is de-selected.  In this case, both loops begin running as soon as the VI starts!

For some reason, the two subvis and the sequence structure are required to make this phenomenon occur.  This phenomenon also occurs when the sequence structure is replaced with a conditional disable structure.

This behavior occurs in at least the following two environments:
1) LabVIEW 2014 32-bit on Windows 8.1 running within Parallels Desktop 11 for Mac
2) LabVIEW 2015 SP1 32-bit on Windows 10 

I suspect that the cause of this behavior is that the LabVIEW compiler is trying to optimize the VI performance by noticing that the second loop and second subvi are not dependent on any data generated in the first while loop.  If this is the case, it’s great that the compiler is trying to improve VI performance; however, what’s not so great is i) this demo VI shows that the error cluster does not always enforce order of execution, and ii) a change in the "Allow debugging" setting can change the behavior of a VI without any indication to the developer.

This apparent quirk raises two questions:
- Are there other situations where the dataflow paradigm does not behave as expected?
- Are there any tools available to find out about changes that LabVIEW implements behind the scenes that could cause this or other unexpected behaviors?

A short video demonstrating this issue is available here:  http://www.screencast.com/t/D3mCCqFyz

Any thoughts on this issue would be much appreciated.

-John Bergmans

Data Flow Test.zip_remove_me

[hooovahh]

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.

[smithd]

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 November 11, 2016 by smithd

[Dirk De Mol]

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 :-)

[jacobson]

Super strange, I notified one of our LV PSEs and filed CAR 614644.

[Mechatroner]

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 November 11, 2016 by Mechatroner
Fixed typo