It is not always advisable to implement access to the local time of a certain time zone via the CODESYS runtime. 
This article considers more background and details on this, and the following application examples and topics are addressed:

General

The time used in a CODESYS controller is always in Coordinated Universal Time (UTC). Also in the programming interface, e.g. in the device logger, the time is displayed in UTC.

On the other hand, users always want to have their local time displayed, adapted to their own time zone and taking into account summer/winter time.
This often results in the desire to set the time and the time zone of the controller from the CODESYS application.

The CODESYS runtime also provides various functions for this purpose.

Please consider the advantages and disadvantages when setting the time and time zone.

Overview  of possible reasons:

  • Not all controllers support setting the time zone equally.
  • Other processes on the controller (apart from the runtime) cannot cope with setting the time/time zone. Many processes in an operating system need a continuously running time.
  • Switching between summer and winter time (and vice versa) must be done manually.
  • In a network with multiple controllers, the clocks do not run synchronized.
  • Users may not have the necessary rights in the application (restricted by the operating system or CODESYS user management) to set the time.
  • Depending on the operating system, other functions must be called so that the hardware RTC is also set.

Setting the time and time zone within the controller

There are the following possibilities to set the time and the time zone of a controller.
The listing is in descending order:

  • Use NTP server

If there is an internet connection, an NTP server should be used if possible. There may also be a local infrastructure that provides a time base.

Advantage:

    • All controllers in the network run synchronized with the same time.
    • The time zone corresponds to the "local" time zone, depending on the NTP server used.
    • Switching between summer and winter time, and vice versa, is automatic.

  • Setting the time via the operating system

Some operating systems offer their own option for setting the time and time zone via a graphical interface or (shell) commands.

  • Setting the time from the CODESYS application

    • Some operating systems offer a number of (shell) commands that can be used to set the time and time zone.
      These commands can be called with the function SysProcessExecuteCommand or SysProcessExecuteCommand2.

      Not all shell commands are allowed on the runtime systems!
      These are often restricted by the Controller's Original Equipment Manufacturer or by end customers for security reasons!

    • If all these possibilities are not available, the time can be set only with still help of the Sys-Functions:
      • SysTimeRtc.SysTimeRtcSet
      • SysTimeRTC.SysTimeRtcHighResSet

Disadvantage:

      • The time must be set manually with each summer/winter time change.
      • Or UTC is always used.

        UTC does not have to be reset for summer/standard time switching!

        This concerns only the case with the conversion of UTC to local time.
        The summer/standard time 'Switchover times' must be taken into account here!

Setting the time and time zone at the operating system level

Windows

On Windows systems, the time zone can be set by a simple click on the clock in the SysTray.
The operating system takes care of setting the current time and changing from summer to winter time and vice versa.

Linux

Setting the time zone

Depending on the distribution used, a configuration tool for setting the time zone is also available here.
If a configuration tool is available, then only this should be used for administration.

If no tool is available, then this can be realized only over Bash commands.


To set the time zone, date and time, the user must be logged in as root.

The available time zones are stored in the directory /usr/share/zoneinfo, e.g. /usr/share/zoneinfo/Europe/Paris for CET/CEST.

To set the time zone, you need to set a symbolic link to the time zone:

ln -sf /usr/share/zoneinfo/Europe/Paris /etc/localtime

After that, the link should look like this:

cd /etc
ls -l localtime
    $ localtime -> /usr/share/zoneinfo/Europe/Paris

In the next step, the system time should be set.
First can check this with the following command:

date
    $ Tue May 15 14:05:49 CEST 2018
date -u
    $ Tue May 15 12:05:49 CEST 2018

'date' returns the date, time and time zone.
With the -u option, the time is output in UTC.

Otherwise, the local time is given.

If the time is not correct, then it can be set as follows:

Local timezone
date -s "2018-05-15 15:00"
UTC
date -u -s "2018-05-15 13:00"

Show current setting of the hardware clock:

hwclock --show
    $ Tue May 15 12:19:44 2018 0.000000 seconds

Then set the hardware clock to the previously set system time:

hwclock --systohc

Check the settings:

hwclock --show
    $ Tue May 15 14:19:44 2018 0.000000 seconds 

Configuration of boot scripts

When booting, the software clock is set after the hardware clock.
To do this, the boot scripts must know whether the hardware clock contains UTC or local time.

In many distributions this can be set in an admin tool, e.g. YaST.

Typically, a shell variable GMT="u" is set for UTC or GMT="" for local time.

The idea is that at boot time either

hwclock -su

or

hwclock -s

is executed, depending on whether the hardware clock is set to UTC or local time.
After these settings, all time information should be correct.

Definition and use of the time zone in the application

In the application, it is often necessary that there is access to use the local time of a certain time zone.

The following FAQ article covers this, How to: Applicative use of the time zone (Util-Lib).




See also....


  • No labels