Just be careful when writing to the MicroLogix Real Time Clock (RTC). There are a couple of good practice rules you should try to follow. One of them springs to mind after viewing your screenshot above...
Documented references to the RTC registers tend to list them as follows - (leaving out Day of Week)
Year
Month
Day of Month
Hours
Minutes
Seconds
Or...
Hours
Minutes
Seconds
Year
Month
Day of Month
...or variations thereof.
The above can depend on where you are referencing but one thing is usually certain; Month is listed before Day of Month. When users then set up their CPW type RTC logic they tend to follow the prescribed lists above or at least, will nearly always end up with the CPW instruction to Month preceding the CPW instruction to Day of Month, which we'll just refer to as Day hereafter. This logical order is typical and as your screenshot suggests above.
However, even though the Instruction Set Reference Manual describes a possible Major Fault 44h - Invalid Write to RTC Function File, and how it may be thrown by writing to the RTC registers outside of the listed ranges; there is another invalid scenario it monitors for...
If, for instance, we are at Jan 31st, and we CPW the Month to Feb before we CPW the Day to the 1st, then the processor will fault as the RTC knows that Feb 31st is an invalid date. Here, we must First CPW the Day to the 1st, and then CPW the Month to Feb.
Further, as we are in Feb 2019 now, and this year not being a leap year, there are only 28 days in Feb this year. So only up to Feb 28th is valid for 2019. 2020 is the next leap year where there will be 29 days in Feb. So next year up to Feb 29th will be valid.
So for this reason you should always CPW the RTC values in the order Day, then Month. This would also go for the order used in other methods, such as Message (MSG) instructions writing to the RTC. If allowing users to manually input time and date values on a HMI, you should also limit the enterable value ranges to prevent accidental faulting of the processor.
I'm not saying this has anything to do with your temporary issue you had here. All I can say on that, and what info you have provided so far, is that "28 for the Month" would not be an invalid value for any month of any year. There will always be a minimum of 28 days in any calendar month. Unless you mean you had somehow gone outside the valid 28 days for Feb 2019? If you think so, then yes, we may very well be back around to the issue of the logical order of your CPW instructions.
If you were changing the date around while testing, and had transitioned say back to any of Jan 29th/30th/31st, and then changed back to Feb for Month, while leaving the Day, then your logic may fault the processor.
I would strongly advise you to change the CPW order from Month/Day to Day/Month, and apply limiting. That is if my viewing of your screenshot is correct. If you like, you could leave your logic "as is" and test first to see if what I am saying proves true or not for you.
Regards,
George