Introduction
If you are installing safety I/O modules in an RIO drop, the current time needs to be configured for the PAC. This can be accomplished in three designs with CPU firmware 3.10 or earlier:
Remote NTP server design with CPU as NTP client: Configure a device in the Control Network as an NTP server, then configure the safety CPU as the NTP client.
Local NTP server design: Configure the safety CPU as the NTP server for devices on the Ethernet RIO network.
Remote NTP server design with eNOC or eNOP: Configure a device in the control network as an NTP server, then configure a module - either BMENOP0300 or BMENOC0301/11 communications modules - in the local main rack and enable the optional feature in the corresponding DTM. If RIO drop with safety devices are configured, configure the safety CPU as an NTP server as described in case 2 above.
In either design, you also need to:
Enable the NTP service.
Set the NTP polling period to 20 s.
If the safety CPU is not configured as either an NTP server or an NTP client, as described above, the time settings of the remote safety I/O modules and CPU will not be synchronized and black channel communication will not operate properly. Inputs and outputs of safety I/O modules in RIO drops will enter the safe (de-energized) or fallback state.
CAUTION | |
---|---|
Schneider Electric recommends that you configure two NTP sources. These can be configured in a redundant fashion with one set as the primary and the second as the standby time server. Both servers however should be time synchronized. Any time adjustment equal to or greater than 2s in any NTP polling period will cause the CPU and the Safety IO modules to be de-synchronized and drift from the NTP time server.
Changing the NTP Time Setting During Operations
CAUTION | |
---|---|
Changing the time during operations can cause a loss of communication and a safety system shutdown.
Changing the time during operation can cause a time de-synchronization with the reference clock. It can also trigger a loss of the safety communication causing the I/O to enter their fallback or safe state. Monitor your system for the occurrence of de-synchronization, and if it occurs restore synchronization to avoid communication loss. If such a de-synchronization occurs, use the following procedure to re-synchronize the system.
If you are using Control Expert V14 or later and using CPU firmware 2.80, 2.90, or 3.10: It is possible to change the time setting in the NTP server or the CPU during operation without a negative impact. Perform this operation by following the procedure set forth below immediately after a time modification.
Refer to the topic NTP Tab in the Modicon M580 Hardware Reference Manual for information on how to configure the NTP service for an M580 CPU.
Procedure for Synchronizing the NTP Time Settings
When power is cycled to the CPU, or the CPU is reset, and the CPU initially receives a time setting from an external NTP server, use the following procedure to synchronize CPU time.
CAUTION | |
---|---|
The following procedure is valid with the SAFE task in RUN state, using Control Expert V14.0 or later and CPU firmware 2.80, 2.90, or 3.10:
Step |
Action |
---|---|
1 |
Check that CPU or external NTP server time is valid, healthy and stable. |
2 |
If the configuration includes one or more eRIO drops, after the NTP service is operating again or after the time modification (which led to the de-synchronization), wait for 2 NTP polling periods to allow the new reference time value to be sent to all CRA modules. |
3 |
Synchronize the system time on the reference clock using the %SW128 system word:
|
4 |
Check that the time is synchronized, by verifying that the parameter values for CPU_NTP_SYNC and M_NTP_SYNC in safe IO DDDT are true (1) |
If this sequence of synchronization is not properly executed, execute it again.
NOTICE | |
---|---|
During the step 3 time synchronization operations, some diagnostics of the safe communication are disabled for a duration of 500 ms. Schneider Electric recommends a maximum of one time modification and synchronization per day.
NTP Service for Peer-to-Peer Communication
The safe Ethernet PAC-to-PAC communication requires the synchronization of the time base of both the sender and receiver PACs.
The following figure describes the sender and receiver PACs time base synchronization principle:

In Control Expert, configure the NTP service parameters for each client as follows:
Select
.Set the
to the IP address setting for the remote NTP server.Schneider Electric recommends a
value set to 20 seconds.
NTP Server Time Consistency and System Bits
NTP server time consistency:
If the NTP server time is consistent with the internal PAC time displayed by the EF
S_SYST_CLOCK
with less than 2 seconds difference, then the time value in the EFS_SYST_CLOCK
is updated with the last NTP server time received filtered with a slope of 1ms/s.If the received NTP server time differs from the internal PAC time displayed by the EF
S_SYST_CLOCK
by more than 2 seconds, then:the last received NTP server time is ignored by the PAC,
the time value displayed by the EF
S_SYST_CLOCK
is refreshed internally,the
status
parameter ofS_SYST_CLOCK
is set to 0, andthe output parameter
SYNCHRO_NTP
from theS_RD_ETH_MX
and theS_WR_ETH_MX
DFBs is set to 0 to indicate this condition.
In this case, you can reset the internal PAC time by taking one of the following actions:
reinitialize the application by a cold start
download the application
restart the PAC
follow the steps for changing NTP time settings.
NOTE: If the NTP synchronization is lost on one of the two PACs (SYNCHRO_NTP
parameter set to 0), both sender and receiver PACs time base can be de-synchronized. In this case, the safe peer-to-peer communication may cease to be operational (S_RD_ETH_MX
DFBhealth
output parameter is set to 0).