View Single Post
  #4   Spotlight this post!  
Unread 19-01-2014, 09:59
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,751
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: Robot Code State starving loops

The lower chart has a plot of CPU usage. It is a red line and it appears to be at 100% the entire time. That is a much better indication of an issue than the Code LED.

First let me explain that the blinking Code LED doesn't indicate that your code is aborting and restarting. If you think about it, how does it know your code is running anyway??? The Code LED is based on whether or not the cRIO program transmits the battery voltage. If it doesn't, the DS presents this as the cRIO code not running -- for that period of time.

So the bigger question is, why is your CPU at 100% causing everything including your battery values to be behind? I assume you were opening all the windows and exploring the code expecting the issue to be in disabled, teleop, or in something they call. You found that they both call Robot Code State and figured that was the culprit. But there are a number of parallel loops running on your robot, and they are far more likely to be the issue.

So, the first thing I'd do is to close the panels of all those subVIs. That will in fact increase cRIO CPU since it has to run the debugging protocol for each of the opened panels. After this, is your CPU usage still at 100%?

I assume so. So the next step is to identify what the CPU is working on. There are two ways that I'd recommend. Once involves using a tool, the profiler, to identify which functions the CPU is spending its time on. The second is to inspect the code you most recently changed looking for loops with no delay.

My suspicion is that your vision code or your periodic tasks are the culprit. Post images of those. A simple jpeg will do -- 720P or even a 480P video with soundtrack and an indignant and misspelled question to the universe is really not that helpful.

If you would like, you can also search CD for info on how to use the Performance Profiler. It will indicate how much CPU each VI is using.

Greg McKaskle
Reply With Quote