PROFINET Device Name vs MAC: S7-300/CP 343-1 Replacement

1. Overview: PROFINET Identification on S7-300/CP 343-1 Stations

On a SIMATIC S7-300 station that uses a CP 343-1 for PROFINET, the I/O controller (the CP itself) does not treat the MAC address of a connected I/O device as the persistent identifier it relies on at startup. The PROFINET IO Controller uses the PROFINET Device Name as the primary identification token during connection establishment, and it stores the device's IP address as a non-real-time addressing parameter that is derived from the project configuration. The MAC address is consumed at the lowest layer for frame delivery, but the controller's name table — built from the STEP 7 HW Config project — is what determines which name belongs to which slot in the process image. This is the engineering reality behind the central question of whether an identically configured spare PROFINET device (same Device Name, same IP, same vendor configuration) can be moved between otherwise identical machines on a plant floor without touching the STEP 7 project.

This reference is written for engineers commissioning or maintaining SIMATIC S7-300 stations with PROFINET CPs (e.g., the 6GK7343-1EX30-0XE0 and the surrounding 6GK7343-1 family) and an array of third-party PROFINET I/O devices that share the same IP and Device Name across multiple machines. The sections below separate the three addressing layers (MAC, IP, Name), explain how the CP 343-1 stores and reuses each, and walk through the supported replacement procedures for both the standard DCP-based workflow and the LLDP-topology-based automatic device replacement workflow.

2. The Three Addressing Layers in PROFINET

PROFINET separates device identification into three independent layers. Each plays a distinct role during startup, cyclic real-time I/O, and acyclic diagnostics. Engineers who treat PROFINET as "Ethernet with a name" often oversimplify the startup sequence, and that simplification is the most common root cause of spare-part headaches on the shop floor.

2.1 Layer 1 — MAC Address (Frame-Delivery Identity)

The 48-bit MAC address is the Layer-2 hardware identifier burned into the PROFINET device's network interface. PROFINET follows the IEEE 802 MAC address model: the upper 24 bits are the Organizationally Unique Identifier (OUI) assigned to the device vendor, and the lower 24 bits are vendor-assigned to make the address globally unique. PROFINET International operates a MAC Address Allocation Service (PI MAC Address Allocation Service) so that PROFINET vendors can obtain vendor prefixes from a single registry and can block contiguous 24-bit prefixes for the PROFINET vendor community at large. The remaining bits inside the prefix are used to derive per-port and per-interface identifiers.

A PROFINET device with an integrated two-port switch (the typical ET200 or third-party block I/O configuration) typically carries three MAC addresses: one for the device/interface itself and one for each of the two switch ports. The three addresses share the same OUI prefix and differ only in the lowest byte(s). The CP 343-1 itself follows the same pattern: the module has one device MAC plus one MAC per integrated switch port, all within the 28-bit block allocated to the device vendor.

MAC addresses are used by the I/O controller and the I/O device for:

• Ethernet frame source and destination addressing.
• The Layer-2 "Device Hello" multicast announcements emitted by an unconfigured I/O device during DCP discovery (multicast MAC 01-0E-CF-00-00-00 per IEC 61784-2).
• PROFINET real-time (RT) and isochronous real-time (IRT) frame exchange at the bottom of the stack, where the cyclic I/O data rides on top of Ethernet/VLAN-tagged frames addressed to the device's port MAC.

MAC addresses are not used as the persistent identifier across power cycles. The I/O controller does not compare a stored "known MAC" table against a newly observed MAC; it compares a stored Device Name against the name the new device reports via DCP. The MAC is therefore a transport-layer detail, not a configuration object.

2.2 Layer 2 — IP Address (Non-Real-Time Addressing)

The IP address is needed for acyclic services that travel over TCP/UDP — for example, SNMP, the PROFINET RPC endpoint, the Web server of the device, the STEP 7 "Edit Ethernet Node" discovery, and the PROFIenergy / asset-management channels. The IP address is assigned to the I/O device by the I/O controller using DCP after the controller has identified the device by its PROFINET Device Name. The I/O device retains its last assigned IP in non-volatile memory and reuses it on the next power-up unless the controller overwrites it.

2.3 Layer 3 — PROFINET Device Name (Persistent Identity)

The Device Name is the single piece of identity the PROFINET I/O controller actually uses to recognise a device at startup. The name is a string (per IEC 61784-2 / PROFINET specification, up to 240 characters, restricted to lower-case letters, digits, and the hyphen) that the controller writes into the I/O device using DCP, and that the I/O device stores in its own non-volatile memory. From that point on, the device presents itself to the network with that name; if the controller asks "who is present at this link?" via a DCP Identify broadcast, the device answers with its name plus its MAC and IP.

The name is also the field that the STEP 7 HW Config project stores in its name table: every PROFINET device slot in the project carries exactly one Device Name, and the controller's startup sequence is essentially "for every name in my project, find a device that announces that name on my network, then establish an AR (Application Relationship) to it." The mapping of name → slot is therefore fully defined by the project, and the controller does not need to remember a MAC for the slot to function.

3. DCP — Discovery and Configuration Protocol

PROFINET DCP (Discovery and Configuration Protocol, defined in IEC 61784-2) is the protocol that does all the heavy lifting at startup. The I/O controller uses DCP to discover unconfigured devices on the link, to read their current name, to assign them a new name, and to assign their IP configuration. DCP runs directly on Layer-2 Ethernet using the PROFINET multicast destination MAC 01-0E-CF-00-00-00, so it works even before any IP infrastructure exists on the segment.

The relevant DCP services for device replacement are:

• DCP Identify (multicast request / unicast response): the controller asks every device on the link to report its name, MAC, and IP. The controller uses the responses to build the live name-to-MAC table for the current run.
• DCP Get / DCP Set: read or write device parameters, most importantly the Device Name and the IP suite.
• DCP Hello: an unconfigured I/O device that has no name yet broadcasts a Hello frame periodically so that a controller (or an engineering tool) can find it without prior knowledge.

From the CP 343-1's point of view, the DCP name table is the authoritative configuration. The CP's retentive storage contains:

1. The CP's own PROFINET Device Name and IP suite (assigned from the STEP 7 project and downloaded to the CP's non-volatile memory).
2. The project-side list of expected Device Names for downstream I/O devices, in the order dictated by the HW Config slots. This list is regenerated on every project download; it is not maintained as an evolving "MAC cache."

4. How the S7-300 CPU and CP 343-1 Retentively Store PROFINET Identity

The S7-300 family separates non-volatile storage into the MMC (Micro Memory Card) on the CPU and the non-volatile area inside the CP module. The S7-315-2DP and S7-317-2DP CPUs referenced in the question carry no PROFINET interface; they only have a PROFIBUS-DP master. PROFINET connectivity is delegated to the CP 343-1 plugged into the S7-300 backplane, and the CP is the entity that owns the PROFINET IO Controller state. This is the most common reason engineers get confused about where the identity information actually lives.

4.1 CPU-Side Storage (MMC, Retentive System Data)

The CPU's MMC stores the STEP 7 project, the system data blocks generated by HW Config (SDB), and the PLC program. The PROFINET configuration lives inside the system data blocks — specifically the SDBs that the CP 343-1 consumes at startup. The MMC therefore holds:

• The HW Config topology (which Device Name sits on which slot of which CP 343-1 port).
• The IP suite that the CP must assign to each I/O device.
• The slot-to-I/O-address mapping that the STEP 7 program reads from.

The CPU itself does not learn the MAC addresses of the I/O devices during operation. The PROFINET stack that consumes the SDBs and runs the AR establishment is the firmware inside the CP 343-1, not the CPU.

4.2 CP 343-1 Internal Non-Volatile Storage

The CP 343-1 holds, in its own non-volatile memory:

• The CP's own PROFINET Device Name and IP configuration.
• The CP's own MAC addresses (factory-assigned, read-only, and printed on the module label — typically in the form 08-00-06-xx-xx-xx for the older CP 343-1 family, or the SIEMENS-specific OUI per the PI allocation prefix).
• Optionally, link-layer neighbour information derived from LLDP, used to support the topology-based automatic device replacement (see Section 6). Whether this neighbour table survives a CP power-cycle depends on the firmware version; on modern CP 343-1 firmware (V2.x and later) the table is re-learned at link-up, not pulled from NVM, and is therefore not something the engineer needs to "reset."

There is no Siemens-supplied function to dump, view, or reset a "connected MACs" list on the CP, because the CP does not store one. The only thing the engineer can inspect via STEP 7 / TIA diagnostics is the live AR status of each Device Name, which reports the MAC of the currently-connected device as a runtime read-out, not a stored value.

4.3 The I/O Device Side

Each PROFINET I/O device stores three things in its own non-volatile memory:

1. Its factory MAC address (read-only, unique per device, assigned by the vendor's PI-allocated prefix).
2. The Device Name last assigned to it by an I/O controller or by the "Edit Ethernet Node" tool.
3. The IP suite last assigned to it by an I/O controller.

When a brand-new, never-configured I/O device is powered up on a PROFINET segment, it has no Device Name and no IP. It identifies itself as an "unconfigured device" via DCP Hello broadcasts. Once an I/O controller or engineering tool writes a Device Name into the device, the device keeps that name across power cycles; the next controller startup will find the device already announcing the expected name and will not need to re-assign it.

5. Practical Workflow — Replacing an Identical PROFINET Device Across Machines

Returning to the original problem statement: there are three or more near-identical machines, each with an S7-315-2DP / S7-317-2DP and a CP 343-1 (e.g., 6GK7343-1EX30-0XE0) connected to three third-party PROFINET devices called A1, B1, and C1. All A1 units across the plant have the same IP, the same PROFINET Device Name, and the same vendor configuration. All B1 and C1 units follow the same pattern. The question is whether a single spare set (A1, B1, C1), once configured against machine 1, can be moved to machine 2, machine 3, and so on without re-execution of the DCP name-assignment procedure.

The answer is yes, with one important caveat: the spare must carry the expected Device Name when it is plugged into the new machine. The controller on the destination machine will accept the spare in exactly the same way it accepted the original device, because the controller's identity check is "is there a device on my link announcing the Device Name a1?" and the spare will, by definition, be announcing that name. The spare's MAC will be different from the MAC of the original device, but that is irrelevant to the controller.

5.1 First-Time Configuration (Building the Spare)

1. Connect the spare set (A1, B1, C1) to the engineering station that hosts STEP 7 V5.5 (or TIA Portal, depending on the project generation).
2. Open HW Config and use the menu PLC → Ethernet → Edit Ethernet Node to browse the network. The three unconfigured spares will appear in the list with their factory MAC addresses, status "No PROFINET name assigned."
3. For each spare, enter the target Device Name (a1, b1, c1) and the target IP, then click Assign Name and Assign IP. DCP writes the name and the IP into the spare's NVM.
4. Plug the now-named spares into machine 1. Download the HW Config to the CP 343-1 if it is not already on the CP. The CP 343-1 will establish ARs to a1, b1, c1 and start cyclic data exchange.

5.2 Moving the Spare Set to Another Machine

1. Power down machine 1. Remove the spares.
2. Plug the spares into machine 2 (or any machine whose project expects the names a1, b1, c1). Power up machine 2.
3. The CP 343-1 on machine 2 will, during its DCP Identify phase, find a device on the link announcing a1, another announcing b1, and a third announcing c1. The MACs will be the spare's MACs — different from the original devices on machine 2 — but the controller does not care.
4. ARs are established and cyclic I/O starts. No "Edit Ethernet Node" action is required on the destination machine.

6. LLDP Topology-Based Automatic Device Replacement

PROFINET supports a more sophisticated replacement procedure that does not require the engineering station at all. The mechanism is the combination of a configured PROFINET topology and the IEEE 802.1AB Link Layer Discovery Protocol (LLDP). The I/O controller (CP 343-1) sends LLDP frames out of every port and receives LLDP frames from neighbours. By comparing the live neighbour table to the topology in HW Config, the controller can determine that "the device that used to sit at port 2 of switch X, slot 4, is no longer present, and a new device has appeared at that same port." If the new device is reachable and announces an unconfigured status (no PROFINET name), the controller can assign it the expected name automatically.

6.1 Prerequisites for Topology-Based Replacement

• The PROFINET topology must be configured in HW Config, with the "Interconnections" / "Port connections" editor filled in for every device and every managed switch on the path.
• Every device and every switch on the path must support LLDP. This means managed switches (not unmanaged); unmanaged switches pass LLDP through transparently but do not generate their own LLDP frames, and PROFINET's topology-based replacement requires the controller to learn each switch's port neighbours.
• The CP 343-1 firmware must support the topology-based procedure. Modern CP 343-1 firmware (V2.x and later on the EX30 and successor modules) supports it. Confirm against the firmware release notes for the specific module variant in use.
• The new device must be powered up and reachable on the same port as the missing device, with no name yet assigned (or with a name that the controller is willing to overwrite).

6.2 What Happens at the Wire

1. The controller detects that the AR for Device Name a1 is down (the original a1 is missing).
2. Through DCP, the controller polls the ports in the configured topology to find a candidate. It uses LLDP to identify "a new device, with no name, plugged into the same port the missing a1 was plugged into."
3. The controller writes the Device Name a1 and the IP into the new device via DCP Set.
4. The controller establishes the AR to the new device. Cyclic I/O resumes.

From the PLC program's point of view, the slot at address IW x or QB y never changed — the I/O data for a1 is now coming from a different MAC, but the slot mapping in the process image is driven by the Device Name, and the Device Name is the same.

6.3 Limits of the Topology Mechanism

7. Verification After a Spare Swap

After moving a spare set between machines, the engineer should run a standard verification sequence. The exact menus differ between STEP 7 V5.5 and TIA Portal, but the underlying diagnostics are the same.

1. Open HW Config and double-click the CP 343-1. Open PROFINET IO → Diagnostics (STEP 7 V5.5) or Online & Diagnostics → PROFINET IO (TIA Portal). All three Device Names (a1, b1, c1) must show status "OK" with an active AR.
2. In the same diagnostics view, expand the slot list. For each device, confirm that the I/O channels expected by the program (input bytes, output bytes, diagnostics) match the project's slot definition.
3. Read the MAC displayed for each device in the diagnostics tree. The MAC will be the spare's MAC, not the original's MAC. This is normal and is the strongest confirmation that the swap is operating correctly through the Device Name path rather than the MAC path.
4. From the PLC program side, force a known output and read it back via the HMI or a watch table to confirm cyclic data is flowing. A diagnostic interrupt (OB 82) may fire briefly during the swap; this is expected and does not indicate a configuration problem.
5. If the project is configured with topology, open the topology view in the online diagnostics and confirm that the LLDP neighbour table shows the spare at the expected port.

8. Edge Cases and Field-Proven Caveats

The Device Name model is robust, but real plants surface a few recurring traps. Each of these is worth engineering for in advance rather than diagnosing at 03:00 on a production line.

8.1 The "I Forgot to Write the Name" Spare

The single most common reason a spare fails to be recognised is that the spare was never named. A brand-new third-party PROFINET device has no Device Name and announces itself as "unconfigured." The CP 343-1 will not assign a name automatically unless topology-based replacement is configured and the new device appears at the expected port. In all other cases, the engineer must run "Edit Ethernet Node" once on the spare before the swap.

8.2 The "Wrong Name" Spare

If a spare was previously used in a different line and was named (for example) a1 by the previous project, and the new project expects a1 as well, the swap works. If the new project expects a2, the spare will be rejected (or, worse, will collide with a still-present a2 if the original a2 was removed before the new one was plugged in, but its NVM still answers DCP). The safe field practice is to re-flash the spare's name to the correct value before the swap, using "Edit Ethernet Node."

8.3 Vendor-Specific Reset of Name and IP

Some third-party PROFINET devices expose a vendor-specific menu (often via the device's web server) to reset the name and IP back to "unconfigured." This is useful when returning a faulty device to a vendor and when preparing a truly blank spare. Siemens PROFINET devices (e.g., ET 200S, ET 200MP) follow the same model but do not always expose a web server; the standard reset path is the "Edit Ethernet Node" tool with the "Reset to factory" option, available in newer STEP 7 versions.

8.4 Mixed Star and Line Topologies

If a machine's PROFINET segment is a mix of a CP 343-1 port, an unmanaged switch, and a chain of I/O devices, the topology view in HW Config is straightforward. If a managed switch is in the path, the engineer must record the port numbers in HW Config's "Port connections" editor. Without that record, LLDP-based replacement will not work even if every device supports it.

8.5 CP 343-1 Firmware Compatibility

The CP 343-1 family spans multiple firmware generations. Older modules (e.g., CP 343-1 EX11, EX21) have older PROFINET stacks with reduced functionality — for example, the topology-based replacement may be limited to single-port cases. Confirm the module's MLFB against the current firmware release notes published on the Siemens Industry Online Support portal before relying on a specific replacement feature. The 6GK7343-1EX30-0XE0 in the original question is a current-generation module with full functionality.

8.6 The CPU vs CP Misconception

Engineers often ask whether the S7-300 CPU's retentive memory (load memory on the MMC) contains a list of MACs. The CPU's load memory contains the STEP 7 project, which contains the Device Names, but no MAC list. The PROFINET stack runs in the CP, and the CP's non-volatile memory holds only the CP's own PROFINET configuration. The MACs of the I/O devices are runtime values, not configuration values. There is nothing on the CPU or CP to view or to reset, and that is by design.

9. Worked Example — Three-Machine Spare Set

To make the workflow explicit, the following is a complete commissioning sequence for the original problem statement: three identical machines (M1, M2, M3) with one spare set (one a1, one b1, one c1).

1. On the engineering station, open STEP 7 V5.5 with the project for M1. In HW Config, the CP 343-1 has three PROFINET devices: a1, b1, c1, each with a fixed IP and a fixed Device Name. The slot mapping (input bytes IW 0..5, output bytes QW 0..3, for example) is identical in M2 and M3.
2. Take the spare set to the engineering station. Connect a1 to the engineering switch. In HW Config → PLC → Ethernet → Edit Ethernet Node, browse, find a1 by its factory MAC, and assign the Device Name a1 and the project IP. Repeat for b1 and c1.
3. Take the named spares to M1. Plug them in. Power M1. CP 343-1 on M1 establishes ARs to a1, b1, c1. Verify cyclic I/O. The spare set is now "blessed" for the M1 configuration.
4. When M2 needs the same configuration, power down M2, remove M2's original a1/b1/c1 (or leave them in place if they are healthy), and plug the spare set into M2's PROFINET segment. Power up M2. The CP 343-1 on M2 establishes ARs to a1, b1, c1 on the spare's MACs. The spare is now in M2.
5. To move the spares back to M1 (or on to M3), repeat step 4. The spares carry their names in NVM and the receiving controller accepts them by name. The MACs are different on each move, and the diagnostics view will report the new MACs every time.

10. References Inside the Project

Two project artifacts determine the behaviour of every replacement. Both are part of the STEP 7 project that is loaded into the CPU's MMC and consumed by the CP 343-1 at startup:

• SDB container for the CP 343-1 (PROFINET IO system data) — contains the Device Name list, the IP suite for each I/O device, and the slot-to-process-image mapping. Regenerated on every HW Config download.
• PROFINET topology (optional) — if the engineer has filled in the "Port connections" / "Interconnections" editor, the CP 343-1 will use the topology plus LLDP to perform automatic device replacement. Without the topology, the CP can still run, but it will not perform automatic name assignment.

There is no separate "MAC list" SDB, no "connected devices" SDB, and no maintenance SDB that needs to be reset between swaps. The Device Name list in the SDB is the entire PROFINET-side configuration the controller holds.

11. Frequently Asked Questions