Hi Alex,

Unfortunately, when a task watchdog is triggered, the most information we can get from the PLCnext Runtime is the name of the program instance that caused the timeout.

You could try debugging the code, or adding diagnostics code to the program, to try and identify the source of the delay.

Thanks Martin,

Does that error mean that the program in question took 299830us longer to execute than what I entered on Interval?

Hello Alex,

the second option is to delete the programs under the task (if you have more as one). And if the program with high duration time is founded, you can delete/cut the Code in the program and try to start the program to check if the problem is resolved. I think so you can spare the time during the analysis.

Best Regards

Eduard

Hi Alex,

The watchdog should trip as soon as the timeout is reached, without any more code execution. I cannot explain how the "time after task start" value is calculated, but I am currently in conversation with someone who should be able to tell me, and I will let you know the answer when I have it.

I have reproduced this situation as follows:

AXC F 2152 FW 2020.6.1

PLCnext Engineer version 2020.6.2

Cyclic task 100ms, watchdog 100ms

One program instance. This program:

WHILE TRUE DO
   // Nothing
END_WHILE

... generates this message in the Output.log file:

03.09.20 12:02:00.934 Arp.Plc.Esm.Internal.WatchdogHandler                         ERROR - Watchdog of task 'Cyclic100' triggered. (watchdog time 100000us / time after task start 199816us)

The "time after task start" is (approximately) 200 ms, when I would expect it to be 100 ms.

Better late than never, I suppose ...

I now have an explanation for the "time after task start" behaviour described in this thread.

In the scenario described above, the task Interval and the task Watchdog values were both 100 ms.

There is a PLCnext Runtime component (called WatchdogHandler) that checks the execution time of each task and compares it with the Watchdog time. If the task has been running for longer than the Watchdog time, then we get the Watchdog error message shown above. The Watchdog Handler only does this check once during each scheduled task interval, and it does this check 200µs before the end of the task interval. So in the example above, the Watchdog Handler does its first check 99.8 ms after the start of the task. At that point the task is still stuck in the endless loop, but it hasn't exceeded the watchdog time yet. The second time the Watchdog Handler does its check is 99.8 ms after the second task cycle was supposed to start, or 199.8 ms after the start of the first task cycle - which is still stuck in the endless loop. This time the watchdog time has been exceeded, so we get the error message shown above. The time after the "hung" task started is correctly reported as (very close to) 199.8 milliseconds.

Sorry for the long wait for an answer to this question. I have asked for this explanation to be added to the Info Center.

~ Martin.