DST

mazeeff

Member
It sure would be nice if the PLC had a automatic DST function. My unit was off an hour today, until I corrected the UTC.
 
Nightmare. Every place has different rules for when to change.
And even then, they're not necessarily consistent.

Far better to work in UTC and let the machine that does the displays, work out the local time of the viewer.
 
Day light saving is not fixed, congress keeps changing it, all countries are having different time.  There is no one central place WebControl can check for that. WebControl gets its clock from NTP server, which always uses GMT, not local time.  Hope one day congress will change that DST started from Jan 1st, and end on Dec 31.
 
It is a lot of trouble, if you have lights on timer, or sprinkler on timer and the time change, but WebControl can not pick up that change.
 
CAI_Support said:
Day light saving is not fixed, congress keeps changing it, all countries are having different time.  There is no one central place WebControl can check for that. WebControl gets its clock from NTP server, which always uses GMT, not local time.  Hope one day congress will change that DST started from Jan 1st, and end on Dec 31.
 
It is a lot of trouble, if you have lights on timer, or sprinkler on timer and the time change, but WebControl can not pick up that change.
 
Why not simply allow the PLC to select a optional NTP time server, instead of the default. It would be simple to set up a NTP time server on my own network, using a PC or router. They both picked up the correct DST change, and could serve the time to the PLC.
 
Hi,
 
The later firmware does have that configuration option. In the Network section, you can specify the NTP server IP. If you left that zeros, it will use pool.ntp.org. If you specify anything, it will use the one you specified.  Thanks to Ross' suggestion.
 
mazeeff said:
Why not simply allow the PLC to select a optional NTP time server, instead of the default. It would be simple to set up a NTP time server on my own network, using a PC or router. They both picked up the correct DST change, and could serve the time to the PLC.
 
Won't make any difference.
 
NTP works UTC, timezone offsets are applied at the local OS level.
 
Since NTP server is an open source software, user can modify it to have its UTC adjusted with DST differences.  Then turn off all the DST settings at anything reference to it.  That may not be the best solution, but it would work.
 
Most windows releases share a common core with servers and most all the services are there, they just need to be enabled and configured.

A quick google yields this:

With win xp
http://support.microsoft.com/kb/314054

Click Start, click Run, type regedit, and then click OK.
Locate and then click the following registry entry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\
In the right pane, right-click AnnounceFlags, and then click Modify.
In the Edit DWORD Value dialog box, type 5 under Value data, and then click OK.
Enable NTPServer.

Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer\
In the right pane, right-click Enabled, and then click Modify.
In the Edit DWORD Value dialog box, type 1 under Value data, and then click OK.

Exit Registry Editor.

The Win 7 PC configured as follows:

1. In the 'Services' window(part of Administrative Tools) Stop the 'Windows Time' service if already running. The 'Startup Type' could be set as Manual or Automatic depending on the user needs.

2. In the Registry Editor following changes to be made under the Key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time:

** Config -> AnnounceFlags = 5.

** HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\TimeProviders\NtpServer -> Enabled = 1.

3. Start the 'Windows Time' service in the 'Services' window(part of Administrative Tools).
 
These ideas look like they would work, if I had the latest hardware. I have version 13 hardware, and it does not have the NTP server option.
 
CAI_Support said:
Day light saving is not fixed, congress keeps changing it, all countries are having different time.  There is no one central place WebControl can check for that. WebControl gets its clock from NTP server, which always uses GMT, not local time.  Hope one day congress will change that DST started from Jan 1st, and end on Dec 31.
 
It is a lot of trouble, if you have lights on timer, or sprinkler on timer and the time change, but WebControl can not pick up that change.
After thinking about this for awhile, I beleive that there is a fairly easy way to fix this in my own PLC code. Since we all know when DST takes place (even if congress changes it!), I can write a small piece of code to look for 2am on that day. I can then add a DST adjustment factor into the code. I don't think that I can change the UTC option programmaticly. Is that correct? If I could write code to change from "UTC-5" to "UTC-4", the problem is solved! If I could change the "UTC" option via code, then the clock on the web page would match DST. Otherwise, it would be off by 1 hour during DST, even though my code is adjusting for the difference. Does anyone concur with this logic?
 
If we can have a list of DST starting and ending date, we can make a list and hard code those dates into firmware.  When congress or any other government changes the DST date, we just have to update firmware.  I think we know US DST starting and ending date, how about other countries?  Australia has many different ones, even half hour time zones!
 
Here is a list, but it looks like a real mess, as mentioned previously  The dates change each year, in order to fall on a Sunday. In the U.S., it is the 2nd Sunday in March, and the first Sunday in November. How about just giving us program access to the UTC variable that is user set. It is a easy set of code (under 8 lines of code) for the user to implement. If you decide to hard code it, make sure to add a "tick box" to turn DST on/off. Countries in Africa have different DST rules in the same time zone! Arizona in the U.S. would be a special case as well!!!!
 
http://www.timeanddate.com/time/dst/2013.html
 
PS. The user code is more complex than I thought. I need a easy way to count "Sundays"! What does the variable "CDW (Current Day of Week)' return for Sundays?
 
PSS: Up to 30 lines of code, and still not done. The problem is made more difficult with the fact that you have to account for DST, when you turn on the unit in June! You can not just use the 2nd Sunday in March as a trigger. For example, this year the US started DST on March 10. Next year is March 9. It is pretty easy to trigger on a specific time & date, but more difficult, when you have to determine if you are between two dates, and these dates change every year!
 
PSSS: I give up. There seems to be too many scenarios to think about. The latest issue, is how to handle a PLC that starts up on March 8, after 1 Sunday has already occurred. I can think of no way to handle this.
 
Thanks for that link for DST around the world. It seems most starting from Sunday, some of them starting from Saturday, some of them from Friday.  I agree, that is a big mess.  If we could just provide a checkbox that is stored in EEPROM that DST ON or OFF,  if it is ON, we reduce 3600 second from UTC clock, if it is OFF, we do nothing.  User has to manually set that.  But then, that is same result as manually set the time zone. 
 
It would be really nice if NTP server also provide that DST information.
 
This is like a Rubik's cube from hell! As a retired engineer, I decided to apply the KISS (Keep It Simple Stupid) solution. I have not tested this, but it should work, and takes 31 lines of code to cover 10 years. Two years of code are shown. This will flip DST at midnight, instead of 2AM, but I can live with that. It will also result in the web display clock being off by an hour as well, unless CAI allows us to change the UTC variable by code. Does anyone know where that UTC offset is stored in the PLC? I have two PLC's that control two small Tulip greenhouses, and just want the PLC's to run without human interaction throughout the year. Can anyone do it in less lines of code?
 
 
TSTGE CD 03/10/2013 RAM1
TSTLT CD 11/03/2013 RAM2
AND RAM1 RAM2 CALLSUB DSTON
TSTGE CD 03/09/2014 RAM1
TSTLT CD 11/02/2014 RAM2
AND RAM1 RAM2 CALLSUB DSTON
CALLSUB DSTOFF
 
Great, we just need to implement DSTON and DSTOFF IO identifier. Internally, we will store that into EEPROM each time being called. Then during power on, we will read back that bit.  If the bit is true, we will advance a hour. 
 
Maybe just call the identifier DST, so that when the date is true, PLC will call
SET DST 1
Then the date reached to turn off DST, PLC call
SET DST 0
 
That way, people from anywhere in the world can use your subroutine to set DST on or off accordingly.
 
Back
Top