Program did not terminate correctly

[mhw]

One of my customers called last night and had a motor that would not stop. I logged in and found that the program code block had ended but the out coils did not go off and timers did not clear. I restarted the program block and then activated the bit that executed the "exit" instruction and it terminated properly.
This project has been in use for several months but when I logged in the "Initialize cleared PLC" dialog box appeared. However the PLC time is correct and the program matches what I have on the disk.
What happened?

[plcnut]

Was the CPU was still in RUN mode?

[mhw]

Was the CPU was still in RUN mode?

Yes

[BobO]

Sounds like a memory corruption. Any chance that with the crazy weather lately, they may have had some bad power?

[mhw]

Sounds like a memory corruption. Any chance that with the crazy weather lately, they may have had some bad power?

Always a chance, even in good weather. Is this self healing? Any recommendations on prevention?
FYI, this is a terminator with a DC power supply. Is the DC powered base more or less susceptible?

[BobO]

It sounds like retentive memory got smacked. Both the failed termination and the setup prompt would both be indicative of that. To the extent that nothing in the retentive memory was truly critical, yes to an extent it is self-healing. You might also check the system log to see if there is any indication of the retentive memory being reinitialized. I'm thinking probably not, but it would be another clue if so.

As for Terminator supplies and susceptibility, I don't really know. That's Koyo's design and I don't have any specific knowledge of issues. I remember a 205 supply that was notoriously bad and was subsequently replaced, but that was many years ago. At Host, we try pretty hard to build these things strong, but noise is a quirky beast at times. Good practices and power conditioning are always welcome, but we've really not heard anything to suggest that either of the Do-more CPUs are particularly sensitive. I guess with the fairly long I/O configuration, the backplane could become a nice antenna, but again, I'm just speculating.

If it happens again, please let us know. If there were some kind of firmware bug where we went ripping down through memory, it could cause a similar symptom.

[mhw]

In the PLC's event logs it shows that the system was powered off and then power on 5 seconds later. This was shortly before he called me.

[BobO]

So you have a log and no initialization entry, so the retentive memory wasn't wiped. It does appear that that PLC rebooted though. Please check the contents of $WatchdogReboot and $WatchdogReboots.

[mhw]

Please check the contents of $WatchdogReboot and $WatchdogReboots.

Off and 0

[BobO]

Which points to it being a true power cycle rather than reboot due to a watchdog. Since the watchdog counter is in the retentive DST range, it could have been zeroed out same as the clock initialization prompt, but the bit shouldn't be dependent on memory retention.

Is the program block in question set as retentive? If it isn't, but any values you are expecting it to reset during termination are, then a power cycle would end up turning off the program without terminating, leaving the those other values set.

[mhw]

Is the program block in question set as retentive? If it isn't, but any values you are expecting it to reset during termination are, then a power cycle would end up turning off the program without terminating, leaving the those other values set.

No the program block is not set to retentive. Normally I change C and T memory to not be retentive, to match the way that DL used to be, but this one must have slipped through.

[BobO]

That answers why the motor hung, but doesn't answer why the clock set prompt came up. I'm betting those two may be different issues.