LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Dataflow Anomaly

Solved!
Go to solution

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



Certified LabVIEW Architect

G# - Award winning reference based OOP for LV, for free! VIPM Github
0 Kudos
Message 11 of 29
(491 Views)

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?

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 12 of 29
(462 Views)

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.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 13 of 29
(450 Views)

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

0 Kudos
Message 14 of 29
(427 Views)

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

aputman
LabVIEW 2017
LabVIEW Programming
0 Kudos
Message 15 of 29
(404 Views)

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

0 Kudos
Message 16 of 29
(397 Views)
Highlighted
Solution
Accepted by topic author Frozen
06-14-2019 06:48 AM

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

Message 17 of 29
(385 Views)

That is some amazing insight.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 18 of 29
(377 Views)

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

We can all breath easier now Smiley Very Happy

0 Kudos
Message 19 of 29
(304 Views)

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

Captured001.png

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

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 20 of 29
(289 Views)