Should a shift register output data prior to loop execution

[Randall_T]

This is probably not considered a bug but the behavior surprised me.  I have only tried this with 2015 32 bit.

 I recently noticed the register was being read and data was flowing prior to the loop executing.  While debugging an application I placed a breakpoint on a wire exiting a loop to allow me to stop the program prior to the rest of the program executing. primarily this would leave the application open so I could edit the program as needed or so I thought.

I have created a sample program that show what I am talking about.  If this works as it does on my system you can select highlight execution and the program pauses for the breakpoint on startup.  Hitting the stop button will queue data to the lower loop data will flow past the breakpoint without breaking.

It appears the same wire has data flow twice. However wire a branch of the wire to a terminal rather than a border the breakpoint works as expected. Data is not read at the terminal and code does not execute beyond that point. In the end this doesn't create a problem unless you happen to be depending on the program to stop after the loop finishes execution.

For instance. Clear the breakpoint and save the program.  Start the program then place a breakpoint on the wire at the same location as in this example. Hit the stop  the program will not pause, restart the program it pauses on start.

[Gregory]

Can you post a snippet or LV 2014?

[tst]

---

@Randall_T wrote:

This is probably not considered a bug but the behavior surprised me.

---

I would consider it a bug. While data doesn't flow through the wire at the start (you can place a probe to see that), the breakpoint behavior does seem incorrect, and the fact that it changes when you change the wiring indicates that too.

[Bob_Schor]

Here's a Snippet --

I think it's a bug in the Breakpoint Manager figuring out when to stop execution.  As amazing as it was to see the Breakpoint "fire" before the second loop ran, it was even more amazing to do the second test, moving the nested Case outside and seeing that it "fixed" the bug.  Incidentally, if you remove the Breakpoint and replace it with a Probe, you can easily see that the Probe doesn't get a value until the lower loop exits.

NI -- He Found A Bug!!

Bob Schor

[Bob_Schor]

The same thing happens in LabVIEW 2014 (and, no, I'm not prepared to test all the way back to LabVIEW 7 ...).  I've attached the 2014 version ...

Bob Schor

[Gregory]

I don't even see the breakpoint in breakpoint manager by itself. If I add another breakpoint somewhere else then I see both of them.

[altenbach]

I don't think it is an execution problem, but a result of compiler optimizations. If you place a probe on the breakpoint wire, you see that it only receives data after the loop has executed.

My guess is that most of the code on the right side is optimized away since both boolean wires are guaranteed to be true and there is not much left where the breakpoint can attach. Just wildely guessing.

Besides the breakpoint issue (Yes, i agree it is a bug), the code seems to work correctly, right?

[Randall_T]

Yes the code executes correctly except it will not stop for the break point when expected. Now I know that it behaves this way it will not be a problem but I thought perhaps someone else could benifit from this knowledge. 

Thanks for the feedback.

[Yamaeda]

I found a similar issue some time ago which i think is related. In this case i probed a wire that didn't connect to anything (just a border) and got really crazy result on the incoming wire. Connecting it to an indicator fixed it. Probably an optimization caused it, as the value wasn't really needed. This sounds similar.

/Y

[aflojo]

Hi All,

I was able to reproduce this with the code you provided. I will report it through the proper channels thank you for pointing this out to us!