I’ve been testing your TSTAT10 units for a bit and have found a few issues, all correctable.
Setting time seems to an issue and varies between hardware rev 4 and rev 5. Rev 4 will sync time correctly and apply the proper time zone offset. Rev 5 will always correct the time to be 1 hour off, regardless of any other setting. If I set a -8 time zone, with Daylight savings time enabled or disabled, doesn’t really matter it seems, if I sync the time with my local PC and it’s 09:47 the unit will adjust it to 08:47 when it shouldn’t. Only happens on the hardware rev 5 unit. Both units running 61.9 firmware and updated using the t3000 interface. Not sure why the hardware rev would impact this but it does.
When executing the following:
80 ST = TIME
I expect to see a value no larger the 2359.59 and no smaller than 0000.00. On both unit I get a value that seems to be way out range. ST is a variable that I added to store the system time for further use in the program. Program is useless at this point because the time variable is not getting evaluated correctly.
For instance at the time of this email 09:58 the system time variable ST shows 39438.0. This number seems way out of range. It should read 958.00. Cant seems to draw any correlation between the 2 values at all.
Any suggestions on this? I can deal with the actual unit time but the evaluation of TIME is an issue. I need 09:58 to return 958.00
1 Like
Hi Scott,
Just a thought, you mentioned the TSTAT identified as being 1 hour less that programmed, could the number of 39438 be seconds since midnight as that would be 10 hours 57 minutes 18 seconds?
There’s a thought. Makes way to much sense. I’ll take a look. A little documentation on this would save time.
Thanks
SCott
That’s defnitely what the TIME command is returning just an hour off. I’ll see if I can rectify that. Not exactly what the documentation has to say about the time function.
Scott
Given the limited programming functions turning turning the 12.595 value into the proper minutes value becomes a challenge. A Rounding function would help to split off the .595 so it could be multiplied by 60 to get the exact minutes. It seems the TIME function is not converting the seconds since midnight into the format hhmm.ss properly
I’m having the same issue with the time on my Tstat-10 devices as well as my BB and two LB units. I had to find a different time zone that worked for time display but all schedules remain an hour early regardless of DT being selected or not. All devices have the latest firmware available.
Interesting about the hardware version issue you discovered.
While the display on the t3000 is one hour off that actual system time is correct for programming purposes
SL
1 Like
We did a firmware update which helped some folks out but there’s still an issue out there somewhere with windows 10 and time keeping. Some systems show time correctly and others show it one hour off. My suggestion to the client is for now let the NTP time sync take over. If you have issues with NTP time sync using the latest firmware you can let us know. We’re digging into why win10 is reporting the time off by one hour, there’s a know issue there somewhere.
Update: The win10 issue has been fixed, time offset of one hour on some systems is no longer an issue. Please update to the latest firmware and T3000 front end.
1 Like