Leaderboard

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

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