Power Outage Issues

[RBPLC]

I doubt that this is an issue, but make sure $WatchdogReboots is zero. There is a mechanism in the PLC to prevent runaway crash and reboot cycles.

$WatchdogReboots = 0

[BobO]

$WatchdogReboots = 0

Good. Just wanted to rule it out.

If $WatchdogReboots hits 10 (I think) it will drop into program mode on reboot. That prevents an endless boot loop from keeping you out of remote access.

[RBPLC]

Not to tell you your business but it looks like the issue is somehow tied to the Sys log entries/common logic.

I had two slaves on this setup that were always offline. I removed these to see if that could potentially be causing it to not go back to RUN (even though they appeard to be configured properly). After removing, I REBOOTed again and no dice. Same Program mode, no retention.

After doing this, for the heck of it, I cleared the Sys log entries. I then REBOOTed and this time, the retentive bits mentioned above keep their state as expected and the controller returned to RUN as expected.

The UDT issue I'm still trying to track down to see if that's on me. The retention and RUN appear to be correct now.

[BobO]

Not to tell you your business but it looks like the issue is somehow tied to the Sys log entries/common logic.

I had two slaves on this setup that were always offline. I removed these to see if that could potentially be causing it to not go back to RUN (even though they appeard to be configured properly). After removing, I REBOOTed again and no dice. Same Program mode, no retention.

After doing this, for the heck of it, I cleared the Sys log entries. I then REBOOTed and this time, the retentive bits mentioned above keep their state as expected and the controller returned to RUN as expected.

The UDT issue I'm still trying to track down to see if that's on me. The retention and RUN appear to be correct now.

Oooh....that does give me some clues...

[RBPLC]

Not to tell you your business but it looks like the issue is somehow tied to the Sys log entries/common logic.

I had two slaves on this setup that were always offline. I removed these to see if that could potentially be causing it to not go back to RUN (even though they appeard to be configured properly). After removing, I REBOOTed again and no dice. Same Program mode, no retention.

After doing this, for the heck of it, I cleared the Sys log entries. I then REBOOTed and this time, the retentive bits mentioned above keep their state as expected and the controller returned to RUN as expected.

The UDT issue I'm still trying to track down to see if that's on me. The retention and RUN appear to be correct now.

Oooh....that does give me some clues...

I didn't have a good Memory Image and that's one issue that was throwing me off. I fixed my Memory Image and have backed it up. This was my UDT memory backup. Since getting the Memory values right, I've REBOOTed multiple times and all UDT retention seems to be correct.

I'm almost positive whatever the issue is was messing with the UDT retention as well and not some errant pointer overwriting values unknowingly.

[BobO]

I didn't have a good Memory Image and that's one issue that was throwing me off. I fixed my Memory Image and have backed it up. This was my UDT memory backup. Since getting the Memory values right, I've REBOOTed multiple times and all UDT retention seems to be correct.

I'm almost positive whatever the issue is was messing with the UDT retention as well and not some errant pointer overwriting values unknowingly.

I can't see any issue and none of this code has changed since day 1 of 205 Do-more. Still, it's interesting. The last PLC mode (that gets restored on powerup), the image reg, the system log, and
and a bunch of other things are all packed into the battery backed ram. If a pointer got loose (OS, not logic) and started spraying over that area any/all of those things could happen. I don't see how clearing the SysLog would affect anything else, unless the SysLog buffer logic got dumb and the log entries were getting stuck elsewhere.

Does your logic use any MEMCLEAR instructions with UDTs?

[RBPLC]

I didn't have a good Memory Image and that's one issue that was throwing me off. I fixed my Memory Image and have backed it up. This was my UDT memory backup. Since getting the Memory values right, I've REBOOTed multiple times and all UDT retention seems to be correct.

I'm almost positive whatever the issue is was messing with the UDT retention as well and not some errant pointer overwriting values unknowingly.

I can't see any issue and none of this code has changed since day 1 of 205 Do-more. Still, it's interesting. The last PLC mode (that gets restored on powerup), the image reg, the system log, and
and a bunch of other things are all packed into the battery backed ram. If a pointer got loose (OS, not logic) and started spraying over that area any/all of those things could happen. I don't see how clearing the SysLog would affect anything else, unless the SysLog buffer logic got dumb and the log entries were getting stuck elsewhere.

Does your logic use any MEMCLEAR instructions with UDTs?

There are no MEMCLEAR instructions used with UDTs.

[BobO]

There are no MEMCLEAR instructions used with UDTs.

We had a bug in MEMCLEAR with UDTs where in certain circumstances it could get loose and go places it shouldn't. It was fixed, but I was just trying to rule it out as the source of trouble.

At this point I'm not sure where to go. Clearly something got loose in your retentive memory and clearing the SysLog seems to have cured it. I wasn't able to dupe any weirdness though and until we can there's nothing to fix. If it shows up again we can poke at it some more. Problems like this are frustrating for both of us.

[franji1]

Are you using the Memory Image Manger with UDT based Regions?

If you have modified the UDTs without deleting their Memory Image Region on the Disk Project, that data in the disk project is corrupt, i.e. you modified the UDT's memory layout, added fields, moved fields around, changed field data types, changed data sizes, of any field in a UDT.  The Memory Image Region is just RAW data, so if you write that Region on top of the new UDT schema layout, it will not be correct/valid.

[RBPLC]

Are you using the Memory Image Manger with UDT based Regions?

If you have modified the UDTs without deleting their Memory Image Region on the Disk Project, that data in the disk project is corrupt, i.e. you modified the UDT's memory layout, added fields, moved fields around, changed field data types, changed data sizes, of any field in a UDT.  The Memory Image Region is just RAW data, so if you write that Region on top of the new UDT schema layout, it will not be correct/valid.

I had not been using the Memory Image Manager to restore any memory elements. I probably did have a bad memory copy but I didn't attempt to restore from it at any point while the above was going on.