Siemens STEP 7 Local ID: Uniqueness Rules in Multiproject

Overview: What Is a Local Connection ID in STEP 7?

In SIMATIC STEP 7, every configured communication connection — whether an S7 connection, ISO-on-TCP, TCP, UDP, or ISO transport link — is identified by a numeric Local ID. The Local ID is assigned by the engineer inside the connection editor (NetPro in STEP 7 V5.x, or the Devices & Networks editor in TIA Portal) and is stored as a property of the connection endpoint. At runtime, the CPU uses the Local ID as the index into its internal connection table to route incoming and outgoing telegrams to the correct communication blocks (FB / FC / TCON / TSEND / TRCV / PUT / GET / BSEND / BRCV / USEND / URCV).

The most common point of confusion, especially in a multiproject where multiple STEP 7 projects share common MPI, PROFIBUS, or PROFINET subnets, is whether the Local ID must be globally unique on the subnet, unique per project, or unique per CPU. The unambiguous answer — confirmed by Siemens documentation, by STEP 7 NetPro compile behavior, and by the runtime firmware of every S7-300, S7-400, S7-1200, and S7-1500 CPU — is that the Local ID must be unique within the CPU that owns the connection endpoint. Two different CPUs on the same physical subnet may legitimately use the same Local ID; the network stack on each CPU keys the connection table by its own local ID only.

Scope of Uniqueness: Per CPU, Not Per Subnet or Project

The Local ID is a CPU-internal handle. When the S7-300/400 or S7-1500 operating system receives a telegram on its Ethernet or PROFIBUS interface, it inspects the connection-describing fields (TSAP for ISO / ISO-on-TCP, port for TCP/UDP, or the S7 connection header for S7 connections) and then dispatches the PDU to the application block that registered that connection via the matching Local ID. Because the dispatcher is local to one CPU, the same Local ID value on a remote CPU is invisible to it.

Consequences of this design:

• CPU A and CPU B on the same PROFINET subnet can both use Local ID 0x0001 for completely different partners without any collision.
• Within a single CPU, no two configured connections may share the same Local ID. The CPU's connection table is keyed by the ID, so a duplicate entry overwrites or rejects the second registration.
• In a STEP 7 multiproject, sub-projects are compiled together, and NetPro performs a CPU-level uniqueness check before generating the system data (SDB). It does not perform a subnet-wide uniqueness check, because such a check has no runtime meaning.

Multiproject Architecture and Shared Subnets

A STEP 7 multiproject (S7-MP) is a container that holds several sub-projects, each with its own S7 station, PC station, or HMI station. Sub-projects are edited independently but compiled and downloaded as a unit. The multiproject coordinator project holds references to the sub-projects and synchronizes the subnet topology across them.

Shared subnets are the normal case in a multiproject:

• A plant-wide PROFINET ring, e.g. 192.168.0.0/24, is defined once in the master project and inherited by every sub-project that contains a station connected to that ring.
• MPI or PROFIBUS subnets used by multiple S7-300 stations are similarly shared.
• Each sub-project may contain its own private subnets (e.g. a machine-internal subnet that does not leave the station) — these are not shared and have no effect on the other sub-projects.

Within a shared subnet, you can have N stations, each with one or more configured connections. Each station's connections are managed by the station's own CPU, so the per-CPU Local ID uniqueness rule applies independently to every station. The subnet itself does not enforce any ID uniqueness — it cannot, because the ID is not a field that appears on the wire.

Connection ID Range and Reserved Values

The Local ID is conceptually a 16-bit WORD, but STEP 7 and TIA Portal restrict user-defined IDs to a documented range. The exact reserved and user-usable range depends on the CPU family and firmware version.

The TCON instruction in the S7-1500/1200 instruction set accepts the full WORD range, but typical engineering practice keeps IDs in the 0x0001–0x0FFF band for backward compatibility with NetPro-exported SDBs.

NetPro Configuration in STEP 7 V5.5

In STEP 7 V5.5, connections are managed in NetPro (Network Configuration). Each connection has a local endpoint (one of the stations in the project) and a partner endpoint (which may be in the same project, in a sibling sub-project of the multiproject, or in an unspecified partner whose address is given manually).

To inspect or change the Local ID of a connection:

1. Open the S7 project in SIMATIC Manager.
2. Select the station (e.g. S7-300 Station_1), then choose Options > Configure Network to launch NetPro.
3. Right-click the CPU and choose Insert New Connection (or open an existing connection).
4. In the connection properties dialog, the Local ID field is shown on the General tab. STEP 7 V5.5 auto-assigns the next free ID per CPU, starting from 1.
5. To force a specific ID, type a decimal or hex value directly. NetPro verifies the value is unused on this CPU before accepting it.

If a duplicate ID is configured inadvertently (e.g. by editing system data blocks manually), NetPro will mark the connection with a yellow warning triangle and refuse to compile the SDB. The diagnostic message names the conflicting connection and the station on which the conflict occurs.

Connection Configuration in TIA Portal

In TIA Portal (V13 and later), the connection editor is integrated into the Devices & Networks view. Open the project, double-click Devices & Networks, then use the Connections button in the toolbar to filter the editor to connections only.

Steps to set the Local ID:

1. In the Devices & Networks editor, switch to the Connections mode.
2. Click on the connection in the table at the top, or in the graphical area.
3. In the Properties > General pane, the Local ID (also labeled ID) is shown. TIA auto-assigns the next free value on the local CPU.
4. To override, click into the field and enter a value. TIA validates against the existing connections of that CPU. If the value collides, the field is flagged red and the connection is marked invalid until the conflict is resolved.

For unspecified partners (where the partner is a third-party device or a CPU not in the project), TIA Portal still assigns a Local ID. The same ID can appear on a different CPU in another sub-project without conflict.

TCON Programming Interface and ID Reference

On S7-1500 and S7-1200, the Open User Communication blocks (TCON, TDISCON, TSEND, TRCV, TUSEND, TURCV) reference the connection via its Local ID stored in the connection description DB. The structure used depends on the protocol:

Code sample — SCL on S7-1500 opening a TCP connection with Local ID 16#0001:

// Connection description DB
DATA_BLOCK "connDb"
  STRUCT
    ID        : WORD  := 16#0001;     // Local ID - must match the TIA connection
    ConnectionType : BYTE := 16#0B;   // 0x0B = TCP/IP (B#16#0B)
    ActiveEstablished : BYTE := 16#01;// 1 = active open
    RemoteAddress : IP_V4 := ...
    RemotePort : UINT := 2000;
    LocalPort : UINT := 2000;
  END_STRUCT
END_DATA_BLOCK

// Open the connection
"TCON_DB"(REQ := TRUE,
          ID   := 16#0001,           // <-- must equal ID in connDb
          ... );

If the value passed to TCON's ID input does not match a connection that the CPU firmware has loaded from the connection configuration (SDB / system data), the TCON block returns status 0x80C4 ("ID not found in connection description"). A duplicate ID — two connections registered with the same value on the same CPU — surfaces as 0x80C5 ("ID already in use") on the second TCON call.

Connection Resources per CPU

Each CPU has a finite pool of connection resources. Local IDs are simply the user-visible handles into that pool. The maximum number of connection resources differs by CPU family and order number. Representative values (consult the CPU's manual for exact figures):

The connection resources are independent of Local ID uniqueness. Even with all 256 IDs unique on an S7-1516, you still cannot exceed 256 total connection endpoints. Plan your ID scheme around the highest value the CPU will actually hold — not around the maximum possible value.

Diagnosing Duplicate ID Conflicts

When two connections on the same CPU are assigned the same Local ID, the symptoms differ between STEP 7 V5.5 and TIA Portal.

STEP 7 V5.5 / NetPro:

1. Compile (NetPro > Network > Check Consistency or Generate SDB) returns a warning of the form: "Connection with Local ID xxxx on CPU yyyy collides with connection zzzz."
2. The connection table in NetPro marks the second connection with a yellow triangle.
3. Download to the CPU is blocked; the SDB containing the conflicting connection is rejected.
4. Online diagnostics (PLC > Diagnostic/Setting > Module Information) show the connection status as Not configured for the second endpoint.

TIA Portal:

1. The Devices & Networks editor flags the conflicting connection red in the inspector window.
2. Compile (Project tree > right-click > Compile > Software) returns a build error: "The ID '16#xxxx' is already used by connection '...' on device '...'."
3. Download to the CPU is blocked; the system data for the offending CPU is not generated.
4. Online > Online & Diagnostics on the CPU > Connection list shows only the first connection; the second never reaches the firmware.

Runtime on S7-1500/1200 (TCON): If a duplicate is forced into the firmware (e.g. by an SDB edit or a third-party tool), TCON returns 0x80C5 on the second open call. The diagnostic buffer records event ID 0x0193 with text "Connection setup error: ID already in use." The buffer entry is on the local CPU; the partner CPU is unaffected.

Best Practices for ID Allocation

1. Let the editor auto-assign. Both NetPro and TIA Portal pick the next free ID per CPU. Manual overrides should be the exception, not the rule.
2. Reserve a band per protocol. For example, 0x0001–0x00FF for S7 connections, 0x0100–0x01FF for ISO-on-TCP, 0x0200–0x02FF for TCP, 0x0300–0x03FF for UDP. Document the convention in a project README or a shared spreadsheet. This is purely a documentation aid — the firmware does not enforce any band.
3. Do not change an ID after commissioning without updating every reference in SCL, LAD, FBD, GRAPH, and any external tool that reads the SDB. Renumbering breaks the TCON ID input and causes open failures at the next download.
4. In a multiproject, treat each CPU independently. Do not waste effort ensuring cross-CPU uniqueness. The runtime does not need it, and the compile tools do not check it.
5. When migrating from V5.5 to TIA Portal, the migration tool preserves Local IDs. Verify with the connection list after migration that the IDs are still unique within each CPU; the migration is normally safe because V5.5 already enforced per-CPU uniqueness.
6. For redundant S7-400H systems, both CPUs of the H-pair run the same connection configuration. The Local ID space is per-CPU even on an H-station, but the S7-H connection is a single logical connection with two physical endpoints; treat it as one connection in the ID plan.
7. For S7 routing across subnets (PG/OP routing), the routing CPU uses a few internal IDs that are not exposed in NetPro. You do not need to reserve them manually.

Migration Between STEP 7 V5 and TIA Portal

When a STEP 7 V5.5 multiproject is migrated to TIA Portal (V16 or later), the migration wizard reads each connection's Local ID from the SDB and writes it into the equivalent TIA connection. The wizard performs its own per-CPU uniqueness check during the import; if it finds a collision (which would only happen if a V5 project was already broken), it renumbers the conflicting connection and logs a warning.

After migration, use Project tree > Devices & Networks > Connections > Table view to export the connection list. Sort by Local ID within each CPU. Any duplicate indicates a migration problem and must be resolved before download. The TIA Portal online help entry "Migrating STEP 7 V5 projects" and the Siemens Industry Online Support FAQ on connection migration give the exact wizard behavior per firmware version.

Frequently Asked Questions