[apalrd]

There are a few watchdogs in the FRC control system. Two exist in the FPGA, and many in user code only.

The FPGA has two watchdogs ('system' and 'user') which are reported to the debug console on the Driver Station when they trip. System reports watchdog errors between Netcomm (FRC communication, not user modifyable) and the FPGA (also not user modifyable) while User reports errors between the user code and FPGA. The 'user' watchdog is no longer really used, although I continue to use it in my code.

The 'user' watchdog is accessed by the red Watchdog blocks in WPI Robotics Library->Utilities->Watchdog and only one exists. Basically, you set a timeout (Default is I believe 500ms, I set mine to 50ms) and must call 'FEED' (there's an FPGA block which sets a boolean to 1 to trigger the FPGA timer) within that time interval or the FPGA will kill all of the outputs (motors, relays, and solenoids). This protects you if all of your code is in 1 thread (as multiple threads separately feeding it could allow code that has gotten stuck in 1 thread to be ignored, and a few but not all of the outputs to be unsafe). It also protects you if your code totally crashes or you stop it with the red stop button in Robot Main. It is IMHO a better protection than the pure software 'watchpuppies' as it involves a second processor.

There are also 'watchpuppies' which can be created for each motor, as the 'safety config'. These are watched by another thread as part of the user code (Actually in Driver Station Start Communication) which checks the timestamp of the last update against the current time. These can exist (if they are enabled) for any motor, relay, or solenoid separately.

Depending on your programming architecture, you can use one or the other or both. I use the FPGA user watchdog only in my code (safety checks code completely removed), set at 50ms, with a 10ms hard loop time. All of my code runs in the same task, so I am not worried about independent code failures. Many programmers run lots of tasks, and should do something else.

What you probably saw with the pneumatics is the effect of the pneumatics after entering an enabled state, as the output was set when exiting an enabled state or in the last enabled state (when teleop ran), but the FPGA enables the outputs faster than the user code can run (so teleop has not yet run since the code entered enabled state). There were issues in the past (not sure if they were fixed) with the relays not respecting the disabled state (due to the hardware and the way the FPGA handles disabled states).