Go to Post FIRST isn't for wimps. It never has been. - JaneYoung [more]
Home
Go Back   Chief Delphi > Technical > Programming > NI LabVIEW
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
 
 
Thread Tools Rating: Thread Rating: 5 votes, 5.00 average. Display Modes
Prev Previous Post   Next Post Next
  #29   Spotlight this post!  
Unread 02-02-2012, 08:13
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: Worried about high CPU usage in CRIO

About the scale on the chart. The graph plots are plotted against the scale, so 0 is not the bottom of the black chart area. If you see your red plot go to the bottom of the black plot area, that would be negative, and I'm not sure if that is a good thing for your CPU.

The reason the scales are lifted off the bottom was to leave room for the instrumentation dots. There are four plots below the 0 on the scale, one for the robot mode that the field or DS gave to the robot, and one each for any calls by the code to declare what was run. At least for LV, the framework has VI calls in it to place a dot on the chart each time the teleop code is run, each time the disabled code is run, and each 20ms while the auto is running. This should help identify when robot code doesn't leave auto, or runs auto and tele or other odd combinations during the event, as well as noting when the code doesn't run anything for extended periods (typically caused by large delays inserted into teleop).

Anyway, thanks for verifying.

I looked into why the autonomous is by default higher than the others, and it is caused by RobotDrive not being updated. Not updating for 100ms causes the robot safety override to kick in. No big deal, but it uses the uncaught error mechanism to print the message to the DS. This adds the extra overhead. Next year, we'll hopefully be able to redo the uncaught error stuff to be cheaper, and/or explicitly send the safety message. A properly written auto should never go into safety, at least not until it has run to completion and stops sending motor commands.

Does anyone else seem to see excessive CPU usage in simple code? Is this one still causing anyone issues?

Greg McKaskle
Reply With Quote
 


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 00:58.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi