Software engineers make mistakes. No matter how well experienced you are, or how many unit tests you’ve written for your code, or how well reviewed the code is, we’re humans and at some point or another we’ll make mistakes. It can be a null pointer reference, an out-of-bound indexing of an array, segmentation fault, a zero-division or any other selection of the thousands of software bugs that should not happen but will happen. In my current area, development of wave energy converters (WEC), I don’t have the luxury of being able to easily reboot the PLC/controller if a software crash happens. I can’t just walk up to the system, and do a power-reset. The WEC can be far out in the ocean. Going out on the ocean and doing any form of maintenance involves costs, which we want to avoid. With this type of scenario, it’s time to consider a watchdog timer.
The watchdog timer in a Beckhoff PLC is a last resort if everything else fails. Simply described, it’s a small piece of software consisting of a timer that monitors if the TwinCAT runtime and your software is in a running state. If the watchdog doesn’t get the response it expects for a certain amount of time, it reboots the complete system so that you get back into a known state. There are many cases where some sort of watchdog has saved a project from high cost or disaster. Watchdog timers are essential when the system is automated and remote.
Watchdog timers in TwinCAT
Part of the watchdog functionality is implemented in the BIOS of your Beckhoff PLC. Once the watchdog is activated, the BIOS monitors and checks that the TwinCAT runtime has called the watchdog to indicate that the software is indeed alive. The good thing about BIOS being involved is that it doesn’t matter where the crash happens. As long as your software stops indicating that it is alive and running the BIOS will detect this and do a system reboot. Now there are many different function blocks that you should use in TwinCAT depending on the hardware that you are using. The one that I’ve found working for my CX5140 and that seems to be the most general and not bound to specific motherboards and/or PLCs is the FB_PcWatchDog_BAPI, located in the Tc2_System library. This does however not support all Beckhoff IPCs/PLCs, so if you want to be certain it supports your particular model then contact your local Beckhoff support. For the readers that are extra curious of how it works in the background, I can recommend looking at the source-code for the Beckhoff BAPI (BIOS-API).
The documentation for the function block describes the usage (with an example) well, so I’m not going to focus on the implementing part of the function block, but rather show a scenario of how it looks when this function block is used. I’ll demonstrate this with help the of a video. Before doing anything practical it’s important that we read and understand the warning stated on the Beckhoff website, let me quote:
The watchdog must be deactivated before breakpoints are used, before a PLC reset or an overall reset, before a TwinCAT stop, before switching to Config mode or before the configuration is activated, because otherwise the PC would reboot immediately once nWatchdogTimeS has elapsed.
Once you’ve started the watchdog (by bExecute = true), you need to make cyclic calls to the function block within the watchdog time that you have specified (nWatchdogTimeS). Once the watchdog is enabled, the hardware in the PLC will reset the system if the function block is not called within the watchdog time. This is completely independent of what the reason is that the function block is no longer called. Make sure to disable the watchdog (by setting nWatchdogTime to zero seconds) when you’ve finished experimenting. However, once the system is rebooted the watchdog needs to be enabled (from PLC-code) again. So if your system boots into configuration mode and/or the PLC-program running the watchdog is not executed, the watchdog will not be enabled.
To watch the watchdog in action, I’ve recorded a video demonstrating this using a Beckhoff CX5140 PLC.