ConnectionWatchdog

For safety reasons, your application may start a communication watchdog with a timeout. The application must send another ConnectionWatchdog command before the defined timeout otherwise the robot will automatically stop moving and report a safety stop with the message [3086][1]. The goal is to make sure that the robot quickly stops moving if communication with the TCP application is interrupted for any reason (including network failure or bug/freeze/dead-lock of the controlling application).

Syntax

ConnectionWatchdog(t)

Arguments

• t: desired timeout period, in seconds, ranging from 0.001 to (2³² − 2)/1000. If the argument is zero, the connection watchdog is canceled.

Default values

By default, the robot will supervise the TCP connection but only when the robot is moving, and as soon as it detects a connection loss, it will stop moving and return the message [3086][1]. However, the delay between the connection loss and the detection may vary from a few milliseconds to several seconds, depending on your network activity.

Responses

• [2177][1]

• [2177][0]

The first response is sent when the connection watchdog is activated for the first time. The second response is sent when the connection watchdog is deactivated with ConnectionWatchdog(0).

Usage restrictions

This command can be executed in any robot state.

Cyclic protocols

This command is not available in cyclic protocols. However, each of these protocols has its own mechanism for managing communication timeouts. For example, in EtherCAT, the master can detect a communication issue if a slave fails to respond within the expected cycle time, triggering a watchdog timeout or setting an error status in the process image.