LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to debug correctly

Hi everyone,

 

I am fairly new to Labview. I wonder if there are different ways to debug the code.

Right now I always place a dozen probes to see what happens somewhere.

 

But now my code is stuck somewhere (have to find the right place yet). Is there a better way than using probes?

 

Thanks

melody

0 Kudos
Message 1 of 9
(1,173 Views)

If the code gets stuck, the Highlight Execution lightbulb is excellent, it'll show you which VI is working. I also like the Retain Values lightbulb so i can check all values by hovering over them without placing probes (there's always something extra you want to check). If you activate it in too many VI's things get sluggish, but if you're debugging a couple VIs it works fine.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 2 of 9
(1,170 Views)

There's also NI IO Trace, which lets you see more things (like VISA communication)

 

edit:

and Desktop Execution Trace Toolkit (which i have never used) which seems to have some CPU details and events.

Message 3 of 9
(1,160 Views)

Attached is an ancient set of logging files that I sometimes temporarily sprinkle around suspicious code.

Also some highlighting VIs that turn highlighting on or off when execution gets to them.

"If you weren't supposed to push it, it wouldn't be a button."
Download All
Message 4 of 9
(1,101 Views)

@me1ody wrote:

Hi everyone,

 

I am fairly new to Labview. I wonder if there are different ways to debug the code.

Right now I always place a dozen probes to see what happens somewhere.

 

But now my code is stuck somewhere (have to find the right place yet). Is there a better way than using probes?

 

Thanks

melody


Don't write bugs.


"Should be" isn't "Is" -Jay
Message 5 of 9
(1,089 Views)

Probes.

Execution highlighting.

Temporary indicators (incl. arrays that build up data).

Temporary Breakpoints.

Temporary Message popups.

Assert VIs (See Exposing the Holes of the Assert API by Peter Horn)

Stopping the main, debug the sub VIs.

Copy subVIs into a new VI, test it there by changing the input data (gateway to unit testing).

Desktop Execution Trace Toolkit (DETT)

 

The best way to find bugs is to remove the crap. Bugs hide in crap.

 

If you can't easily find a bug, it's (almost by definition) because the code is too complex.

 

Pretty useless advice, as making things simple is the hardest thing 😊. But sometimes things get complex simply because no time is spend to refactor. If bugs can't be found, that's the cue.

Message 6 of 9
(1,053 Views)

Also:

Turning 'retain wire values' can be very helpful.

0 Kudos
Message 7 of 9
(1,022 Views)

Hi Paul,

 

your Log2 zip file is missing atleast one subVI ("variant to string")…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 8 of 9
(1,013 Views)

@GerdW wrote:

Hi Paul,

 

your Log2 zip file is missing atleast one subVI ("variant to string")…


Oops.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 9 of 9
(1,008 Views)