Hello everyone, today I’m sharing some pitfalls related to using date and time in PLC programs, especially for newcomers who are prone to making these mistakes. Even after understanding the cause of the issue, many still make errors when fixing programs. In PLC programming, we often encounter functions that rely on dates—specific actions triggered at certain times, such as daily, weekly, or monthly equipment production statistics, or periodic maintenance reminders for equipment components.
After your equipment is delivered and operates normally for months or even over a year, you suddenly receive a call from the customer saying the equipment is malfunctioning. Typically, you’d ask what they changed, and the customer usually insists nothing was touched—it was working fine before and just stopped. When you arrive on-site, connect your computer to the PLC for debugging, you notice the PLC’s date and time are significantly behind your phone’s. You quickly identify that the issue is caused by incorrect date and time settings. The equipment’s time was calibrated during commissioning, so why is it off now? The PLC itself is definitely not faulty, so why does this time discrepancy occur after long-term operation?
To understand this, we need to look at how the PLC’s internal clock works. Like other electronic devices, a PLC relies on a crystal oscillator. Think of the crystal oscillator as a metronome that continuously generates a fixed-frequency waveform. The CPU is driven by this metronome, and the clock is based on it, much like the ticking of a wall clock at home. So why does the PLC’s time drift while a phone’s date and time remain accurate? Phones don’t have this issue, yet PLCs, which are often much more expensive, do. Is the PLC defective?
For Siemens TIA Portal, this shouldn’t be an issue, as the date and time are updated together during synchronization. However, on some other platforms, the date and time commands are separate, which can hide a potential problem. For example, if the HMI issues a time-sync command at 00:00:00, but the PLC executes the time-setting instruction at 23:59:59, an error can occur. The date won’t update, resulting in a one-day discrepancy in the date portion.
To understand this, we need to look at how the PLC’s internal clock works. Like other electronic devices, a PLC relies on a crystal oscillator. Think of the crystal oscillator as a metronome that continuously generates a fixed-frequency waveform. The CPU is driven by this metronome, and the clock is based on it, much like the ticking of a wall clock at home. So why does the PLC’s time drift while a phone’s date and time remain accurate? Phones don’t have this issue, yet PLCs, which are often much more expensive, do. Is the PLC defective?
Since it’s a metronome with a fixed frequency, does that mean it’s always a constant value, like 50 Hz? Of course not. We know that errors can only be minimized, not eliminated, so the date and time in electronic devices will eventually drift over time. Why, then, does a phone’s time always seem accurate? That’s because someone—or something—has already handled the time synchronization for us. Phones are connected to the internet, and a background program periodically syncs with a time server to keep it accurate. However, for devices like car displays, if they’re not connected to the internet for a long time, you’ll notice their time also drifts.Now that we understand the cause, the solution is straightforward. If your PLC supports a time synchronization protocol and has access to a time server, configuring these is the best approach. If these features aren’t available, you can add an automatic time-sync script in the HMI interface. This script can sync the time daily or weekly, as needed, for example, by sending a time-sync command to the PLC at midnight. By adding such a program to the PLC, does that resolve the issue?
For Siemens TIA Portal, this shouldn’t be an issue, as the date and time are updated together during synchronization. However, on some other platforms, the date and time commands are separate, which can hide a potential problem. For example, if the HMI issues a time-sync command at 00:00:00, but the PLC executes the time-setting instruction at 23:59:59, an error can occur. The date won’t update, resulting in a one-day discrepancy in the date portion.
To avoid this, when implementing time synchronization, try to steer clear of these critical transition periods. For instance, syncing when the seconds are at 30 is safer. That’s all for this session. If you found this helpful, please like and follow. If you have questions or want to contribute, feel free to leave a comment or send a private message.