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
(2,163 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
(2,160 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
(2,150 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
(2,091 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
(2,079 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
(2,043 Views)

Also:

Turning 'retain wire values' can be very helpful.

0 Kudos
Message 7 of 9
(2,012 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
(2,003 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,998 Views)