CPU at 100%

[blaisanx]

Hi everyone,
Im a programmer from team 1732 and i need a bit of help with our cRio. even without having anything running, our CPU usage is at 100% we tried taking out all of our vision tracking code to no avail. is there any team that has had and fixed this problem or know how to fix it. any help would be appreciated.
Thanks

[Mark McLeod]

If you want to zip and post your project we could help look for the problem.

A common cause is a While loop that doesn't have a Wait inside to give the CPU time to breathe.

[Joe Ross]

Another common problem is a typo in a device reference that gets called repeatedly. This is shown by error messages on the driver station diagnostics screen.

[pastelpony]

Try and see if there any devices that are programmed onto the bot but not in actual use (i.e. a solenoid or compressor.) For example, our bot's cRio completely crashed during a match because we forgot to take out references to a solenoid that was not actually on the bot and so the cRio was maxing out it's usage while trying to find it. Also, disable any safety configs that may be hooked up to devices in your code. Sometimes, an incorrect loop in Periodic Tasks can cause a cRio to max out.

[joecloud]

Do you have pneumatics on the bot? Make sure in periodic tasks that your compressor code is not in it's own while loop, I did this and had the same issue with max cpu usage and robot joystick response being choppy.
VI's you are implementing that already have set refresh cycles with while loops can cause the cpu to hang if you put those VI's in another while loop (like the cotrol loop for the compressor).

[Greg McKaskle]

Unless it has been modified, the compressor loop has a 1000ms delay. If it ends immediately and you invoke it again in a loop, it will once again sleep that thread for 1000ms. This shouldn't cause 100% CPU usage.

If you do not see a loop without a delay, look for a loop with more work it is doing than time to do it in. If a loop sleeps for 20ms, but uses the CPU for 15ms, the CPU is guaranteed to be above 75% usage. If it runs for 20ms, the CPU is guaranteed to be at 100%.

If you cannot find the loop by looking, consider debugging your code using either the Performance Profiler or using the Elapsed Time VI. Both of these will give you precise numbers about how things are running. It is a lot like turning a light on in a dark room. It is amazing what you find sometimes.

Greg McKaskle

[EDesbiens]

We got the same problem... Just try to lower the number of global variables and make sure youre Crio cards are in order...

[tcjinaz]

Why lower the number of global variables? Seems like the worst they can do to performance is stimulate some extra address calculation dances. The global memory page(s) is(are) probably not likely to get swapped out very often when the main line code is running.

The profiler is a wonderful thing. Pay large amounts of attention to Greg McKaskle; it's his job to know this stuff inside and out. We had a mediocre string to DevRev VI that was called way too often, The profiler highlighted the problem in just a minute or two of analysis. And none of us had seen that profiler before. (FIRST Mentor salary: seeing the lights go on in my lead programmer when he started looking at the profiler data and saw the problem about the same time I did).

[EDesbiens]

Originally Posted by tcjinaz

Why lower the number of global variables?

We had a lot of global variables and they started dead-locking... We changed some of them into local variables to avoid dead-locks.

[tcjinaz]

Originally Posted by EDesbiens

We had a lot of global variables and they started dead-locking... We changed some of them into local variables to avoid dead-locks.

You were writing globals from multiple places? If so, there are some other ways of managing those sorts of communications. They're not in my toolkit today, look for semaphores and queues and the like. And probably you fixed it in the whole with local variables (empirical observations are important).