There is an errata associated with the "SysTimeRtsSet" but should be only when the IDE is connected to the PLC.

https://docs.codesys-p2cds622.com/en/latest/Errata/rtcsetconnect.html

As long as the PLC is running in standalone mode (not connected to IDE) and the Visualization (utilized via an external WebVisu Browser) has an input button select for "setFwd", "setBack", this should be functional.

Reference:

• https://docs.codesys-p2cds622.com/en/latest/Getting%20Started/webvisu_example.html

Currently setting the RTC clock during application run is not possible without causing this error because it's tied to the Codesys runtime "schedule". So when you change the time ahead (or behind) the system will think that amount of time has passed. We'll update the website to reflect this.

Is this just in place so the user can update the date and time displayed on Webvisu or is there some other functionality you are seeking?

One thing can do is have another date and time variable, say like APP_TIME, that will track and offset the time from the RTC.

Or if you are wanting a constant accurate time, you could use the same technique, but using a NTP server time. You would read the NTP time into an application variable and offset from the APP_TIME.

We apologize for this issue and that we cannot resolve directly.

An "Unsupported Feature" has been generated on the website ( https://docs.codesys-p2cds622.com/en/latest/Unsupported/setrtc.html ).

If it's a viable option for you to utilize the "SNTP" function support, it is discussed here: https://docs.codesys-p2cds622.com/en/latest/Example%20Projects/iiot_sntp.html .

Thanks for looking into this.

I don't know what expected real time clock accuracy would be, but if you think that the life of a plc is 10 to 15 years, at some point the clock will need to be adjusted. Asking a customer to load up codesys on his computer and do "rtc-set" from the PLC shell is not realistic. If you want a timeclock to start something at 12:00, you want it to start at 12:00 not 12:05. This could be handled with calculating an actual time based on an offset from the real time clock and allowing the user or sntp to adjust that offset.

This does not solve the requirement for an accurate clock to to be able to do internet connectivity. Some internet connectivity especially with security needs accurate time to work. I assume this is why most of your plc's now have an easy way to set the clock with SNTP. Having an offset that calculates a actual time won't help with this. Here is what chat GPT thinks about PC clock accuracy requirements:

How much error can my pc clock have before I will start experiencing internet connectivity problems?

ChatGPT said:

Your PC clock can be off by a few seconds without major issues, but if the error grows too large, you might start experiencing connectivity problems. Here’s how different levels of clock drift can impact your internet usage:

1. Small Error (Under 5 Seconds)

• Generally, no issues.
• Secure websites using HTTPS will still work fine.
• Most authentication systems will tolerate minor discrepancies.

2. Moderate Error (5 Seconds to 5 Minutes)

• Some secure websites and services that rely on TLS may fail.
• Authentication failures in time-sensitive applications (e.g., SSO, OAuth).
• NTP (Network Time Protocol) will likely correct the time automatically if enabled.

3. Significant Error (5 Minutes to 30 Minutes)

• Many HTTPS sites and services will fail due to certificate validation errors.
• Cloud services like Google, Microsoft, and AWS might refuse logins.
• VPN connections might fail due to mismatched timestamps.
• Some DNS queries and security features might break.

4. Large Error (Over 30 Minutes)

• Almost all secure connections will break due to TLS certificate issues.
• Many online services (email, banking, cloud storage) will fail authentication.
• Kerberos-based authentication (common in Windows networks) will stop working if the difference exceeds 5 minutes.
• Software updates and package managers might refuse to download updates.

5. Extreme Error (Over a Few Hours or Days)

• NTP may refuse to sync unless forced manually.
• Your system might be flagged as suspicious by some security systems.
• Logs and timestamps will be unreliable, leading to problems in debugging and system monitoring.
• Some websites might outright block access due to security concerns.

Fixing Time Drift

• Enable automatic time synchronization via NTP (on Linux/macOS) or Windows Time Service.
• If you have a dual-boot system (e.g., Windows and Linux), ensure they handle RTC (Real-Time Clock) correctly (Windows expects local time by default, Linux often expects UTC).
• If your CMOS battery is failing, replace it to prevent your BIOS clock from resetting.

Bottom Line

• Try to keep your clock within ±5 seconds of the real time to avoid most issues.
• Beyond 5 minutes, expect trouble with authentication and security-sensitive applications.
• Beyond 30 minutes, internet services may break completely