Resolving Siemens S7-1200 T_CONFIG C080_8100 Hardware ID Error

Overview

The T_CONFIG instruction on a Siemens SIMATIC S7-1200 CPU (CPU 1214C, CPU 1215C, CPU 1217C and the entire 1211/1212/1214 family) re-programs the IPv4 parameters, subnet mask, default router and PROFINET device name of the CPU's PROFINET interface at runtime. The instruction is implemented in the user program as a function call and is supported from CPU firmware V2.0 onwards. It is the standard way to re-IP an S7-1200 from inside STEP 7 (TIA Portal) without using a PRONETA, SINEC NMS or any external tool.

This article addresses a recurring field problem in which T_CONFIG returns STATUS = 16#C080_8100 (hex), indicating that the hardware identifier (HW ID) passed at the INTERFACE parameter is not assigned to a configurable PROFINET interface. Engineers report that DONE, BUSY, ERROR and STATUS do not appear to react, and that nothing seems to happen even though the block is being called in OB1. The root cause is almost always a stale or wrong hardware identifier, and the documented fix is to bind the INTERFACE input to the PLC tag's system constant for the PROFINET interface rather than to a manually typed integer. A secondary root cause is the lack of a STATUS latch, which makes the error disappear before the watch table can capture it.

The article covers the T_CONFIG specification, the CONF_DB layout, the hardware identifier resolution, a step-by-step implementation, a full diagnosis of the C080_8100 error, verification and commissioning steps, a comprehensive troubleshooting matrix, adjacent recipes (T_RESET, T_DIAG, PROFINET-name reconfiguration), and operational notes that include the asynchronous behavior, the single-job-per-interface rule, and the STOP/RUN considerations on older firmware.

Prerequisites

• S7-1200 CPU with firmware V2.0 or higher. T_CONFIG is not present in V1.x firmware; an upgrade is mandatory.
• STEP 7 (TIA Portal) V11 SP2 Update 5 or higher. V13, V14, V15, V15.1, V16, V17 and V18 are all acceptable. For current engineering work, V15.1 or V16 with the appropriate S7-1200 HSP installed is recommended.
• The PROFINET interface must be enabled in the device configuration. A PROFINET device name should be assigned if a PROFINET IO relationship will be maintained, otherwise the controller is permitted to operate as a pure PROFINET device (PN device mode).
• The configuration data block (CONF_DB) must be a non-optimized DB on S7-1200 firmware < V4.0. From V4.0 onwards optimized blocks are tolerated if the length field is correctly populated.
• A way to observe the asynchronous DONE, BUSY, ERROR and STATUS outputs across multiple PLC cycles. The minimal mechanism is the STATUS-latch pattern shown in the Implementation section below; a small HMI tag or an OPC tag is the ideal observation surface.

T_CONFIG Instruction Specification

The instruction is found under "Communication → PROFINET IO → T_CONFIG" in the TIA Portal instruction tree. Its formal I/O is defined in the SIMATIC S7-1200 Programmable Controller Function Manual as follows.

Important timing behavior: DONE, ERROR and STATUS are latched for exactly one PLC cycle at the end of the asynchronous job. If the user program does not capture the STATUS value in that same cycle, the value is lost and subsequent inspection of STATUS in the watch table will return 0. This is the most common reason field engineers report that "nothing happens" when they force REQ.

CONF_DB Structure

The CONF_DB parameter points to a data block that the user constructs as a global DB. The first WORD contains the total length of the data block in bytes. The block has a fixed layout for IP configuration. The table below summarizes the layout for a single-interface, single-sub-function record.

For setting the IPv4 address, SubFunctionId is 1, SubFunctionLength is 14, and cbLength is 30. The IP, subnet and router fields must be valid: the bitwise AND of the IP and the subnet must be non-zero (i.e. the address must actually live in the subnet), and the router address must be reachable inside the IP/mask. T_CONFIG rejects invalid combinations with status C080_8103 and C080_8104 respectively.

Hardware Identifier Resolution

The INTERFACE parameter of T_CONFIG must receive the hardware identifier of the PROFINET interface whose parameters will be modified. The CPU exposes this identifier in three places; the three places must always agree.

1. Device configuration → PROFINET interface → Properties → Advanced → Port (X1)(P1) → Hardware identifier. On a stock CPU 1214C this typically reads 64 (interface) and 65 (port). On a CPU 1215C the interface ID can be 64, 260 or higher depending on the configuration.
2. PLC tags → System constants. The constant "Local~PROFINET_Interface_1" or "Local PROFINET interface" is published here. This is the recommended source because TIA Portal maintains the value across firmware upgrades.
3. Constants tab of the program editor. The same constant is available as a tag drop-down when the INTERFACE pin is wired.

If the INTERFACE input is wired to a literal integer (for example 65) but the firmware has been upgraded and the interface has been renumbered, the value will be wrong and T_CONFIG will return C080_8100. Always use the system constant — never a typed integer — to avoid renumbering drift between firmware versions. A second common mistake is to use the PORT hardware identifier (65 on a CPU 1214C) rather than the INTERFACE hardware identifier (64). T_CONFIG needs the interface identifier, not the port identifier.

Step-by-Step Implementation

1. Create a new global DB named "TConfigData". Mark the DB as a "System" data block (TIA Portal: Properties → Attributes → "System data block") and disable optimized access for S7-1200 firmware < V4.0. The declarations should match the layout in the CONF_DB section:

   DATA_BLOCK "TConfigData"
   { S7_Optimized_Access := 'FALSE' }
   VERSION : 0.1
   NON_RETAIN
     STRUCT
       cbLength         : WORD  := 30;   // total length of the DB in bytes
       usInterfaceCount : WORD  := 1;
       usInterfaceId    : WORD  := 0;    // 0 = the calling interface
       usSubFunctionCount : WORD := 1;
       usSubFunctionId  : WORD  := 1;    // 1 = set IP address
       usSubFunctionLength : WORD := 14; // bytes of payload below
       usDataLength     : WORD  := 7;    // 7 words of payload
       InterfaceRef     : WORD  := 0;    // 0 = apply to the calling interface
       IpAddr           : ARRAY[1..4] OF BYTE := 192,168,0,10;
       Subnet           : ARRAY[1..4] OF BYTE := 255,255,255,0;
       Router           : ARRAY[1..4] OF BYTE := 192,168,0,1;
       Reserved         : WORD  := 0;
     END_STRUCT;
   END_DATA_BLOCK
   

2. Drop T_CONFIG from the instruction tree into a cyclic OB. OB1 is acceptable for a one-shot re-IP; OB30..OB38 give a deterministic, fixed-interval execution if the re-IP is to be retried periodically. Wire REQ to a tag you can control from a watch table (e.g. "xTConfig_Req"). Wire INTERFACE to the system constant "Local PROFINET_Interface" (NOT a literal integer such as 65). Wire CONF_DB to the symbolic name of the DB, e.g. "TConfigData".
3. Wire DONE, BUSY, ERROR and STATUS to retentive or non-retentive tags. Critically, add the following latching logic immediately after the block:

   // Capture STATUS for one cycle on rising edge of ERROR or DONE
   IF "tConfig".ERROR OR "tConfig".DONE THEN
       "iStatus_Saved"  := "tConfig".STATUS;
       "xDone_Latch"    := "tConfig".DONE;
       "xError_Latch"   := "tConfig".ERROR;
   END_IF;
   

   Without this code, STATUS = 0 the moment you look at it in the watch table. The bug is not in T_CONFIG, it is in the user program not reading the result.
4. Pre-load IpAddr, Subnet and Router with the new values from a startup OB (OB100) or via a watch table before forcing REQ. Watch out for endianness: the array is filled byte by byte, so the example 192,168,0,10 is the four bytes of 192.168.0.10, not a 32-bit integer.
5. Force REQ = TRUE for one cycle in the watch table. Watch "xDone_Latch" rise; if it does, the IP change succeeded. On firmware < V4.4 the change may not be active until a STOP→RUN transition or a power cycle; on V4.4 and higher the new IP is live immediately.
6. Switch the engineering station to the new IP subnet and verify connectivity with a ping and an "Online → Accessible nodes" scan from TIA Portal. The CPU's MAC address will continue to respond on the new IP.
7. Re-establish the OPC connection from the SIMATIC NET OPC server (or the customer's preferred OPC stack) using the new IP, then browse the S7 items to confirm the application data path is intact.

Diagnosing STATUS = C080_8100

The hexadecimal value 16#C080_8100 decomposes as follows in the Siemens error model:

Causes, in order of probability based on field reports:

1. INTERFACE wired to a literal integer (e.g. 65) rather than the system constant. After a firmware upgrade, the HW ID may shift and the literal becomes stale.
2. The HW ID refers to the port, not the interface. T_CONFIG needs the interface HW ID, not the port HW ID. Port IDs on a CPU 1214C are 65; interface IDs are 64.
3. The PROFINET interface is disabled in the device configuration (greyed out in the inspector).
4. CONF_DB is incorrectly typed (UINT vs. WORD pointer) or points to an optimized-only DB on firmware < V4.0.
5. The CPU is not the controller of any PROFINET IO subsystem but a pure PROFINET device — the device interface may be 64 while the controller interface is 65 in some configurations; the T_CONFIG instruction must be issued on the same interface whose parameters it is changing.

Remediation: delete the constant integer at the INTERFACE input, re-wire it to the system constant "Local~PROFINET_Interface_1" from PLC tags, recompile and re-download the project. The error clears on the next execution of T_CONFIG.

Verification and Commissioning

• After forcing REQ once, expect "xDone_Latch" = TRUE and "iStatus_Saved" = 0x0000. Any non-zero value means the job failed; consult the STATUS map in the next section.
• Issue a ping from the engineering station to the new IP. TTL is typically 64 for an S7-1200. A "Destination host unreachable" reply means the CPU has not yet picked up the new address; some firmware versions require a power cycle for the change to take effect, others apply it hot.
• Re-establish the OPC connection from the SIMATIC NET OPC server using the new IP, then browse the S7 items.
• For permanent retention across power cycles, write the new IP into a recipe in the PLC's retentive area and apply it on OB100 startup so a power-down does not leave the CPU on the old address.
• Use the CPU's integrated display (where present) to confirm the live IP. The display shows the project IP and the live IP, which can be different for a few seconds after a T_CONFIG job.

Troubleshooting Matrix

Adjacent Recipes: T_RESET, T_DIAG, PROFINET Name Reconfiguration

When the IP change is the entry point to a larger commissioning effort, the T_CONFIG instruction can also be used to set the PROFINET device name. The SubFunctionId is 2. The data layout differs: it carries the IO device number, a vendor-reserved word, and the name as a CHAR array of up to 240 bytes. The same HW ID rules apply, so reusing the system-constant approach is mandatory. For diagnostics on the same interface, T_DIAG reads the interface's diagnostic buffer; T_RESET returns the interface to its configured project state. Both instructions share the same INTERFACE parameter conventions as T_CONFIG and are subject to the same C080_81xx class of errors when wired incorrectly. A common pattern is to issue a T_DIAG right after a successful T_CONFIG to log the change in the diagnostic buffer for the customer's records.

The T_CONFIG instruction also has a "reset to project state" sub-function (SubFunctionId = 4) which rolls the interface back to whatever was loaded by TIA Portal. This is the recommended recovery if a runtime re-IP leaves the CPU in a state that prevents further engineering access: cycle power, enter the project IP from a programming device, issue a T_CONFIG SubFunctionId = 4, and the interface is restored.

Interaction with SIMATIC NET and OPC

The original symptom in many T_CONFIG tickets is a broken OPC connection between SIMATIC NET v8.1 (or later) and the S7-1200. Once T_CONFIG re-IPs the CPU, the OPC server's S7 connection must be redirected to the new IP. In the SIMATIC NET Configuration Console, edit the S7 connection, change the partner IP, and re-activate the connection. If the OPC client uses the SIMATIC NET DA server, restart the DA server after the IP change so it re-binds the S7 channel. For SIMATIC NET PC software v16 and above, the connection can be updated without restart if the "auto-reconnect" property is enabled. Bear in mind that re-IPing the CPU will break the PROFINET IO relationship if one exists; the IO controller must update its AR (Application Relationship) with the new IP before the IO devices come back online.

State Machine for the T_CONFIG Job

The T_CONFIG job progresses through a deterministic state machine that the user program should respect. Forcing REQ repeatedly without waiting for DONE or ERROR is a common misuse and is one of the reasons jobs are rejected with C080_8200 (job already active).

Re-triggering REQ while BUSY is TRUE does not queue the new request; it is rejected. The user program must wait for DONE or ERROR before re-arming REQ.

Operational Notes

• T_CONFIG on S7-1200 is asynchronous; do not assume REQ → DONE in the same cycle. The internal job can take 1 to 5 OB1 cycles depending on the firmware version and the runtime load.
• Only one T_CONFIG job can be active at a time per interface. If a second T_CONFIG instance is triggered while the first is BUSY, the new request is rejected with STATUS = C080_8200 (job already active).
• On S7-1200 firmware V4.4 and higher, the new IP is applied immediately. On earlier firmware, a STOP→RUN transition or power cycle may be required.
• The T_CONFIG instruction does not store the new IP in the CPU's remanent load memory. To retain the new address across a power cycle, repeat the configuration from OB100 at every cold restart.
• Changing the IP at runtime breaks any active PROFINET IO connections. Stop the IO controller first or accept the IO drop. With PN/PN couplers, the coupler will fault and require operator acknowledgment on the partner controller.
• If the new IP causes the CPU to leave the subnet of the engineering station, TIA Portal will lose its online connection. Re-establish online access by changing the station's IP first, then re-attaching via "Online → Accessible nodes".
• Do not confuse T_CONFIG (runtime interface re-configuration) with the IP configuration that takes place in the device configuration. The latter is loaded with the project and is the source of truth on a cold start. T_CONFIG overrides it for the current RUN session only.
• When using T_CONFIG in a safety-related S7-1200F controller, note that the change of IP address is not part of the F-runtime signature. The IP change is invisible to F-code and does not affect the safety signature; nonetheless, do not rely on IP-based access control as a safety barrier.

Re-applying the IP at Cold Start (OB100)

To make the runtime re-IP survive a power cycle, the application must re-issue the T_CONFIG job in OB100 using a stored "desired IP" kept in a retentive DB. A reference implementation is below.

// OB100 — startup
// On the first scan, force a T_CONFIG with the desired IP from a recipe DB.
"TConfigData".IpAddr[1]  := "recipe".desiredIp[1];
"TConfigData".IpAddr[2]  := "recipe".desiredIp[2];
"TConfigData".IpAddr[3]  := "recipe".desiredIp[3];
"TConfigData".IpAddr[4]  := "recipe".desiredIp[4];
"TConfigData".Subnet[1]  := "recipe".desiredMask[1];
"TConfigData".Subnet[2]  := "recipe".desiredMask[2];
"TConfigData".Subnet[3]  := "recipe".desiredMask[3];
"TConfigData".Subnet[4]  := "recipe".desiredMask[4];
"TConfigData".Router[1]  := "recipe".desiredRouter[1];
"TConfigData".Router[2]  := "recipe".desiredRouter[2];
"TConfigData".Router[3]  := "recipe".desiredRouter[3];
"TConfigData".Router[4]  := "recipe".desiredRouter[4];
"xTConfig_Req"          := TRUE;  // single-shot in OB100

The same latching pattern from the OB1 call should be present in OB100 or in a shared monitoring FB so that the cold-start re-IP is observable.

Putting It Together: Field-Proven Commissioning Sequence

1. Confirm the CPU firmware is V2.0 or higher. If not, upgrade before continuing.
2. Compile the project in TIA Portal and resolve any hardware identifier warnings in the device configuration.
3. Build the TConfigData DB and the latching network. Wire the INTERFACE input to the system constant — never a literal.
4. Download the project. Verify the CPU is in RUN. Force REQ once from the watch table and observe the latched STATUS.
5. If STATUS = 0x0000, the change succeeded. If STATUS = C080_8100, re-check the system constant and re-download.
6. After the change, cycle power on the engineering station, reconfigure the station IP, and re-attach to the CPU on the new address.
7. Persist the new IP to a recipe and re-apply from OB100 if survival across power cycle is required.
8. Update the SIMATIC NET OPC connection and any PN/PN coupler partner to the new IP.
9. Document the change in the customer's change log; the IP change is invisible to the safety signature but is a configuration change that should be tracked.