Hi, I am looking for an update on this time sync problem. Occasionally one of my T3’s sets itself back a day. The time is correct but the date is wrong. It always seems to be the same T3-LB. As luck would have it, that T3 is the one that does a lead/lag switch over on our 2 chillers based on the time and the day of the week. When the T3 updates and the date rolls back a day, then it will run the wrong chiller on Monday’s. My workaround for this problem is to manually check the date almost daily. If it’s wrong I change the time sync setting to “Synchronize with Local PC” and sync it. When the correct date is displayed, I switch it back to “Synchronize with the time server”,
This is really the only bug remaining. They don’t seem to reboot randomly and Bacnet data from one T3 to another comes over the ethernet network on a reliable basis.
Chelsea will see if she can duplicate the issue. Thanks Ted.
You could also put a program line like so:
10 IF+ TIME = 0:0:01 THEN LEADLAG = NOT LEADLAG
Every day just after midnight it will switch the lead chiller. Since there are only two chillers you can use this NOT command which flips LEADLAG from 0 to 1 or vice versa.
Or here’s another way to manually control it:
10 IF DOW = 1 OR DOW = 3 OR DOW = 5 THEN LEADLAG = 0
20 IF DOW = 2 OR DOW = 4 OR DOW = 6 THEN LEADLAG = 1
You could work something out to handle the decision on Sundays, perhaps use a variable to track the run time of each chiller and base it off that.
Update: Chelsea mentions that a leap year issue was fixed a while back as was another issue with daylight savings time under Win10. Just make sure that all controllers on the site have the latest firmware and you should be good.
Just so you know: All controllers in the building will sync to the time & date of the lowest panel ID in the building, usually its Panel 1. If Panel 1 is offline every device will sync to Panel 2 and so on. While discussing this here we see there’s a chance for time sync to get out of whack if you had Panel 1 syncing to a time server and Panel 2 syncing to the Operator station’s PC. We’ll add a dialog to make this more clear and also add some background logic so that all panels in the building follow the same sync source, if you change it to sync to the PC on one panel it will change all panels to match.
I checked all panels in our company, the time are correct. I did fix the leap year issue one or two months ago and T3000 had a fix for handling daylight_saving_time under Win10. Make sure all panels are running the latest firmware and update the T3000 front end as well.
This logic makes sense and its very helpful to know. Now that I know (and understand the possibility for creating problems) I will set the sync-ing accordingly
The panel with the lowest ID is automatically given the task of time sync, set the panel number at Tab1 shown below.
If Panel1 is offline the next higher panel will take care of it.
I have asked the team to add some hover text help to make the user more aware of what is going on behind the scenes here.
Upcoming improvements:
We’ll also do some work on an upcoming release to make the time sync setting universal, all panels in the system will take on the same time sync properties, ie if you set one panel to time sync with time.windows.com as shown at Tab2, all the controllers in the network will also take that setting. Only Panel 1 will normally actually sync to time.windows.com and the rest will sync to panel 1.
I can confirm that the time is running well on firmware 52.2. And the cascading time sync is a brilliant idea as long as everybody knows what’s going on. It’s very helpful when you have multiple panels like we do. Another thing that might not be intuitive for some of us dummies out in the field is the way it seems to handle DST. The time shown in my settings is GMT – 5 which is correct for EST. If the “Automatically adjust clock for DST” is checked, then the TIME variable is changed by one hour to reflect DST but the time displayed in the settings panel is standard time. All that is fine as long as we know what’s going on. Can you just confirm that for us?
Maybe i didn’t explain what I was after.
Bacnet has a time sync function, so on a large network there is a time master. This is not ntp service. So from another bacnet panel or a workstation all the panels can sync.
C: 250.643.3287
E: jim@jetcontrols.ca
O: 778.210.2088
Solving the worlds problems, one building at a time…
Yes, standard Bacnet time sync commands are used to sync the network. ‘Panel 1’ will do this automatically, if it goes offline the next panel will take over.
NTP is only used by ‘Panel 1’ if the user configures it to sync to a time server, otherwise it will grab the time from the PC when the user next logs in.
I just ran into the Time Sync problem again. My lowest panel# is 2 and that’s where the time is right and the date is one day behind. All the other panels have the right date and time. It happened while running firmware version 53.1. To fix it, I have to click on Sync with local PC, sync the time and set it back to “sync with the time server.”
I do not have a panel 1. Panel 2 is my lowest panel. Could that be creating a problem??
Ted
It does not matter whether panel #1 or #2 is the lowest numbered panel in a given system. The system will automatically decide which panel is in charge of time sync and will take care of sending the time, the time zone, and daylights savings info out to the other panels in the system.
Tobedone: Sync the NTP time server details to other controllers as well, one global time setting for the entire system.
I’m trying to get this function to work also, and on the T3-Nano I’m using, I can never get the NTP server function to work.
There didn’t seem to be anywhere to configure DNS servers on the controller. Without that, how is the controller able to resolve the NTP server’s IP address?
Hmm. So, does that mean it can’t be a custom DNS server, and the ones in the list just have their IP addresses hard-coded in the firmware, or does it still resolve DNS, but with a hard-coded DNS server??