Dataflow Anomaly

[Frozen]

Give that "A block diagram node executes when it receives all required inputs" (from Dataflow Programming basics), help me understand why probe 2 executes before probe 1.

Note: removing the concatenate option "fixes" the dataflow so that probe 1 executes before probe 2.

I am assuming this is just a visual anomaly since dataflow is so fundamental to LabVIEW.

[altenbach]

I would even be wondering why there is a 10 ms difference between the two. 😉

What do you see with execution highlighting?

Just wildly guessing a "close file" is somewhat special in that it executes independent of any incoming error condition. Is it possible that the compiler inlines the close operation for some interesting side effects.

... or maybe it's just a bug. 😉

It would help if you could provide more details (e.g. LabVIEW version, etc.) and attach the sample code so we can test. Thanks!

[Frozen]

Sorry, forgot to include that I tried it with 2016 and 2018. I have attached the 2016 version for reference (it is easily enough reproduced)

As mentioned, replacing the "concatenate array" tunnel will "fix" the dataflow problem.

It was with execution highlighting ON that I noticed the problem (as well as stretching out the functions to see it actually happening)

[altenbach]

Thanks. I see the same in LabVIEW 2019. Curious!

[RTSLVU]

What's even more interesting and concerning is that the Close executes BEFORE it even get the reference!

This has to be a visual and timing bug of some sort, otherwise the Close would error out due to a bad or missing reference.

Proce 2 executes before probe 1 or 3?

[Frozen]

Yeah... that is sorta what I was pointing out. The close function is executing before receiving any of the inputs to the function which is contrary to the dataflow principle.

[aputman]

You can see it clearly in Highlight Execution mode.  Looking at the Help for Close File function, it says that Error I/O operates uniquely in this function. Still doesn't make sense why it violates dataflow. 

[thols]

Remove and replace the for loop. Then everything is back to normal. Must be some compile bug. I cannot reproduce it.

[aputman]

---

@thols wrote:

Remove and replace the for loop. Then everything is back to normal. Must be some compile bug. I cannot reproduce it.

---

This doesn't work for me.  Did you turn on the concatenation tunnel for the string array?  This seems to be the cause of the compile bug.  I replaced the for loop with a while loop and the issue still persists...until I turn off concatenation.  

[Frozen]

As per original post, it is the concatenation of arrays that breaks things.