Sinumerik 840D SL TCU Ethernet Setup: X120, X127, X130 Port Guide

Overview

The Sinumerik 840D sl is a digital CNC platform whose operator station is built around a Thin Client Unit (TCU). The TCU is a diskless panel PC that boots its HMI image from the NCU (Numerical Control Unit) and renders the operator interface over VNC. All of this traffic — DHCP, TFTP, VNC, NFS, and the operator panel connection — flows over Ethernet between the NCU and the TCU. On an NCU 720.1 the engineer has three Ethernet interfaces to choose from, and the most common commissioning problem is connecting the TCU to the wrong one.

This reference covers the role of the X120, X127, and X130 ports on the NCU 720.1, the TCU boot sequence, the default IP scheme, the basesys.ini file used to expose the controller on a company network, the HMI diagnostic path that exposes a link as "inactive", and the physical-layer rules for the patch cabling between NCU and TCU. It is written for the engineer standing in front of a panel that says "Wait for boot server..." and that has no obvious next step.

NCU 720.1 Ethernet Port Architecture

The NCU 720.1 exposes three copper RJ45 Ethernet interfaces on the front bezel, plus a PROFINET-converged port (X150) used for real-time I/O, and PROFIBUS interfaces for legacy fieldbus. The three RJ45 service-class ports are functionally distinct and routed through separate virtual interfaces inside the NCU Linux image:

The IP defaults above are factory defaults for the system network segment. The X120 subnet is reserved for the NCU, the TCUs, an HT8 handheld terminal, and any PCU50/PCU70 industrial PC connected to the system network. It is intentionally isolated from the company network — there is no default route from X120 to X130 inside the NCU.

Refer to the official SINUMERIK 840D sl Commissioning Manual on the Siemens Industry Online Support portal for the canonical description of these ports and their routing rules.

X120 — System Network and TCU Connection

X120 is the HMI port. Every TCU, HT8, and PCU that is intended to display the operator panel of this NCU must terminate on X120 — either directly, through a managed switch dedicated to the machine, or via a daisy chain (TCU-to-TCU) terminated at the NCU. The HMI subsystem on the NCU runs a DHCP server, a DNS server, a TFTP server, and a VNC server on this interface, and a TCU will not boot unless it can find those services on the wire.

The X120 segment must be a private subnet free of plant traffic. A common cause of intermittent boot failures is a technician plugging the plant's general-purpose switch into X120, which lets other devices' DHCP replies race the NCU. The X120 segment should be physically and logically isolated from X130.

X130 — Company Network and Firewall Boundary

X130 is the company-network port. It is the only NCU interface that has a default route to the plant LAN. It is also the only NCU interface protected by a Linux iptables firewall that is configured from basesys.ini. By default the firewall blocks inbound services such as Step 7 / TIA Portal remote access, port forwarding, and unsolicited VNC.

Putting the TCU on X130 is a misapplication: the HMI subsystem does not bind its DHCP / TFTP / VNC services to X130, so the TCU will time out looking for a boot server, or will pick up an IP from the plant DHCP server and then fail to find a TFTP server. The diagnostic menu will report the X130 link as "inactive" because, from the HMI subsystem's perspective, the operator interface is not present on that interface.

If the company network must be able to see the NCU, configure X130 with a static address or a DHCP client as described in basesys.ini, but do not expect the operator panel to follow that interface.

X127 — Service Interface

X127 is the service interface intended for Siemens service personnel. It is configured with its own subnet and is restricted at the NCU side. Not all service functions work reliably over X127 — in particular, image download and full PLC debug are typically done over X120 (with the controller in service mode) or via the diagnostic interface on a PCU. Treat X127 as a last-resort service path and a means for read-only diagnostics, not as a primary commissioning link.

TCU Boot Sequence and Network Services

A TCU is a diskless device. It depends on the NCU to provide the following services on the system network (X120):

1. DHCP — assigns the TCU an IP address and supplies the TFTP server address and boot file name as DHCP options (options 66 and 67).
2. DNS — resolves the boot server's hostname so the TCU can find the NCU even when its IP changes during commissioning.
3. TFTP — transfers the Linux kernel, initrd, and TCU-specific configuration files when the TCU powers on.
4. VNC — once the TCU is booted, the HMI on the NCU is exported to the TCU as a VNC desktop.

The TCU powers up, broadcasts a DHCP DISCOVER on X120, receives an offer from the NCU, downloads its image over TFTP, and then connects to the HMI's VNC server. If any of those four services is missing on the wire, the TCU hangs on the "Wait for boot server..." message indefinitely.

Default IP Addressing Scheme

The system network (X120) uses the 192.168.214.0/24 subnet by default. A typical layout is:

The DHCP pool, the static reservations, and the boot filename are all defined in basesys.ini. Address ranges shown are typical commissioning values — verify the exact pool in the active configuration before changing any device's static IP, as collisions with the DHCP pool are a common source of "inactive" link states after a manual IP is set.

Diagnosing an Inactive TCP/IP Link

If the HMI is loaded but the TCU link is reported as not connected, navigate the diagnostic menu on the operator panel:

1. From the main HMI area, press the Menu Select key and choose Diagnostics.
2. Open Bus TCP/IP.
3. Open TCP/IP Diagnostics.

The resulting screen lists the system-network interfaces and reports the link state, the configured IP, and the DHCP state of each connected device. "Inactive" on X130 is expected and correct — that port is not used by the HMI subsystem. "Inactive" on X120 indicates that no TCU is responding to DHCP on the system network, and is the symptom to investigate.

A working commissioning step is to first verify the link LEDs on the NCU's X120 port and the TCU's LAN port. If the link LED is dark, the problem is physical: cable, patch panel, switch port, or device. If the link LED is lit but the diagnostic still says "inactive", the problem is at the network layer: wrong subnet, DHCP not running, or TCU not on the same segment.

Manual vs Automatic IP Configuration

Setting a static IP on the TCU is supported but is rarely the correct first step. The TCU is designed to receive all of its configuration — IP address, subnet mask, gateway, TFTP server, and boot filename — from the NCU's DHCP server. A static IP set on the TCU bypasses DHCP and is generally used only for the small number of TCUs that need a fixed address for VNC keyboard assignment or to be visible to a network management tool.

basesys.ini Configuration

The basesys.ini file is the central configuration file for the system network. It is read at NCU boot and controls:

• The X120 subnet and NCU static address
• The DHCP pool range and lease time
• The TFTP root and the boot filename handed out in DHCP option 67
• The DNS zone and hostname assignments for TCUs
• The X130 firewall rules and the X130 default route
• VNC port bindings and password policy

A representative basesys.ini excerpt for the system network looks like:

[SYSTEM_NET]
IP = 192.168.214.1
SUBNET = 255.255.255.0
DHCP_RANGE_START = 192.168.214.10
DHCP_RANGE_END = 192.168.214.239
LEASE_TIME = 3600

[TFTP]
ROOT = /tftpboot
BOOTFILE = tcu-image.bin

[DNS]
DOMAIN = sinumerik.local

[X130_FIREWALL]
ALLOW_SERVICES = none
DEFAULT_POLICY = drop

Edits to basesys.ini take effect after an NCU restart. The file is typically edited from the HMI's commissioning area or via a service laptop connected to X120. Do not edit it over X130 — the firewall will block the write-back in most configurations.

Physical Layer and Cabling

The TCU is connected to the NCU's X120 port with a standard RJ45 patch cable. The cable is Cat 5e or better; the run length follows standard 100/1000BASE-T limits (100 m total channel). For a single TCU, the connection is point-to-point.

For multiple TCUs the topology is a daisy chain: NCU X120 → TCU #1 uplink → TCU #1 downlink → TCU #2 uplink → ... Each TCU exposes a second RJ45 for the daisy-chain output. Do not loop the chain back into a switch and then into the NCU; the resulting broadcast storm will hang every TCU at boot.

HMI Embedded Network Manager

On configurations that include a PCU20 with HMI Embedded (Windows-based industrial PC acting as the HMI host), the HMI Embedded Network Manager is the tool used to configure the X120 side of the network from the PCU. It writes the same basesys.ini values the NCU would otherwise own, and it manages the relationship between the PCU and the TCUs that are attached.

If the machine is an NCU 720.1 with native HMI on the NCU (no PCU20), the Network Manager is not required — the NCU's own HMI subsystem owns basesys.ini directly. Mixing the two configurations (NCU HMI plus PCU20 Network Manager) is a common commissioning error and produces contradictory DHCP and TFTP offers on the wire.

Commissioning Verification

Run the following checks in order after the physical connection is in place:

1. Link LEDs. Confirm the X120 link LED on the NCU is lit and the corresponding LED on the TCU is lit. If either is dark, replace the cable before continuing.
2. DHCP offer. From a service laptop on the system network, run a packet capture or simply watch the NCU's Diagnostics → Bus TCP/IP → TCP/IP Diagnostics screen during the TCU's next power cycle. The TCU should appear with a DHCP lease.
3. TFTP transfer. The TCU's display will move from "Wait for boot server..." to a kernel download progress bar within a few seconds. A hang at "Wait for boot server..." indicates a TFTP problem — verify the tftpboot directory on the NCU contains the expected boot image.
4. VNC session. The TCU should display the HMI main screen within roughly 60 to 90 seconds of power-on. A VNC connection refusal usually means the HMI software is not yet ready, not a network problem — wait one boot cycle and retry.
5. Ping the TCU from the NCU. From the NCU service shell, ping 192.168.214.10 (or whichever address the TCU took). A successful ping confirms end-to-end IP connectivity, separate from the VNC layer.

Troubleshooting Matrix

Field-Proven Notes

• One NCU per X120 segment. Two NCUs on the same X120 switch will hand out overlapping DHCP ranges and TFTP images. Each NCU must own a private system network.
• Don't fix the wrong symptom. A "static IP works but ping doesn't" result usually means the TCU is on the wrong port, not that the IP is wrong. Verify the physical port before troubleshooting the address.
• Firmware and HMI versions must match. The TCU image on the NCU's TFTP root must match the HMI version running on the NCU. A TCU booting an older image against a newer HMI will get past TFTP and then fail to negotiate VNC.
• Firewall first, services second. When commissioning X130 access, start with the firewall rules in basesys.ini and only then enable individual services. Reverse-order commissioning produces transient openings that are hard to close later.

FAQ