changing real-time clock values via HMI

Skidood

Member
Join Date
Oct 2016
Location
Ontario
Posts
213
Hi again
Looking to write date or time values to the RTC in my MicroLogix 1400
In the ladder logic I am using a CPW instruction as per the 1400 Instruction Set manual. The data is being stored in an integer file which is updated via the HMI clock adjust screen I made up. The instruction copies N7:22 to RTC:0.YR (for example)
The PLC faulted out when I activated the CPW instruction. The error message said the data was invalid. I need to look into a few things but specifically, for now, I'd like to ask you all, is there an issue with the word length I specified? I set it at 1.
 
Last edited:
Hello,

Looking at the user manual (page 57 in my version) for the 1400 and the stated error message I would guess one of the values is out of range. i.e. year must be 1998…2097.

Me I would try to set only one field and if it worked add more until it fails.
 

Very pleased for you. As this is an information sharing forum, and users frequently search for solutions to their problems, it may be helpful to follow up your 'Solved' statement with details of how you fixed it! :)

I know when i've used the ML1100/1400 RTC function, i have had to manually set the clock initially, then it seems to accept the CPW command to modify it! Maybe you had a different issue?

Regards,

Rob
 
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
 
Last edited:
Whenever I have values to write on a HMI I always check the value with a LIM compare to make sure it is in parameters.

Rarely can just any number be written.

Second & Minute LIM 0 xx 59
Hour LIM 0 xx 23
Month LIM 1 xx 12
Day LIM 1 xx 31 (with checks for 28, 29 & 30 day months)
Year LIM 2019 xx 2099 (I probably won't be around to see that be a problem)
Operator# LIM 100 xx 999
Job# LIM 1000 xx 99999

And especially for timer and counter presets that control the machines.
 
Yes, you can do native limiting on many HMI products, but it's usually best to do it in the controller. Just watch for the year limits you've mentioned as we're dealing with a MicroLogix 1400 controller here specifically...

RTC:0.YR - Range: 1998…2097

So obviously writing 2098 here to "this" controller would fault it. But like you say, you or I need not worry too much about that!

G.
 
Last edited:
Maybe I should have specified, but I do the LIM compares in the PLC when accepting any new entry. I do also put entry limits in the HMI, but don't rely only on them.

Years back I had a SmartA** operator that knew on a Quartech screen, PLC5, if you went to a certain page number, something like page 961, it went to a data entry screen where you could put any file, any address in that file, and any entry to that address.

He could enter file 7 for the integer file, address 43 for N7:43, and enter any number he wanted. High numbers would fault the PLC, out of range numbers were still accepted and crashed the machine. Couldn't do anything about the faulting on a high integer, but did put LIM checks in for every entry to make sure they were in the accepted range.

BTW: in the year 2098 I will be 141 years old and hopefully retired by then.
 
Last edited:
Aabeck said:
Maybe I should have specified, but I do the LIM compares in the PLC when accepting any new entry. I do also put entry limits in the HMI, but don't rely only on them...

No need to. Once you mentioned "LIM" the first time I did understand this to be referencing the LIM instruction in the PLC specifically. My mention of the limiting in the HMI was additional to your LIM advice while pointing out the PLC method is usually the better to rely upon, which we do concur on.

Aabeck said:
...BTW: in the year 2098 I will be 141 years old and hopefully retired by then.

Well "retired", I'm sure. But I like your optimistic outlook on still being around!

G.
 
Thank you very much, I re-arranged my logic.

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
 
Wow you are 62 years old! Any advice to give to young engineers Mr. Aabeck sir.


Learn as much as you can from every field and profession.You never know what unrelated information will help you solve a design or operation problem in the future.


I worked with one technician that finally figured out a problem we were facing by applying some information related to training attack dogs he had done years before. Specifically how air flow patterns happen in structures that move scents for dogs in certain flows, if I am remembering well. Totally unrelated - totally relevant.
 

Similar Topics

I'm being directed to fill process values into an array of DINTs. A portion of the REAL values got copied into 2 DINTs each, but there are more...
Replies
2
Views
2,201
Hi all, I am having an issue where some of my HMI push Buttons and Indicators go in to error when I navigate to a new screen. I am using a...
Replies
16
Views
321
We have a new machine that uses an armor block to transfer input signals for conveyor position that continuously alarms out on no position change...
Replies
0
Views
73
Hello everyone, I am trying to change the IP address of the Omron PLC (NJ30-1200) and HMI (NB7W-TW01B) to fetch the network on our network...
Replies
7
Views
256
Dear Experts, I'm just started working with GEO SCADA and I need your valuable help. Currently, I'm trying to edit the alarm limits on MIMIC...
Replies
0
Views
192
Back
Top Bottom