Active Structure Debug Indication

[wiebe@CARYA]

When entering debug mode (turn execution highlight on) it can be hard to see what is happening.

With event structures it can be hard, but there are subtile changes. Sometimes it's impossible. For instance, if you run this VI, and wait a while, it is impossible to why the VI has not stopped. In this case it's easy to deduce, but it can be really hard. Probes also don't provide a solution here...

SubVI's get a green arrow when they are executing. So, could structures get them as well?

[altenbach]

So that idea would recursively mark all loops that are currently executing, all the way to the toplevel loop in the case of deeply stacked loops. OK, that could be generally useful.

However, it does not solve the main problem if the innermost currently executing loop contains a lot of code and is hung up at a "wait for occurrence", because it will not pinpoint the exact stall location. I still think this function would also need to be marked if it is waiting (e.g. with the same green arrow), solving the original problem that triggered this idea.

[JÞB]

This menu ring that will "Pop" you to  any point in the call chain highliting the point of execution.

Note: I did have to enable debugging on the sub-vi to set the breakpoint so vis in vi.lib and structures still won't show but, the diagram the subvi is in can be reached.  Technically feasable to add the "structure executing" glyph since the call chain IS known and the exact location in any diagram/subdiagram must be known for the call chain menu ring to work the way it does today.  but, I don't see the need for the glyph on the surrounding subdiagram structure when the call chain ring takes me right to it.

And Probes will get you there too if you "Retain wire values" and watch times as well as values on your probes

[wiebe@CARYA]

Jeff,

Never noticed that ring in a sub VI. Perhaps it will be useful, so thanks for bringing that to my attention.

It won't help for occurrences, queues, and other blocking functions. Or blocking structures, like the event structure and timed structures (these have other debugging issues\bugs). It is also additional work, and the suggested indications would give the information immediately.

The retain wire value, to me, has an "after the fact" issues. You need to foresee the problem, but when a problem is there it's usually too late to turn it on. It could also be very undesirable when dealing with large data sets. More important, it's not always a solution, since the wire will have a value when executed once. So it will still not give you information about what is running, only what has been running at least once. I could be wrong, I never use it.

Christian,

Yes, arrows on blocking functions would be great. In fact, if they where there, it would reduce the need for the arrows on structures. Both would be convenient to have.

OT:I tried to check how debugging is handled in timed structures (timed while loop) and it looks really wrong to me. A wait in a timed loop gets a green arrow, even when the timed loop is waiting for execution. This is just wrong. It does not happen with sub VI's, even if they are reentrant. So I put a probe on "i", and it says 0. Until you abort the VI, then it jumps to 1. How confusing is that?