View Single Post
  #6   Spotlight this post!  
Unread 21-02-2012, 07:56
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: Any Actual Purpose to Safety Enabled?

Ideally, you would write the autonomous code so that you wouldn't need to disable the safety update mechanism. But it is your robot, and you can disable it completely if you like.

The safety update is just a watchdog timer. If your code isn't in control of the robot, sending updates it could be something serious like a breakpoint, an infinite loop, an exception, or other serious issues. It could also be slow code, or code that doesn't care to update the speed -- not really a safety issue, but the code can't tell the difference.

If you are pretty sure that the code is safe, you may choose to turn off the safety. If you would instead like to put in loops to do updates, you don't need to turn it off.

As for the breakpoint issue. I believe the WR debugger can be set both ways. LV, leaves parallel tasks in other diagrams running, by the way, so the robot comms is still going, I/O still enabled. I don't know what the default is for WR. I don't know how Java behaves at a breakpoint.

So, the HW safety mechanism is triggered by a loss of comms, and tthe Safety config is another layer of safety specific to the SW updates.

Greg McKaskle
Reply With Quote