Go to Post The amount of sense this rule makes is irrelevant. It is still the rule, and breaking this rule violates something that i'm sure all of you have heard of. Does gracious professionalism ring a bell? - Kate00 [more]
Home
Go Back   Chief Delphi > Technical > Programming > C/C++
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
 
 
Thread Tools Rate Thread Display Modes
Prev Previous Post   Next Post Next
  #13   Spotlight this post!  
Unread 11-16-2010, 08:27 AM
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,748
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: Intermitten power failures

Camera communication is over TCP, and both the reads and writes have timeouts of 0.5 or 1 second on LV. I can't say what they are on C++. This was my basis for saying that I didn't expect a large CPU spike with the camera wasn't plugged in or powered.

When I said slow errors, that is of course not very definitive. It is true that last year's system could choke a bit when a large stream of fast errors were being sent to the DS. I don't think those errors would be only camera, but if you had lots of other errors, the camera could contribute to make things even worse.

As for loops causing watchdog issues, it isn't the fact that it is a loop, but the time that the code takes to execute. If the code manipulates a solenoid, a common occurrence last year, they code would often have delays and would cause a watchdog each time it ran. Even worse, it would cause many teleop packets to be overwritten since the teleop handler would take far longer than 20ms to execute.

A printout was inserted deep into the libraries last year to help determine when short disables were occurring. It kept count of the user and system watchdog disables since boot. If these correspond with the robot "power failures", then indeed, the WD was disabling the robot due to a missed deadline. If not, then it was something else.

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

Similar Threads
Thread Thread Starter Forum Replies Last Post
[FTC]: Common failures with TETRIX PhilBot FIRST Tech Challenge 20 10-25-2012 11:19 PM
Your Successful Failures ? ebarker General Forum 0 11-03-2009 01:20 PM
Last Minute Programming Failures robobrain0101 Programming 3 02-11-2007 02:30 PM


All times are GMT -5. The time now is 09:29 AM.

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