Dynamically Update color of Wire for Errors [ Debugging mode ]

[sandyy]

Hi Team,

Debugging a big application for errors can be made easy. No need to probe for errors or ON highlight Execution. This idea can be faster to debug a big Application.

I dont know if this idea is posted before. Thanks All.

[AristosQueue (NI)]

You'd still have to turn on execution highlighting or some mode switch like it... even with debugging enabled, LV doesn't take time to message the diagram for value changes unless you request it.

Also, what makes the error cluster so special? If you want to see values on your diagram for debugging, for me, it is just as likely that I'd like to see the string value or numeric value that is about to go into a Case Structure as it is to want to see the value on an error wire.

Also, this information wouldn't show up any faster than it would with Execution Highlighting enabled. The values are available when they get there and no sooner. And they wouldn't persist or be available after-the-fact unless you had also turned on the After Probes option that removes all inplace optimizations from a VI for deep debugging.

Overall, I don't see this being any better than Execution Highlighting is today.

Perhaps you can go into more detail about how you think this would function and when it would be better than EH?

[P@Anand]

Have a look at this Idea (which I posted long back) helps to debugg the application even better.

[sandyy]

Thanks for the Comments.

@ AristosQueue :  When i debug a big application Execution Highlighting, as you know will take more time. This method will run as normal VI but Highlight the color of the nodes based on Errors. which will take less time to get into the error.  This may be a visual Representation or overview of flow of errors.

@ Anand : This may be a visual Representation or overview of flow of errors for a big application .Your idea is also good .

[P@Anand]

I am still not convinced for this idea, because its main focus is just to catch the error. When you take debugging methods (Highlight or Probe) it has lot more to do apart from catching error. And when you make a good design eventually error handling will be a part of it and you will catch it at a glance.

[crossrulz]

I'm still thinking I might as well just use the probes.  Plus, my error handling tends to include the call chain, so it is usually quite obvious where the offender is.  This becomes even more important when you build an executable.

[AristosQueue (NI)]

sandyy: So your prime concern is just the time it takes for the highlight dots to move through a diagram? If it weren't for that, exec highlighting would be supplying the information that you're looking for, yes?

[sandyy]

Hi AristosQueue,

Yes Exactly.

Please think in this aspect. New production support engineer debubgs the Application in a live production Environment. Where,

1. Dont have much time to debug

2. Can not use higlight option to get time critical datas

3. Its a production Environment

4. Real Time

5. Worst thing, support engineer taking a first look of the application and he needs to support as its critical.

This idea may not a so useful where you have more time to debug & not real time. 

Snapshot  i just made it paint, it can be better, just an idea how it can be.

Thanks All for your time

[P@Anand]

AristosQueue

Is there any option/Idea to change the execution time of Highlight option instead of sticking to the LabVIEW default time of execution?

[crossrulz]

You mean like this one: Variable Speed highlight execute?

[AristosQueue (NI)]

sandyy: Given that your use case is just the speed of execution highlight, your idea is a duplicate of the existing idea (see the post by crossrulz above).