Hoobs

How are you utilizing the NJ watchdog timer?

9 posts in this topic

I would like to explicitly utilize the cpu watchdog timer to not only determine when the CPU is hung/stuck, but then execute a cpu reset.  Other PLCs I have used expose a config setting where you can choose a timelimit for the watchdog timer and, if that time limit is exceeded, there is independent hardware that sees this and causes a cpu reset to occur.

In my NJ501, I see in the docs that there is a watchdog time (WDT), but I can't find any information about configuring it, or utilizing it as part of a state identification and recovery strategy.

Anybody else doing something like this with the WDT?  How?

Thanks!
Hoobs

Share this post


Link to post
Share on other sites

I don't think it's possible. There's no function in NJ to restart the CPU automatically for whatever errors that may happen.
The WDT timeout error also only generates a fatal error that will stop program execution, until the PLC is power cycled / reset manually.

Just my own thoughts... isn't it quite dangerous to let the CPU resets by itself when it's running a machine?

Edited by innoaloe

Share this post


Link to post
Share on other sites

It always depends on the situation.  On my current project, it would be far more dangerous to let the operator continue processing with the PLC hung than with it being reset.  In this particular case the hardware was specifically designed to be handled this way, and if a keepalive pulse generated out of the main loop doesn't arrive on schedule the hardware could also initiate a reset externally.  In either case the hardware correctly locks out the operator console until well after the system is fully backup and a positive status position is established.

Share this post


Link to post
Share on other sites

The watchdog timer is set on the Task Settings screen when the tasks are assigned their cycle time.  But as innoaloe said, it's not something that can be reset from software.  it requires a power cycle.

Share this post


Link to post
Share on other sites

Wow...  that's surprising.  I must be missing something then...  what is it good for as currently implemented?  Without the ability to take asynchronous recovery action, that is not dependent on proper code execution occurring, the WDT doesn't strike me as useful.  What do I not see?

Thanks,
Hoobs

Share this post


Link to post
Share on other sites
On 12/26/2017 at 3:00 AM, Hoobs said:

Wow...  that's surprising.  I must be missing something then...  what is it good for as currently implemented?  Without the ability to take asynchronous recovery action, that is not dependent on proper code execution occurring, the WDT doesn't strike me as useful.  What do I not see?

Thanks,
Hoobs

I cannot really say since I never had experience resetting a PLC system using the Watchdog timer. Did it with microcontrollers, never did it with PLC.

So far the only experience I had with watchdog in NJ is when we are using a Loop (e.g. FOR / WHILE loop) with improper counter variable data type that will cause the program to lock in that loop forever. This will return a Task Execution Timeout error. So I guess the only use of Watchdog is to let you know that your program somehow locked somewhere. Still, tracing the source of locking is a different story.

As for what crossbow mentioned, it is this thing here. Typically the watchdog is set 5 times your task cycle time, but you can choose another multiplier (smaller).
Capture.thumb.JPG.8d14a19e5adc175d8e6bfb

Share this post


Link to post
Share on other sites

Or the processor has failed? No good resetting it then.

Share this post


Link to post
Share on other sites

Typically watchdog timer in PLC is to catch an infinite cycle, like getting stuck in a loop.

Which PLCs have you used that allow a software reset of this condition?  I do not know of any from my experience.

There is a RUN contact in the power supply, which is only closed when the CPU is in RUN mode.  Could you potentially use that to trigger ax external timer and cut power from the PLC for a few seconds??

Share this post


Link to post
Share on other sites

@innoaloe, Thanks for that pointer.  I had discovered this as well, and it does what it is supposed to but, as you state, it's not really what I'm looking for.

@Crossbow, It's been a little while but I remember 6-7 years ago working on an A-B unit that had the type of WDT I was expecting to see on the OMRON units.  This approach to WDT comes from embedded industrial microprocessor control technology of the last couple decades, where an on-board WDT has options for what to do if it gets triggered: full system reset (like a power cycle), reset only some system components (i.e., reset a network port/stack, reset a potentially stuck I/O module, etc.), and/or simply jump to a specific machine instruction address and execute from there.  It's not that software can reset the WDT (which is pretty pointless in most real-world situations because the software is likely not even executing in a predictable manner any more).   Rather,  the WDT has on-board ability to take specified action that can recover the system functionality and allow normal processing to continue from that point forward.  Of course, this requires that the up-front engineering work correctly designs how to identify that the system is in a state that requires the WDT to take action.

I could do the external hardware design you're talking about, it's not difficult, but I was expecting this kind of functionality to be on-board, otherwise the WDT is essentially useless for recovery of a locked-up system.  If I have to do something external I'll instead stick in an IP-controlled switched outlet, and have my production proxy server (which expects a ping from the PLC every 500ms) to use that IP-controlled switched outlet to force a power-cycle.  It's kinda brute force, but it should get the job done.

ASSUMING the implementation bug(s) in the AC_StepProgram instruction don't get in my way (subject of a different thread).  My regional OMRON field engineer is supposed to be here next week so I can show him how the AC_StepProgram instruction is not coming up in a stable state after a power cycle of the PLC, making full recovery/restart of the affected control processes impossible.  If we can get that issue figured out, then I should be able to correctly bring the system back up after a power hit.  If I can get to that point, I can then use that capability to also be the WDT/locked-up recovery approach.

Thanks guys!
Hoobs

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now