Configuring a SIMATIC S7-400 as SNTP Server to Clear SINAMICS S120 Alarm A1097

1. Problem Overview: Alarm A1097 on SINAMICS S120

SINAMICS S120 firmware raises alarm A1097 when the NTP/SNTP client function inside the Control Unit (CU320-2, CU310-2, CU305, etc.) cannot complete a time synchronization handshake with the configured server. The drive logs the alarm in its alarm buffer and the drive time-of-day clock continues running on the last accepted value. The user-visible symptom is:

• Drive alarm buffer: A1097 (N) NTP server cannot be reached
• Status word / r3102 indicates the NTP server state as not synchronized
• Time stamping in the SINAMICS alarm log drifts from the controller time

The alarm is reported as a warning, not a fault, but it disables the auditable timestamp chain that the higher-level S7 expects from a synchronized drive fleet. Most cases reported against an S7-400 acting as the server root cause back to one of three categories:

1. The SNTP server FB on the PLC is not actually listening on the expected UDP/123 socket (LocDevID/port mismatch, OUC connection not opened, FB not enabled).
2. The S120 NTP client is configured against an IP that does not match the PLC port on which the FB is bound.
3. Network path or ACL filters drop UDP/123 between the Control Unit and the S7-400 CPU port.

2. Architecture and Protocol Stack

The Siemens SNTP server library for SIMATIC S7-300/S7-400 implements a stripped-down SNTPv4 server on top of the standard ISO transport / UDP open user communication (OUC) primitives. The relevant stack is:

The server function uses passive open user communication. The S120 NTP client initiates the request; the S7-400 server replies from the same port 123 socket. The library FB therefore does not require firewall punches beyond UDP/123 between both devices.

3. Affected Components and Required Firmware

4. Prerequisites

1. The S7-400 CPU is fully commissioned: hardware configuration loaded, IP addresses assigned per port, time-of-day set to UTC or local with the correct time zone configured in HW Config (CPU properties → Time-of-day → Time zone).
2. The S120 Control Unit is online and accessible from Starter/Startdrive. The drive must not be in an active fault state that blocks parameter writes (clear F-class faults first).
3. Network connectivity is verified with a simple ping from the S120 service interface or from a PC in the same subnet to the S7-400 port that will host the SNTP server.
4. The library 82203451 is unzipped and imported into the STEP 7 / TIA project. The library supplies:
   • FB1000 SNTP_SERVER
   • DB1000 as the instance DB template (copy per server instance if multiple ports are used)
   • UDT 1000 for the configuration structure
   • Helper FBs for time conversion
5. User rights to load the modified program into the CPU and to perform a CPU restart (OB100 logic requires a restart to take effect on the Startup reset path).

5. SNTP Server Library Setup on the S7-400

The library's example project demonstrates the canonical wiring. The four required calls are summarized in the table below; each must be present for the FB to leave the initialization state and accept client requests.

5.1 Marker bit M1.0 explained

The Enable input on the FB is a standard BOOL. The library example hard-wires it to M1.0. There is no reserved or special meaning; the engineer can route it to any BOOL, e.g. M1.0, DB1000.Enable, or a tag from a user HMI. The bit must remain TRUE while the server is required.

6. LocDevID Selection per CPU Port

The LocDevID input on the FB tells the S7-400 communication stack which integrated Ethernet interface the SNTP server socket must bind to. The value is a one-byte hexadecimal literal; assigning the wrong value causes the FB to either open on a different port (and the drive cannot reach the IP it was given) or to report local resource not available.

To identify the LocDevID of a given integrated port:

1. Open the hardware configuration in STEP 7 / TIA Portal.
2. Select the port object (e.g. PN/IE X8 of the CPU 410E).
3. In the properties dialog, switch to the Addresses or Interface tab and note the Interface ID / System ID / LocDevID shown. On CPU 410 hardware this matches the Xn port number: X5 → 5, X8 → 8.
4. Enter the value as a hex literal at the FB input, e.g. iLocDevID := 16#08 for port X8 on a CPU 410E.

7. OUC Connection Configuration

The library uses an internally declared connection DB that is referenced by the FB's ConnID input. The ConnID is the standard STEP 7 OUC connection identifier (not the TCON instance DB number).

• Valid range for ConnID: 1 … 16 for integrated IE ports (per S7-400 communication resource limits). Values above 16 typically return STATUS = W#16#8085 / W#16#80A4.
• Use a unique ConnID per active SNTP server instance. If the same S7-400 is to serve multiple subnets from multiple ports, assign one ConnID per port (e.g. ConnID = 1 on X5, ConnID = 2 on X8).
• The library ships an example DB1001 with the connection parameters. Either load the example or declare a TCON_IP_RFC UDT yourself with the following minimum content:
  • InterfaceId := w#16#1 (LocDevID encoded as required by the FB; consult the FB source for the exact mapping)
  • ConnType := 17#0E (UDP, per TCON IP RFC variant)
  • ActiveEst := TRUE (active = the FB will periodically refresh)
  • Local port 123, remote port 123, remote IP = 0.0.0.0 for an SNTP server that must accept any client

8. Wiring FB1000 in OB1 and OB100

Below is the minimum call pattern (in STEP 7 FBD notation; equivalent STL is documented in the library manual page 20).

// OB1 - cyclic
CALL  FB1000, DB1000
  iLocDevID       := 16#08          // CPU 410E port X8, change to 16#05 for X5
  iConnID         := 2              // 1...16, must be unique on the CPU
  iEnable         := M1.0           // permanent TRUE while server is required
  iStartup        := DB1000.Startup // edge-driven, see below
  oStatus         := MW100          // status word for HMI / diagnostics
  oLastError      := MW102          // most recent non-fatal status
  oServerTime     := DB1000.SrvTime // echoed UTC time for verification

// OB100 - startup
SET
R   DB1000.Startup    // one-shot, cleared on every restart

The Startup edge is generated by a one-shot logic: on the very first OB1 pass after the OB100 reset, the bit is briefly TRUE, the FB opens the OUC connection, and on the next pass the FB itself resets the bit. The library manual page 20 §4.4 lists the exact RLO sequence (sections 3 and 4 of that paragraph) — both OB1 and OB100 calls are required.

9. SINAMICS S120 NTP Client Configuration

The drive side is configured with a small set of parameters. Exact parameter numbers are firmware-dependent; for V5.x the standard set is summarized below. Always cross-check the values against the parameter manual of the installed firmware version.

To clear the existing A1097 alarm, perform a parameter save (copy RAM to ROM, p0971 = 1) and a CU restart so the NTP client daemon reinitializes. After the restart, monitor r3102[0]; the bits for server reachable and time synchronized should clear the alarm automatically within one update interval.

10. Root Cause Matrix for A1097

11. Step-by-Step Resolution Procedure

1. Confirm the S7-400 firmware and port assignment. Note the IP address of the port that will host the SNTP server (e.g. CPU 410E X8 = 192.168.0.10). The drive's NTP client must target exactly this IP.
2. Import the library from entry 82203451 into the STEP 7 / TIA project. Open the example S7 program and copy the FB1000 call into your project.
3. Set the FB inputs:
   • iLocDevID = 16#08 for X8 (or 16#05 for X5, 16#01 for X1, 16#02 for X2 on classic CPUs)
   • iConnID = a free ID in 1..16
   • iEnable = a permanent TRUE bit, e.g. M1.0
4. Insert the OB100 logic to reset the Startup variable in DB1000. Without this step the FB never opens the UDP socket.
5. Insert the OB1 logic that calls FB1000 and that pulses the Startup bit on the first pass after restart (per the library manual page 20 §4.4 sections 3 and 4).
6. Compile and download the modified program to the CPU. Perform a STOP → RUN transition (or a full restart) so OB100 executes.
7. Verify on the CPU side by opening the online view of DB1000 and checking:
   • oStatus = W#16#0000 (no error)
   • oServerTime updates each second
   If oStatus is non-zero, the value maps to a standard TUSEND/TRCV status (e.g. W#16#80A4 = connection resource problem; W#16#80C3 = local resource busy).
8. Configure the SINAMICS S120 NTP client: p3100 = 1, p3101[0..3] = IP octets of the S7-400 port used in step 3, p3102 = UTC offset in seconds, p3103 = update interval in seconds. Save and restart the CU.
9. Watch the S120 alarm buffer: A1097 should clear within one update interval (default 10 s). If it persists, re-check the matrix in section 10.

12. Verification and Diagnostics

To confirm end-to-end synchronization, capture the following:

• PLC side: DB1000.oServerTime and DB1000.oStatus in the VAT or in an HMI. Status must be W#16#0000; the time must increment once per second.
• Network side: capture UDP/123 with Wireshark on a mirrored port. Look for a periodic client request from the S120 Control Unit MAC and a server reply from the S7-400 port MAC. The S120 requests every p3103 seconds; absence of the reply means the FB socket is not bound.
• Drive side: r3102[0] in Starter/Startdrive online. The bit pattern reports server reachable, time synchronized, and stratum. A non-zero stratum with the synchronized bit set means the S7-400 is being used as a valid time source.
• CPU diagnostic buffer: must contain no entries of class communication error referencing ConnID used in step 3.