Script and serial watchdog

Several passages in the user's manual imply that any script generated command will re-start the serial watchdog timer. For example:

In the Serial mode, the mode is considered as active if commands (starting with “!”)
arrive within the watchdog timeout period via the RS232 or USB ports. The mode will
be considered inactive, and the next lower priority level will be selected as soon as the
watchdog timer expires.

Script commands are also subject to the serial Watchdog timer and share the same
priority level as Serial commands. Use the “Command Priorities” configuration to
set the priority of commands issued from the script vs commands received from the
Pulse Inputs or Analog Inputs.

However:

Script Command Priorities
When sending a Motor or Digital Output command from the script, it will be interpreted
by the controller the same way as a serial command (RS232 or USB). This means that the
RS232 watchdog timer will trigger in if no commands are sent from the script within the watchdog timeout.

implies that only Motor or Digital Output commands reset the watchdog.

Which is it - all SetCommand or only some of them? And, does Motor command mean only commands that Roborun, for example, would graph as MotorCommand (e.g. _G) or also commands such as SetCommand (_DECEL,cc,var)?

Hmm, it's even unclear to me what the correct behavior would be. Indeed, changing any command should be considered a serial update and reset the watchdog, but that may not currently apply for runtime commands that are hooks for maintance commands and configuration settings (such as !EES), and it is ambiguous whether that would be desirable or if it is intended. I will have to bring this up with our firmware engineers and get back to you.

For now, the behavior seems to be, as far as I can test, that unless you command a new motor command, position, or a digital output change, the watchdog timer will continue counting down. I will be sure to bring up the watchdog timer at our next engineering meeting however. If there is a clear methodology to which commands do and do not reset the watchdog timer I will let you know, and have our documentation changed.

Okay, I have a weird answer. In 1.8 any run time command will reset the watchdog timer. In 2.0 this behavior will change to only a few select commands that will be listed in our documentation.

Indeed the answer you got is decidedly weird. I don't know what version the user has that is causing a problem, but here's why I suspected that the watchdog might be reset only by some SetValue commands.

This person is testing the current analog version of my script for wheelchair control with an FBL series controller. The problem he's run into is this. If the joystick is moving, behavior seems to be correct, but if it's held in a fixed position at 1000 he gets a sawtooth (Roborun+) Motor Command oscillation from 0 to 1000 and back to 0 with a period of about 7-800 msec. Another user, who has an HDC controller, has not run into this.

The script sends _G only IF the joystick output changes, whether because the stick is moved or because of noise, and I wondered if lack of this motor command was causing the watchdog (set at 500 msec) to trigger. Given the lack of a definitive answer to my question, I will have him test this hypothesis by increasing the watchdog time, and if it is a watchdog problem I will have the script get the watchdog configuration from the controller and send an otherwise-unneeded _G at a somewhat shorter interval, doing it this way so that different users don't have set a particular watchdog time in the profile.

BTW, I think having the watchdog reset only with motor-affecting script commands is actually a good way to do things. It's aberrations in motor behavior from which we want protection. Loss of information for other functions is less likely to affect safety. Even more important from a user's standpoint would be clarity in the manual.

Could it be that there's been an "oscillation" in your engineers' thinking between the firmware for different controllers as well as from one firmware version to another?

If it is 1.8, you will need to send a runtime command (SetCommand()) to restart the watchdog timer, so the above behavior sounds as expected.

One workaround I would recommend if you want to enforce the watchdog is to use a User Variable as a Comm status value, and then continually update it. This creates an impromptu heatbeat that should continually reset the watchdog timer in 1.8. The only downside to this approach is that it shouldn't work in 2.0 when we release it. I will ask at an engineering meeting to add some sort of dedicated heartbeat command in 2.0. We will also update our documentation to specify whether the command does or does not reset the watchdog timer.

Here is an example snippet that displays what I am talking about:

I still don't have confirmation from the user who's run into this problem that the watchdog timeout is involved. However, should that be the case what I would do something like this:

That could work, but I am proposing having a heartbeat signal independent of motor commands.

You can also always disable the serial watchdog by setting it to 0.

That could work, but I am proposing having a heartbeat signal independent of motor commands.

You can also always disable the serial watchdog by setting it to 0.