Resolving S7-1200 Modbus Error 16#8180 on CB1241 Port

1. Problem Overview

The S7-1200 Modbus RTU master raises error code 16#8180 at the MB_COMM_LOAD block when the PORT input receives an invalid hardware identifier for the attached point-to-point communication module. In typical S7-1200 deployments, the error appears immediately after project download on a CPU 1212C, CPU 1214C, or CPU 1215C with a CB 1241 (RS485) or CM 1241 (RS485/RS232) attached to the left of the CPU. The user observable symptom is that MB_COMM_LOAD.DONE never becomes TRUE, MB_COMM_LOAD.ERROR becomes TRUE, and MB_COMM_LOAD.STATUS shows the hex value 8180.

The error does not indicate a wiring problem, a slave device fault, or a Modbus protocol violation. It is a project configuration problem: the symbolic name or numeric hardware ID passed to the PORT input does not match any active communication port in the device configuration of the connected CPU. Common misconfigurations include leaving the input at the placeholder default (commonly 0 or the residual value 270 from a removed module), referencing the wrong module slot, or using a hardware identifier that was reassigned after a hardware reconfiguration in TIA Portal V13 and later.

2. Affected Hardware, Firmware, and Software

Error 16#8180 is firmware-independent on the CPU side: the Modbus instructions (LAD/FUP blocks MB_COMM_LOAD, MB_MASTER, MB_SLAVE) parse the PORT input at runtime and validate it against the active hardware list. The check is the same from firmware V4.0 through the latest releases. CPU 1212C firmware V4.6 (or any V4.x) is the most common environment in the field reports.

3. Root Cause Analysis

The Siemens TIA Portal documentation classifies 16#8180 as:

16#8180 — Invalid value for the PORT parameter (the hardware identifier does not match a configured communications module).

The error is generated by the Modbus library when the integer value supplied to the PORT input of MB_COMM_LOAD cannot be resolved to a hardware object in the device configuration. Several distinct root causes produce the same status word:

1. Stale hardware identifier. The project was compiled when a CB 1241 occupied a slot, and the user later moved or removed the module. The literal integer (e.g., 270) was retained in the PORT input but no longer points to a real object.
2. Slot renumbering. After deleting and re-adding a CB/CM module, TIA Portal may assign a different hardware identifier. Slot 101 is the default for the first CM/CB to the left of the CPU; subsequent modules use 102, 103, etc. The default numeric value of the identifier is calculated by the system and may shift.
3. Wrong module type selected. The hardware catalog entry was set to a different family (e.g., CM 1241 instead of CB 1241, or PROFIBUS slave CM 1242-5), causing the MB_COMM_LOAD call to reference a non-point-to-point port.
4. Optimized data block. MB_MASTER uses VARIANT-style indirect addressing through DATA_PTR. The referenced data block must have the "Standard" access attribute (not "Optimized block access") so the absolute byte offset matches the Modbus payload. While this is not the cause of 16#8180 directly, it frequently appears as a secondary fault after the PORT issue is fixed.
5. Download to wrong CPU. The compiled project targets a CPU whose online hardware list does not include the referenced CM/CB (e.g., the user changed the device but did not re-detect). The hardware identifier exists in the offline configuration but not online.
6. PLC STOP-to-RUN transition after firmware update. Field reports indicate that the error can persist immediately after a firmware update until the CPU is fully power-cycled, even when the project is correct.

The reference page for Modbus RTU error messages is the Siemens TIA Portal Help — MODBUS (RTU) error messages (S7-1200, S7-1500). The 16#8180 entry documents the PORT validation; the surrounding table lists the closely related 16#818A ("Invalid length — select a suitable data length at the DATA_LEN parameter") which frequently surfaces after the PORT problem is fixed but the data block length is still wrong.

4. Locating the Correct Hardware Identifier

The hardware identifier is assigned automatically by TIA Portal at compile time and exposed in two places. Use either to confirm the value before wiring it into the block.

Method A — Device configuration system constants:

1. Open the device view of the S7-1200 station.
2. Click the CB 1241 or CM 1241 module in the rack.
3. In the inspector window, switch to the Properties > System constants tab.
4. Locate the entry labelled <Module name>_RS485_Interface (for CB/CM 1241 RS485) or ..._RS232_Interface.
5. Read the value in the HW identifier column. The integer is what the PORT input expects. Common values are 269 (slot 100 fallback), 270 (slot 101 default for first CM/CB to the left of the CPU), or 271 if a module is in slot 102.

Method B — Watch table on the online CPU:

1. Compile the project and download hardware configuration.
2. Open a watch table and add the system constant tag <Module name>~RS485_Interface (or the corresponding name shown in the project tree under PLC tags > System constants > Constants).
3. Go online. The watch table displays the live hardware identifier. This is the authoritative value if there is any doubt about the offline configuration.

Method C — Drag the symbolic name:

1. In the project tree, expand PLC tags > Show all tags > System constants.
2. Drag the constant CB1241_RS485_Interface directly onto the PORT input of MB_COMM_LOAD in the LAD/FBD editor. TIA Portal will substitute the symbolic name and resolve it at compile time. This is the safest method because it survives hardware reconfiguration automatically.

5. Step-by-Step Resolution Procedure

Apply the following sequence to clear error 16#8180. The steps match the field-proven fix used by integrators running TIA Portal V13 SP1 through V20 with firmware V4.x on the CPU.

1. Open the project in TIA Portal and place the CPU in STOP (online > "Stop CPU") before making hardware changes.
2. Open the device view of the S7-1200 station and locate the CB/CM 1241 module. If the module is present in the rack, jump to step 4.
3. Remove and re-add the module. Right-click the CB 1241 in the rack and select Delete. From the hardware catalog (search for 6ES7241-1CH30-1XB0), drag a fresh CB 1241 RS485 into the slot to the immediate left of the CPU. Confirm that the order number matches the physical module.
4. Configure the module interface. Open the module's properties and set the protocol to Modbus master (RTU) if prompted, or leave the port in Freeport mode (the Modbus instructions handle framing internally). Verify baud rate, parity, data bits, and stop bits match the slave device. The MB_COMM_LOAD block overwrites these settings at runtime, so the device view defaults are not critical, but consistency aids diagnostics.
5. Compile the project. Use Project > Compile > Hardware (rebuild all). This regenerates the system constants and forces every PORT input that uses a symbolic name to re-resolve.
6. Update the PORT input on MB_COMM_LOAD by dragging the system constant <Module>_RS485_Interface from the project tree directly onto the input. If the value is hard-coded, replace it with the new integer shown in the system constants table.
7. Compile software only to confirm no remaining unresolved references. The "Compile" log should show zero errors. Pay attention to warnings about type mismatches in DATA_PTR.
8. Download to the CPU — both the hardware configuration and the software blocks. Use Online > Download to device and select Hardware and software (only changes) or Hardware and software (complete) if the hardware changed.
9. Power-cycle the CPU if the error persists immediately after download. Several user reports confirm that a STOP → RUN transition alone is insufficient after a hardware swap; a full power cycle clears the residual hardware list in the CPU's online view.
10. Monitor MB_COMM_LOAD.STATUS in a watch table. The expected value at the end of the first execution cycle is 16#0000 (no error). If 16#8180 returns, repeat the cycle starting at step 3 and confirm that the same hardware identifier is present in both the offline project tree and the online watch table.

6. Configuring MB_MASTER to Write Holding Register 40005 = 2000

The original report asks specifically for the parameter values required to write a single holding register at Modbus address 40005 with a value of 2000. The configuration below uses the standard Siemens Modbus instruction MB_MASTER (FC version V3.0 or later in the instruction library).

Data block layout for the write buffer:

DATA_BLOCK "ModbusData"
TITLE = Modbus data buffer (Standard access)
{ S7_Optimized_Access := 'FALSE' }
VERSION : 0.1
NON_RETAIN
  STRUCT
    HoldingRegister : WORD;      // Value 2000 to write to 40005
    HoldingReadback : WORD;      // Optional: read-back buffer for diagnostics
  END_STRUCT;
END_DATA_BLOCK

Wire ModbusData.HoldingRegister := 2000 in OB1, then point DATA_PTR to "ModbusData".HoldingRegister. The instruction reads the 2 bytes starting at the absolute address of HoldingRegister, sends them as the data field of Modbus function code 06, and the slave writes them into its register 40005. To read the same register back, switch MODE to 0 and leave DATA_LEN at 1 — MB_MASTER will overwrite DATA_PTR with the value returned by the slave.

7. Data Block Access Mode (Standard vs Optimized)

The MB_MASTER and MB_SLAVE instructions use the VARIANT pointer type. In TIA Portal, data blocks have two access modes:

• Optimized block access (default for new S7-1200/S7-1500 DBs) — symbolic, no fixed offsets, no bit/byte/word access allowed.
• Standard access (legacy) — fixed memory layout, absolute byte offsets, supports direct DB1.DBW0 addressing.

The Modbus instruction requires the data block to use Standard access so that the absolute byte offset passed by the pointer matches the Modbus payload bytes. With an optimized DB, MB_MASTER returns status 16#818A ("Invalid length") or 16#80C8 depending on firmware version. To switch a DB to Standard access:

1. Right-click the data block in the project tree.
2. Select Properties > Attributes.
3. Uncheck Optimized block access.
4. Recompile the project and download.

8. Avoiding Common Pitfalls

Beyond the PORT mismatch, the following configuration issues generate a similar downstream fault signature. Address them in order during commissioning.

8.1 Calling MB_MASTER in the Wrong OB

Field experience shows that calling MB_MASTER in OB100 (startup) or in a cyclic interrupt OB can produce intermittent 16#8180 or "no response" behavior, because MB_COMM_LOAD has not yet completed its first execution when MB_MASTER triggers. Place both blocks in OB1 (program cycle) in the order: MB_COMM_LOAD first, then a small wait/monitor block, then MB_MASTER. The exact wait is not required when the order is preserved — the MB_MASTER instruction queues the request internally and executes it once MB_COMM_LOAD reports DONE = TRUE.

8.2 First-Scan Tag Not Working in Startup

A common mistake is to derive the REQ edge from the FirstScan system bit while the trigger sits in OB100. If the same edge is needed in OB1, copy it across or move the trigger logic to OB1. Alternatively, use a project-internal flag with a one-shot rising edge detector and reset it in OB1 after the first successful transaction.

8.3 Re-triggering REQ While BUSY

The Modbus library buffers only one request at a time per port. If REQ is pulsed every scan while a previous request is still in flight (slave response pending), the queued request is lost. Use the pattern: pulse REQ when BUSY = FALSE AND ERROR = FALSE AND a user-defined "send next" flag is set.

8.4 Mismatched Baud Rate or Parity

Error 16#8180 is not a framing error — but a slave that never responds because the port is misconfigured will produce 16#80C8 ("Slave did not respond within response timeout") after the PORT issue is fixed. Match baud (e.g., 9600), parity (None/Even/Odd), data bits (8), and stop bits (1) exactly with the slave.

8.5 Termination and Biasing on RS485

The CB 1241 RS485 has on-board termination and bias resistors selectable by DIP switch. For a single slave on a short cable, leave termination OFF at the master (CB 1241) and ON at the far end of the trunk. For multi-drop, terminate at both ends and bias only at the master. Floating bias produces intermittent framing errors that look like port faults at the application layer.

9. Related Error Codes and Their Meanings

The full list is published in the TIA Portal V20 help — MODBUS (RTU) error messages (S7-1200, S7-1500).

10. Verification Procedure

After applying the resolution, verify that the link is healthy using the following checks.

1. Watch table check. Add MB_COMM_LOAD.DONE, MB_COMM_LOAD.ERROR, MB_COMM_LOAD.STATUS, MB_MASTER.BUSY, and MB_MASTER.STATUS to a watch table. Expected steady state: MB_COMM_LOAD.DONE = TRUE, MB_COMM_LOAD.STATUS = 16#0000, MB_MASTER.BUSY = FALSE between transactions, MB_MASTER.STATUS = 16#0000 after each DONE pulse.
2. Single-coil write test. Pulse REQ with MODE = 1, DATA_ADDR = 5, DATA_LEN = 1, DATA_PTR pointing to a DB containing WORD = 2000. Confirm that DONE becomes TRUE for one cycle and STATUS stays at 16#0000.
3. Read-back test. Change MODE = 0, DATA_ADDR = 5, DATA_LEN = 1, and re-trigger. The WORD in the data block should now contain the value 2000 (decimal) or 0x07D0 (hex).
4. Slave-side verification. Read the same register from the slave using a portable Modbus scanner (e.g., a Windows tool talking directly to the RS485 port, or the slave's vendor configuration software) to confirm that the value persisted in non-volatile memory if the slave uses EEPROM-backed registers.
5. LED inspection. The CB 1241 has Tx and Rx LEDs next to the RS485 connector. Both should flicker at the configured baud rate. If Tx flickers but Rx is silent, the issue is wiring, termination, or slave power.
6. Diag buffer check. Open Online > Diagnostics > Diagnostics buffer on the CPU. The buffer should be free of "Port configuration error" entries. If any are present, the project has a hardware/software mismatch that the next full download will resolve.

11. Field-Proven Edge Cases

11.1 Multiple CB/CM Modules

Adding a second CM 1241 to a CPU that already has a CB 1241 shifts the hardware identifier of the first module. If the first module's PORT input was hard-coded as 270, it may become 271 (or vice versa). Always use the symbolic constant <Module>_RS485_Interface to be position-independent.

11.2 PROFIBUS CM 1242-5 in the Same Station

The PROFIBUS slave module CM 1242-5 (6GK7242-5DX30-0XE0) occupies a different logical port and cannot host Modbus RTU master. The hardware identifier of a PROFIBUS module in slot 101 is unique to PROFIBUS and must not be passed to MB_COMM_LOAD. The error 16#8180 is returned if the wrong module is selected because the firmware rejects the unsupported service.

11.3 S7-1200 Firmware V4.0 to V4.2 Known Issue

On firmware V4.0 and V4.1, a documented bug requires a full power cycle (not STOP/RUN) for the new hardware identifier to take effect after a download that changes the CM/CB configuration. V4.2 and later hot-swap the identifiers more cleanly but still benefit from a power cycle when the error persists.

11.4 Mixed Modbus TCP and Modbus RTU

Modbus TCP uses the MB_CLIENT instruction with a TCON endpoint; Modbus RTU uses MB_MASTER with MB_COMM_LOAD. Do not mix the two on the same port. The error returned by passing a TCP connection ID to MB_MASTER's sibling MB_CLIENT configuration is 16#80B6, but passing an RTU port to MB_CLIENT returns 16#8180. Cross-check the instruction version in the project tree before assuming the port is wrong.

12. Quick Reference Configuration

Use the following compact block diagram as a copy-paste starting point for a clean Modbus RTU master with a CB 1241 and a single holding-register write.

// OB1 — Program cycle
// Order of execution: MB_COMM_LOAD first, then MB_MASTER

// --- MB_COMM_LOAD instance: "MB_COMM_LOAD_DB" ---
MB_COMM_LOAD_DB(REQ   := TRUE,                // Always TRUE after first scan
                PORT  := "CB_1241_1".RS485_Interface,  // System constant
                BAUD  := 9600,
                PARITY := 0,                  // 0 = None
                FLOW_CTRL := 0,
                RESP_TO := 1000,              // 1 second response timeout
                DONE  => "ModbusDiag".LoadDone,
                ERROR => "ModbusDiag".LoadError,
                STATUS=> "ModbusDiag".LoadStatus);

// --- MB_MASTER instance: "MB_MASTER_DB" ---
// Edge-triggered one-shot from a user flag
IF "ModbusDiag".LoadDone AND "ModbusDiag".SendRequest THEN
    "ModbusDiag".SendRequest := FALSE;
END_IF;

MB_MASTER_DB(REQ      := "ModbusDiag".SendRequest AND NOT "ModbusDiag".MasterBusy,
             MB_ADDR  := 1,
             MODE     := 1,                   // FC06 — write single register
             DATA_ADDR:= 5,                   // 40005 → offset 4 → input 5
             DATA_LEN := 1,
             DATA_PTR := P#DB1.DBX0.0 WORD,   // 2 bytes starting at DB1.DBX0
             DONE     => "ModbusDiag".MasterDone,
             BUSY     => "ModbusDiag".MasterBusy,
             ERROR    => "ModbusDiag".MasterError,
             STATUS   => "ModbusDiag".MasterStatus);

Data block DB1 is configured as Standard access (not optimized) and contains a single WORD at byte offset 0 set to the decimal value 2000 (hex 0x07D0). The result on the wire is Modbus frame 01 06 00 04 07 D0 8A B6 (slave 1, function 06, register 4, value 2000, CRC) followed by an echo response.

13. FAQ