Time change didn't happen on the forums (or my Do-more either).

[Mike Nash]

I just noticed my forum time was an hour ahead. I have the preference for automatic, my local PC clock is right, but I had to set it manually to -1 hr to get it to display CST.

Also, is there a configuration switch to enable DST change automatically on the Do-more, or is it up to me to set/reset the Summertime bit?

[BobO]

Not sure about the forum.

Controller is manual. PLCs stay in service for a long time and the laws here and abroad are subject to change.

[Mike Nash]

Controller is manual. PLCs stay in service for a long time and the laws here and abroad are subject to change.

I thought that might be the case. I'm sure the time change is quite a hassle for all the data collectors, never mind night shift concerns.

But may I request some consideration be given at some point to an instruction box that we can configure easily? Date and time to change and internal logic to prevent getting stuck in the fall DST to non DST changeover. I personally rarely need it, but occasionally it comes up.

(One of our guys had a glitch on a Do-more data collection PLC recently due to the time change.) Thanks.

[BobO]

I like that approach. Instruction allows us to do the work but keeps us from being responsible for when.

[Dean]

Bernie taught me this one.

[franji1]

Bernie taught me this one.

Bernie is a sharp guy.  Here is the English prose of Bernie's straight forward logic (from https://www.nist.gov/pml/time-and-frequency-division/popular-links/daylight-saving-time-dst):

Begins at 2:00 a.m. on the second Sunday of March and
Ends at 2:00 a.m. on the first Sunday of November

[Mike Nash]

I like the simplicity of that code snippet, but it won't work if the PLC is not in run mode at the transition minute.

Please correct me if I am wrong!

[franji1]

I like the simplicity of that code snippet, but it won't work if the PLC is not in run mode at the transition minute.

Please correct me if I am wrong!

You are correct.

[Controls Guy]

You'd need to range check it continuously.   For example, what I do when I want to do something once a day, let's say presumably at midnight, is to record the last day-of-month upon which the task was performed.  If current date is different, do the thing and update the last date register.  That way, the PLC being off at midnight doesn't skip the task (though it still only gets done once if the PLC is off for a week, say)

[b_carlton]

I believe that this expansion should pick up most possibilities of time that the system is turned on. I'm sure some compression could be done with creative use of math for the tests of other days of the week possibly following the Sunday change.

[Dean]

Hadn't thought about that possibility. Just added a pair of buttons to the password protected maintenance screen labeled DST, and ST. Off to put a note in the SOP revision file, and tell the maintenance guys. 

[Mike Nash]

I believe that this expansion should pick up most possibilities of time that the system is turned on. I'm sure some compression could be done with creative use of math for the tests of other days of the week possibly following the Sunday change.

Old I know, but I decided to "steal" your code and noticed that the "fall back" month is October rather than November.
I changed:
 $Now.Month<=9 to <=10 in Rung 1
 $Now.Month=10 to =11 in Rung 2
 $Now.Month>10 to >11 in Rung 2

Thanks for the code Bernie!