I don’t know if this is a cause or an effect:
Here’s an error message at about the reboot time:
The other thing that’s a little crazy is the date. It shows 3/10 but it’s 3/9 and the system time tab in Settings clearly shows it’s 3/9.
This also appears in the DOW. It’s off by a day. It says today is day 2 which would be Tuesday. What’s going on?
I have attached a copy of my system with all programs.
Ted
Chiller3-9-20.prog (65 KB)
Not really following the issue I guess. The alarm is just showing when it tried to sync time to your time server.
But… it shouldn’t be trying to sync time to the time server since it has always been set to use the local PC. See image below as proof:
Chelsea will check this.
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.
Standing by to help.
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.
I was on firmware 51.5 and T3000 of May 9. So I have just updated both to 52.2 and June 9. My apologies if you did the fix after 51.5.
T
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
Somewhat related, bacnet time sync, where are we on that? Most bacnet networks have a designated time sync panel. Can we do this? Can we receive it?
Jim
I believe time sync is done and working well now.
For background info:
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?
Ted
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.
Ok thank you for clarifying
C: 250.643.3287
E: jim@jetcontrols.ca
O: 778.210.2088
Solving the worlds problems, one building at a time…
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.
