Dataflow Anomaly

[thols]

---

@aputman wrote:

---

@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.  

---

You're right. I had missed to turn concatenation on after removed and added the loop. Now I can reproduce it from scratch (had missed concatenating). That behavior is really weird. What does concatenation have to do with it...

[paul_cardinale]

I wouldn't worry about it.  My guess is that the timestamp is when the probe receives the data, which would be a little later than the time when data arrives in the wire.  Do you really care about that small difference?

[billko]

I suppose it could set up some kind of unexpected race condition.

A rare case when the code isn't doing what you told it to do.

[mcduff]

Just a guess here. Is it a compilation error or a debugging probe error?

It appears the compilation is correct because the code is behaving correctly; however, the debugging tools seem to indicate an error that does not show up in the running code.

mcduff

[aputman]

---

@mcduff wrote:

Just a guess here. Is it a compilation error or a debugging probe error?

It appears the compilation is correct because the code is behaving correctly; however, the debugging tools seem to indicate an error that does not show up in the running code.

mcduff

---

If you step thru the code with an empty path, error # 1430 will appear after the File Open.  Execution immediately skips to the File Close (function flashes during HE mode).  Then execution goes back to the for loop.  This is incorrect code behavior.  The error out terminal actually gets updated before the for loop is completed.  Yes, you end up with the same outcome in this situation but that may not always be the case.

I replaced the File functions with Config File functions and do not get the same anomaly.

I then replaced them with TDMS functions and also do not get the same anomaly.

It seems to only occur with File functions and concatenate tunnels.  

[mcduff]

---

@aputman wrote:

---

@mcduff wrote:

Just a guess here. Is it a compilation error or a debugging probe error?

It appears the compilation is correct because the code is behaving correctly; however, the debugging tools seem to indicate an error that does not show up in the running code.

mcduff

---

If you step thru the code with an empty path, error # 1430 will appear after the File Open.  Execution immediately skips to the File Close (function flashes during HE mode).  Then execution goes back to the for loop.  This is incorrect code behavior.  The error out terminal actually gets updated before the for loop is completed.  Yes, you end up with the same outcome in this situation but that may not always be the case.

I replaced the File functions with Config File functions and do not get the same anomaly.

I then replaced them with TDMS functions and also do not get the same anomaly.

It seems to only occur with File functions and concatenate tunnels.  

---

In LabVIEW 2018 with execution highlighting on (empty File Path), I do not see a step over of the for loop, but I do see the error out from the File Close being updated first, that is, before the error in of the file close vi. But it seems like a bug.

mcduff

EDIT: The only unexpected behavior shown so far is the debugging, as far as I can tell the compiled code ran correctly, so it is a weird case.

[BoKnows · Accepted solution]

---

@aputman wrote:

---

@mcduff wrote:

Just a guess here. Is it a compilation error or a debugging probe error?

It appears the compilation is correct because the code is behaving correctly; however, the debugging tools seem to indicate an error that does not show up in the running code.

---

If you step thru the code with an empty path, error # 1430 will appear after the File Open.  Execution immediately skips to the File Close (function flashes during HE mode).  Then execution goes back to the for loop.  This is incorrect code behavior.  The error out terminal actually gets updated before the for loop is completed.  Yes, you end up with the same outcome in this situation but that may not always be the case.

---

mcduff was actually correct.  I'll do my best to explain in a way meant to hit a wide audience here.

When you're using debugging tools (highlight execution, probes, etc) you're adding extra functionality to your source code.  There has to be code to perform those tasks.  With a graphical language, you create an interesting scenario where you've got a set of code specifically designed to trigger and draw events to help show the user what's going on.  For the sake of this explanation, let's call those debugging visualizations (DVs for short).  

Ideally, DVs would take place at the exact same time as the code itself.  Being practical, they create an extra place for erroneous behavior.  In addition to there being potential for a bug in the code itself.  There's also potential for an erroneous translation between the functional code and the way the DVs are being triggered.

In this instance, it appears the code is actually functioning as desired.  The code runs in the order you'd expect dataflow to handle it.  There's a flaw in the way the DVs are handling the order and that's showing you something that wouldn't make sense.  As a result, the DV that we'd expect to see on the first wire is instead being sent to the output wire.  You can use stepping, highlight execution, or probes (as a variety of folks have pointed out) to see this odd DV behavior.  Though, it's less terrifying than it initially appears as the actions themselves are taking place in the correct order. 

I haven't been able to figure out what is special about the concatenating output mixed with the file I/O to cause this oddity.  But, that's the reason for the strange visual behavior.

[billko]

That is some amazing insight.

[Frozen]

I thought as much. It is just a visualization bug (as I stated in my OP)

We can all breath easier now

[paul_cardinale]

I don't even see it as a bug.  Here's how I see it:

From a data flow perspective, I wouldn't expect probes 1 & 2 to be synchronized.