can't find where code is still processing at

[bmishoe]

I have my code organized into a flat sequence structure totaling 6 panels.  The 6th panel closes an established telnet connection along with the VI's front panel.  My problem is that the code in the 6th panel never executes (I know because I've placed a breakpoint there that never gets hit).

The majority of my code is in the 5th panel, which is a collection of parallel while loops.  The 'stop' button of each loop is connected to a "Get Notifier Status' node, as in this example (2/3 of the way down the page):

http://digital.ni.com/public.nsf/allkb/267704CDE91156D186256F6D00711AAE

I put a probe at every single loop's stop wire, and it is working as expected.  In other words, when I click 'stop', each and every loop's "get notifier status" output (i.e. the input to the loop's 'Stop sign') changes from false to true, and all processing stops.  However, even though every loop in the 5th panel is now stopped, programming execution doesn't proceed to the 6th panel.

I recognize that that can be kind of confusing in its description, so what I'm actually hoping for is that someone can tell me how they'd approach debugging this problem.  If execution doesn't proceed, then that says to me something in the 5th panel is still going.  I've looked everywhere and don't see any code that's not contained within one of the loops that I know have stopped, but regardless I clicked on "highlight program execution" in hopes that it would show me the block of code that's the problem.  However, even after highlighting execution, I have looked all over the 5th panel and don't see "data travelling along wires" anywhere, i.e. I still can't see where it's processing.

Is there something else I can do to see where it's processing?

Thanks in advance

[jcarmody]

Is there anything wired into the sixth frame that hasn't yet received its data?  This can either be from the fifth frame or from the outside of the entire structure.

[bmishoe]

I don't think so.  Here's a screen cap of the 6th frame.  You can see probe number 33 to the right of the 5/6 tunnel.  I also placed a probe on the left hand side of the tunnel (i.e. frame 5).  It shows a valid value.  In other words the value is there at the tunnel but execution never proceeds past it.

[RavensFan]

Having a screen capture of the 5th frame would be helpful as well since you say that is where you code is still hanging.

But in the 6th frame, I see you have a breakpoint set around that inner, 2-frame, sequence structure.  I can't tell if that is something you intentionally did as part of this debugging process, or something you accidentally did, your code is actually holding there, and you didn't realize it.

It's not clear from your description whether you have a value showing in probe 33.  If the execution is getting to the inner sequence structure and holding there, you should have a value in probe 33, but if you don't, maybe it is some oddity about the way the probe window is updating values.

[crossrulz]

This when I normally turn on the highlight execution.  There is often a VI or function that is stuck for whatever reason.

[RavensFan]

What version of LabVIEW are you using?

I remember there was a bug with highlight execution for 1 or 2 versions, I think somewhere around 2010.  Before the problem versions, when you have highlight execution on and the code is stuck in a subVI, you'd see a green arrow on top of whatever subVI's were still executing.  That arrow disappeared in the problem versions.  If a subVI was still executing, you couldn't tell which one until you got lucky and drilled down into it.  Eventually the bug was fixed and the recent versions of LabVIEW show that green arrow again.

[bmishoe]

Frame 5 is a large frame of parallel while loops, so any screenshot I provide would have to be so zoomed out it would be useless.  However, from placing probes at every single loop, I know that the value of the loop 'stop' is set to TRUE after I click the 'stop' button I created on my front panel.

Apologies - NO - there's no value in probe 33.

I'm running 2012 SP1.  In theory, highlight execution is the perfect solution for this problem....when I've used it in the past, the moment I click on it, it takes me right to the currently executing code (i.e. my screen automatically moves to the portion of the block diagram executing); however, in practice this time, when I click it, nothing happens (i.e. screen doesn't move, can't find data anywhere)...it's as though I never even pressed the button.

[RavensFan]

I'd do a block diagram cleanup, at least temporarily, to see if there is any code hiding somewhere.  Such as a subVI that is hiding behind a loop.

I often create boolean indicators, one for each while loop.  At the beginning of the program, I'll set local variables to all of them False.  I'll wire the stop condition out of the while loop and to its terminal.  That way I can see that all loops that have stopped will be now True.  Any loops still running are still False.

Just because you have a True Value on the probe going to the Stop terminal doesn't mean that all code in the loop has stopped.  It means that the Stop condition has been set.  The while loop won't actually complete and move beyond it until all code inside the loop has finished.  So perhaps there is still something else happening in parallel in one of the those while loops.  Checking the value using the boolean indicators immediately after the while loop will truly show you whether the loop has finished.

[bmishoe]

oh wow I didn't know that...I was thinking that the stop condition got evaluated after the code inside the loop was processed, but it makes more sense that it gets evaluated first.  In any event, that's an excellent suggestion, I will give it a try.

[crossrulz]

---

RavensFan wrote:

Just because you have a True Value on the probe going to the Stop terminal doesn't mean that all code in the loop has stopped.  It means that the Stop condition has been set.  The while loop won't actually complete and move beyond it until all code inside the loop has finished.  So perhaps there is still something else happening in parallel in one of the those while loops.  Checking the value using the boolean indicators immediately after the while loop will truly show you whether the loop has finished.

---

In my experience, it is usually a Dequeue Element or Event Structure waiting for a message that will never come that keeps a loop from completing.