Breakpoint happens in the wrong place

[mikeporter]

Ok this is a strange one. Refering to the snippet:

When I run this code, the breakpoint fires and the TCP Modbus VI is highlighted as the next node to execute, which is ok I guess though I could make a case for another behavior. The problem is that when I click the continue button with highlighting turned on the next function to execute is the 1D Array Sort! After it runs, execution continues with the small loop, my little "blocks" VI and finally the loop to the right. When execution finally reaches the breakpoint's actgual location, it does not fire again.

HOWEVER, if I change this code to turn on parallelism in the little loop after the sort, all works as I would expect: The breakpoint fires and the next things to execute is the loop to the right.

Mike...

[tst]

I have seen cases before where LV does get the order incorrectly. See here for an example - http://forums.ni.com/t5/LabVIEW/Should-a-shift-register-output-data-prior-to-loop-execution/m-p/3241...

I also remember bugs where it looks like LV tries to optimize the order of operations in parallel code and ends up running something which is supposed to be after a loop before it, although I can't find it with a quick search.

[johnsold]

What happens if you put probes on the wires between the 1D Array Sort and the breakpoint?

I try not to trust debugging tools too much because little things like that seem to happen.  The complier optimiazations and the debug code sometimes seem to fight each other.

Lynn

[mikeporter]

They don't update until after the breakpoint fires and I resume execution.

By the way, I don't really have any expectations that NI will ever fix this... But going forward people should know about it and perhaps this conversation will help them.

Mike...