One thing I realized too late is that the PLCnext is factory-set to the UTC+00:00 time zone. So, when I saw in the WBM that the time was incorrect, I pressed the button in PLCnext Engineer („Write current time to the controller“) without any hesitation. But later, as I was working on a schedule program (Wochenzeitprogramm) in PLCnext, something interesting happened.
The PLCnext communicates with an HMI via the WebIQ Framework, and the time setting is represented as a Unix timestamp (UDINT type). The client sees its local time (UTC+01:00) but sends a Unix timestamp to the PLCnext. To compare this timestamp with the one on the PLCnext, I used some functions from the base library. I mistakenly assumed that the time on the PLCnext was also in local time. As a result, my program never worked properly.
Why not use an NTP server? Not every project allows us to pass through the firewall to make NTP requests.
Why not change the time zone on the PLCnext? You need a root superuser account to do that, and it will likely be reset after a firmware update. (See: https://pxc1.esc-eu-central-1.empolisservices.com/service-express/portal/project1_p/document/en-so-deb95804-1aba-4247-8d77-da744c190b90?context={})
I hope this discussion helps someone who might not have considered this issue.
Hello TeTi,
thank you for your contribution.
At the moment the times are interpreted internally as UTC0.
You can find more information here: System time
You have already mentioned the problems and a workaround.
In the future it is planned to work with two times: UTC0 and UTC0+Offset.
This will make it easier to solve such issues.
At the moment I don’t know the date for this feature, but it is supposed to come.
Thank you Tim,
then I have another question about the client side: the webpanel like WP 6101.
Who will handle the problem with sommer time?