Assigning PROFINET Device Names from S7-400 PLC Program

Problem Overview

Engineers commissioning PROFINET IO systems on a Siemens S7-400 CPU 416-3 DP with a CP 443-1 communications processor frequently encounter a hard limitation: the STEP 7 V5.5 program environment does not expose any SFC, SFB, or FB that writes a PROFINET device name to a downstream IO device from PLC user code. When a Scalance X216 switch port is rewired and a previously learned topology is broken, the CPU flags the affected devices as mismatched and the engineering tool is required to perform a factory reset and Assign PROFINET device name for every displaced device.

The same workflow is trivial on Allen-Bradley (EtherNet/IP) and Beckhoff (EtherCAT) controllers, where the controller can write identity and connection parameters at runtime. PROFINET separates device naming (a DCP service) from IO data exchange (a cyclic RPC service), and the legacy CP 443-1 firmware only implements the latter. This article documents the exact capabilities, the firmware boundary where the limitation lifts, and the practical workarounds available on a brownfield S7-400 site.

PROFINET Device Name Assignment Architecture

A PROFINET device name is a string of up to 240 characters stored in non-volatile memory of the IO device. It is the link between the engineering configuration (which names a slot) and the physical device sitting on the wire. The lifecycle is:

1. The engineering tool (STEP 7 / TIA Portal) issues DCP Identify on the link-local multicast MAC 01-0E-CF-00-00-00.
2. The selected device replies with its current NameOfStation, IP, and MAC.
3. The tool issues DCP Set NameOfStation carrying a NameOfStationBlock (TLV containing the new name and the device's MAC).
4. The device writes the name to its remanent store and reboots its AR (Application Relationship) if the name changed.

On an S7-400 with CP 443-1, this dialog is reachable from the engineering tool (PC on the same subnet or routed via the CP), but no library element in STEP 7 V5.5 packages the DCP Set service for the user program. The CP firmware only forwards DCP frames from the configuration channel; it does not expose a programmable DCP master interface.

Affected Hardware and Firmware

Why the S7-400/CP 443-1 Cannot Assign Names from the PLC Program

Three reasons converge:

1. No CPU-side PROFINET interface on the S7-400. The PROFINET controller role lives on the CP 443-1, not on the CPU. The PLC program cannot directly emit Ethernet frames to the PN subnet; the CP handles the stack and presents the IO image as input/output process areas.
2. CP 443-1 firmware does not expose a DCP master FB. The CP's PROFINET stack accepts DCP for its own configuration but is not a generic DCP client for the application. Siemens did not add this function block to the CP 443-1 because the configuration path is the engineering tool.
3. STEP 7 V5.5 lacks a system block for DCP write. The library SIMATIC_NET_CP provides FBs for open communication (TCP, ISO-on-TCP, UDP) via the CP, but none of these wrap DCP Set NameOfStation. Search STEP 7 V5.5 SP2 for FBs with the prefix FB UDT DCP or SFB 99 through SFB 125: nothing in the standard scope performs a DCP name write.

S7-1500 Native Capability (Firmware V1.5 and Higher)

Starting with S7-1500 firmware V1.5, the CPU exposes a configuration flag that, during CPU startup, allows the controller to overwrite the PROFINET device name of an IO device when the configured name does not match the device's stored name. This is documented in the TIA Portal help under Permit overwriting of PROFINET device name. The feature is configured in the device properties of the IO controller, in the PROFINET interface > Advanced options > Name assignment area, and operates once per CPU RUN-to-RUNUP transition.

This is the only PLC-side mechanism Siemens ships for S7-class controllers to push a name to a device. It is a configuration-time, not a runtime, mechanism: the program does not call a block; the controller's startup routine enforces the configured names against the discovered devices.

Configuration Path in TIA Portal V20

1. Open Devices & Networks, select the S7-1500 CPU.
2. Open Properties > PROFINET interface [X1] > Advanced options > Name assignment.
3. Tick Permit overwriting of PROFINET device name.
4. Compile and download the hardware configuration.
5. On every STOP-to-RUN transition the controller re-assigns any displaced device to its configured name.

Workaround 1 — TIA Portal Engineering Tool

The standard recovery procedure for an S7-400 site is to use the engineering tool to reassign the name. The dialog is documented in Assigning a name in the 'Assign PROFINET device name' dialog. For an S7-400 site still on STEP 7 V5.5 the equivalent dialog is HW Config > Edit Ethernet node > Assign device name. Procedure:

1. Open HW Config in STEP 7 V5.5 SP2 (or TIA Portal with a V5.5-imported project).
2. Select PLC > Ethernet > Edit Ethernet node.
3. Click Browse. The CP scans the local subnet and lists every device with its MAC, current NameOfStation, and IP.
4. Select the displaced valve, set Device name to the configured value (e.g. valve_axis_1), and click Assign name.
5. Confirm the Reset to factory settings checkbox if the device carries a name that does not match your project (Siemens recommends this on first assignment to clear stale names).

This is the documented Siemens path and is fully supported on the CP 443-1. It is interactive, not PLC-driven.

Workaround 2 — PRONETA (Free Network Tool)

SIEMENS PRONETA is a free, portable Windows tool that ships with a graphical network scanner, IO tester, and a CLI for headless name assignment. The CLI is the part that can be wrapped in a script called from the S7-400 via a Windows-based HMI station.

PRONETA CLI syntax for name assignment

PronetaCmd.exe -scan -outputfile scan.xml
PronetaCmd.exe -assignname -ip <device_ip> -name <newname> -resetfactory

Wrap the call in a WinCC V7.x script on the engineering station, trigger it via a button or an S7 flag from the S7-400 (using PUT/GET or a CP 443-1 IT OPC connection), and the station will execute the DCP write. The S7-400 itself is not doing the assignment; the HMI is.

Workaround 3 — Open IE Communication with Custom DCP Frame

For engineers who must keep the assignment logic inside the S7-400 program, the only path is to use the CP 443-1's open communication services to emit a raw Ethernet frame. This requires the CP 443-1 IT or the CP 443-1 Advanced (6GK7 443-1EX50-0XE0) and the FB 67 / FB 68 / FB 65 / FB 66 TCON / TSEND / TRCV / TDISCON blocks. Even then, the open IE block set only transports TCP, UDP, and ISO-on-TCP segments; it does not encapsulate raw Layer-2 frames.

To send a DCP Set NameOfStation via open IE, the approach is to:

1. Run an external DCP master (PRONETA or a Linux host with libpnet) on a PC station reachable from the CP 443-1.
2. From the S7-400 program, raise a flag that the PC polls (e.g. via FB 14 PUT / FB 15 GET to a CP 343-1 Lean in the PC rack, or via OPC DA on a WinCC station).
3. The PC, on the rising edge, runs PronetaCmd.exe -assignname and reports the result back as a status word to the S7-400.

This is the closest engineers get to PLC-driven name assignment on an S7-400. It is a coordinated PC/PLC flow, not a single FB.

ST snippet for the trigger (S7-400 / STEP 7 V5.5 STL)

// Trigger flag to PC for PROFINET name reset
A     M    100.0          // Operator "Reset valve names" request
S     DB20.DBX   0.0     // PC trigger: do DCP reset
// Wait for ack
A     DB20.DBX   2.0     // PC ack: reset complete
R     DB20.DBX   0.0
// Operator lamp
=     Q    100.0          // "Reset complete" lamp

Workaround 4 — Migration to S7-1500

If the application is greenfield or the controller is up for refresh, migrating to S7-1500 (e.g. CPU 1515-2 PN, 6ES7 515-2AM02-0AB0) with firmware V1.5 or higher gives the cleanest answer. The controller's startup will overwrite displaced names without operator action. Migration steps:

1. Convert the STEP 7 V5.5 project with TIA Portal migration tool. Map the CP 443-1 PROFINET subnet to the integrated PROFINET interface of the S7-1500.
2. Enable Permit overwriting of PROFINET device name on the PROFINET interface.
3. Replace the SFC/SFB calls that referenced CP 443-1 with the S7-1500 native PROFINET blocks (none required; the controller does it during startup).
4. Re-assign each IO device once with TIA Portal at commissioning; thereafter the controller manages the name store.

For MOOG valves in the original question, the valve's GSD file must be re-imported and the device name typed exactly as in the existing project; the controller will push it on first run-up.

Topology Configuration with Scalance X216

The original setup uses a Scalance X216 managed switch (6GK5 216-0BA00-2AC2) with two valves per port, and the engineer observes that swapping cables between ports 1 and 2 triggers a topology mismatch. This is the expected behavior of PROFINET neighbor detection via LLDP. Two correction paths exist:

1. Disable neighbor detection in HW Config: set PROFINET IO > Topology > Compare actual topology / expected topology to disabled. The CPU will accept the device regardless of port. This is a less strict approach but it is the correct setting for flexible cabling.
2. Configure both topologies: add the swapped cable layout as an alternate topology, and have the controller pick one. STEP 7 V5.5 supports a single expected topology; alternates are not first-class. TIA Portal V20 supports multiple topologies on S7-1500.

Combined with the name-assignment limitation, the practical S7-400 answer is: disable port-based topology check, leave name assignment to the engineering tool or PRONETA. The MOOG valve DCP responder will not care which port it sits on as long as the name resolves to the correct slot.

Step-by-Step: Recovery Procedure for a Swapped Cable Event (S7-400)

1. From WinCC or a button on the HMI, call the PRONETA CLI on the engineering station with the device MAC list of the four MOOG valves.
2. For each affected valve, run PronetaCmd.exe -assignname -mac <MAC> -name <configured_name> -resetfactory.
3. Read back the assignment status from the PRONETA return code (0 = success).
4. Have the S7-400 program poll a status bit written by WinCC after the script completes.
5. Trigger a STOP-to-RUN on the CPU only if the IO devices still show mismatched; the controller will re-establish the AR once the name is correct.

Verification and Diagnostics

After the name write, verify by:

1. STEP 7 V5.5: PLC > Diagnostics/Setting > Hardware diagnostics. The IO device slot shows the configured name and the diagnostic buffer is clean.
2. PRONETA Network analysis: the Name column matches the configured name; the Status column shows OK.
3. CP 443-1 Web server (V3.x and higher): Information > PROFINET IO > Devices. The State field shows Connected; Name shows the assigned string.

Comparison Matrix: Methods

Key Constraints and Field-Proven Caveats

• No PLC-resident block performs DCP Set NameOfStation on S7-400. This is a hardware/firmware boundary, not a documentation gap. Do not waste time searching STEP 7 V5.5 SP2 libraries.
• CP 443-1 variants older than -EX30 are PROFINET-disabled or limited to 8 devices. Confirm the variant supports the required number of IO devices before commissioning MOOG valves that may exceed 8.
• DCP frames do not cross routers. The CP 443-1 must be on the same Layer-2 broadcast domain as the IO devices, or the PRONETA station must be on the same subnet. Plan the network accordingly.
• Factory reset of a device is not always required. Siemens recommends it only when the device carries a name from a previous project; in a clean re-wiring scenario, plain Assign name suffices.
• LLDP neighbor check is independent of name assignment. Even with names matching, port mismatch will trigger a diagnostic warning. Use Topology editor > Disable on S7-400 to allow flexible cabling.
• MOOG valve GSD/GSDML version must match the STEP 7/TIA version. A valve imported with an old GSD may not respond to all DCP services; re-import the latest GSDML from the MOOG product page before commissioning.

Standards Reference

PROFINET device name assignment is defined in IEC 61158-6 (Application Layer) and PROFINET specification Discovery and Configuration Protocol. The DCP multicast MAC 01-0E-CF-00-00-00 and Ethertype 0x8892 are reserved by the PROFIBUS Nutzerorganisation (PNO). Use the standard as a reference when validating any third-party tool's behavior, not as a guarantee that a vendor implementation exposes every service.

FAQ