Siemens S7/TIA v18: Wall clock time (again)...

[Mas01]

Should I choose this option for the download?

 

[mk42]

Should I choose this option for the download?

Yes. Doing both at the same time really doesn't have any downsides, unless you consider stopping the PLC as part of the HW DL a downside.

 

[Mas01]

This is what I did:
1. Went Offline and Stopped the CPU.
2. Compile > Hardware (rebuild all)
3. Compile > Software (rebuild all)
4. Download to device > Hardware Configuration.

Then I went back Online and put CPU to RUN, but still the monitored time is 1hr ahead of what it should be.


I'm clearly being thick and doing something wrong here.

 

[drbitboy]

https://www.youtube.com/watch?v=2qB0aFzCQyY


If you set the PLC time using your local time but before fixing the time zone from UTC+1, and then the PLC system time (RD_SYS_T) was off by 1h, but you never noticed because you were on DST so the DST offset may have canceled the system time offset. When you then fixed, per @mk42's comment, the time zone to be UTC+0, you lost the offset. Or summat like that (I think I am saying the same thing that @mk42 said about six posts ago).

Anyway, if that is what happened, then the example Hegamurl experienced (or arranged for purposes of explanation) in the video above is essentially the same situation you are experiencing, and you should be able to fix it the same way he did.

Bottom line: there is one base time in the PLC, and that is the system time. RD_SYS_T reads that time with no correction for time zone or DST. RD_LOC_T is an offset from system time that uses time zone and DST. When you set the time, via either from the PLC or by manually entering a time, in the [Set Time] window of the online diagnostics ([Online Access] => [DisplayLink Network Adapter ...] => [time of day.profinet...] => [Online and Diagnostics] => [Functions] => [Set time]), I suspect the online diagnostics interpret the entered time as a local time, and use the curent time zone and DST settings in the PLC to back-calculate a system time, and then use that back-calculated value to update the PLC system time. It's all about the bookkeeping.

Sidebar/thought experiment: if we assume that last paragraph is an accurate reverse engineering of the PLC time system, then what happens if we update the time on the PLC halfway between 2am and 3am local time on the day when the clocks fall back? How would the PLC know whether it was the local 2:30am before the change or the local 2:30am after the change?

 

[Mas01]

https://www.youtube.com/watch?v=2qB0aFzCQyY


If you set the PLC time using your local time but before fixing the time zone from UTC+1, and then the PLC system time (RD_SYS_T) was off by 1h, but you never noticed because you were on DST so the DST offset may have canceled the system time offset. When you then fixed, per @mk42's comment, the time zone to be UTC+0, you lost the offset. Or summat like that (I think I am saying the same thing that @mk42 said about six posts ago).

Anyway, if that is what happened, then the example Hegamurl experienced (or arranged for purposes of explanation) in the video above is essentially the same situation you are experiencing, and you should be able to fix it the same way he did.

Bottom line: there is one base time in the PLC, and that is the system time. RD_SYS_T reads that time with no correction for time zone or DST. RD_LOC_T is an offset from system time that uses time zone and DST. When you set the time, via either from the PLC or by manually entering a time, in the [Set Time] window of the online diagnostics ([Online Access] => [DisplayLink Network Adapter ...] => [time of day.profinet...] => [Online and Diagnostics] => [Functions] => [Set time]), I suspect the online diagnostics interpret the entered time as a local time, and use the curent time zone and DST settings in the PLC to back-calculate a system time, and then use that back-calculated value to update the PLC system time. It's all about the bookkeeping.

Sidebar/thought experiment: if we assume that last paragraph is an accurate reverse engineering of the PLC time system, then what happens if we update the time on the PLC halfway between 2am and 3am local time on the day when the clocks fall back? How would the PLC know whether it was the local 2:30am before the change or the local 2:30am after the change?

Many thanks for this, @drbitboy.

I'll be sure to watch that video. I'm already subscribed to Hegamurl on YouTube, as I find his videos really useful.
Cheers.

 

[mk42]

How would the PLC know whether it was the local 2:30am before the change or the local 2:30am after the change?

That is a frightening question and reminds me of one of my favorite programming stories


https://www.joelonsoftware.com/2006/06/16/my-first-billg-review/

 

[Mas01]

That is a frightening question and reminds me of one of my favorite programming stories


https://www.joelonsoftware.com/2006/06/16/my-first-billg-review/

I think the equally frightening thing is the thought of Bill Gates using the F-word during meetings!

 

[Mas01]

I think we're all sorted now, thanks to the video link provided.

Once I ticked the box "Take (time) from PG/PC", the PLC time matched the wall-clock time.

The HMI is now showing the correct time.

Thanks

 

[Puddle]

To help with this, I usually set up NTP for anything that has a permanent network connection.

List of IP addresses here: https://tf.nist.gov/tf-cgi/servers.cgi

 

[Mas01]

To help with this, I usually set up NTP for anything that has a permanent network connection.

List of IP addresses here: https://tf.nist.gov/tf-cgi/servers.cgi

There's no plans (at the moment) for my application to be connected to a network, but if it is, I'll bear this in mind. Thanks @Puddle.