Thread: CRIO ghosting
View Single Post
  #3   Spotlight this post!  
Unread 23-03-2014, 13:04
Thad House Thad House is offline
Volunteer, WPILib Contributor
no team (Waiting for 2021)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Thousand Oaks, California
Posts: 1,091
Thad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond reputeThad House has a reputation beyond repute
Re: CRIO ghosting

Quote:
Originally Posted by Greg McKaskle View Post
When your compressor ran unexpectedly, I doubt that the robot was really enabled. Usually, this is either caused by an improperly wired compressor circuit or a faulty digital breakout board that has shorted.

The other symptoms sound like they could be caused by a limit switch that has stopped working. It could be due to wiring or code that doesn't read it often enough.

I can't speak for all engineers, but I don't believe in ghosts. Also, imaging the cRIO seems to have this mystical quality. It replaces the OS and libraries on the cRIO's file system. It is only necessary if the files have become corrupted, and a corrupted OS generally doesn't boot, run, and simply read limit switches differently.

I'd encourage you to debug and diagnose the symptoms independently. Fix what you find and develop good testing techniques for your robot. Things are almost guaranteed to break and become damaged in this game, so being prepared to diagnose and correct is a great skill to have.

Greg McKaskle
When the robot enabled in the queue, the DS actually showed enabled, and other motors started as well. It actually caused our catapult to dry fire in the middle of the queue, which made it really scary.

Also, when the issue happened in matches, it visibly was not running the correct code, even if we ignore the limit switch. We usually have a delay of about 2 seconds before anything moves in auto, but everything started moving immediately, instead of waiting.

The limit switch when tested was working correctly, and is running in a 10ms periodic tasks loop, where it is triggered for more then 100ms by the robot.

Where else should I look to see if there are problems?
__________________
All statements made are my own and not the feelings of any of my affiliated teams.
Teams 1510 and 2898 - Student 2010-2012
Team 4488 - Mentor 2013-2016
Co-developer of RobotDotNet, a .NET port of the WPILib.
Reply With Quote