Debugging exotic LabVIEW problems - Performance Monitor

[Sam_Sharp]

That's a great writeup - I've used the performance monitor in the past (particularly for looking at CPU spikes and/or memory leaks over time) but you've managed to describe the use of the tool very well - it's definitely one that developers (of any language!) should have in their toolkits.

[PaulG.]

" ... Deleting controls one by one from the Front Panel eventually led us to the fact that we had some messed up controls on the FP which were sending the UI thread crazy.  Replacing these controls with visually identical new controls solved the problem ... "

This sounds odd. How does a control get "messed up" exactly? Does it "wear out"? 

[QFang]

Hey PaulG., I think it was a case of loose wire-nuts!

Sometimes in high vibration environments, the wires will shake loose.

http://blog.jki.net/news/announcing-the-new-jki-wire-nut-toolkit-for-labview/

(sorry, it is Friday, I could not help it.  Your question is valid, and I have no answer myself.)

[DavidBoyd]

Paul,

Not sure of the exact "how", but I know controls are made up of lots of member parts with complex class hierarchies exposing all kinds of properties.  A few trips through the control editor plus a few version upgrades involving "mutations" (great terminology used by NI!) and (I'm guessing) somebody somewhere in that control's/indicator's descriptive space gets warped.

At least, that's my mental model. Someone from NI will have a better description, I hope.

Dave

[Hooovahh]

Yup I love Performance Monitor.  I usually set it up to log to a tab delimited file once a second, and then open the results in Excel later.  Several of the issues I've had to debug were BSOD, or out of memory crashes, and when this happens all you have left are the logs.

It's pretty brute force, but once I found there was a repeatable way of causing memory to increase, I would play with it and see if doing somethings caused memory to increase faster, slower, or the same.  I'd simulate data and see if the memory increased at the same rate.  If it didn't it wasn't hardware related.  I'd use these basic troubleshooting techniques, along with disabling parts of the code until I could narrow down to what was causing the memory or BSOD event.

Troubleshooting these types of issues is a pain no matter how you do it, and they take time, lots of time depending on the steps to reproduce the issue.  But with the tools provided by NI, and a few others like Performance Monitor we can always narrow in on the cause.

[dan_u]

---

PaulG. wrote: 

This sounds odd. How does a control get "messed up" exactly? Does it "wear out"?

---

We customized controls in LV2012. No problem there. When switching to LV2015 SP1 half a year ago the problem started. So the version upgrade on the customized controls messed some of them up.

It seems a bit random, though. As mentioned before a slide control with 1 slider was affected, the same control with 2 sliders was not.

Back then we didn't have a clue why the software would become sluggish when used over several days (try debugging problems that only start after several days without having a clue where to look...). Only performance monitor helped us identify the root cause.

[pallen]

Thanks for the great post!

This thread is Bookmarked!