Reconfiguring Siemens CP 341 from Modbus Slave to Modbus Master

A single Siemens CP 341 point-to-point communication module can be re-tasked between Modbus slave and Modbus master, but the conversion is treated as a fresh installation rather than a parameter edit. The hardware stays in the rack; the loadable driver, the project configuration, the function-block call structure, and the RS232 cable must all be re-engineered for the new role. This reference walks through the full conversion path for the 6ES7 341-1AH01-0AE0 (RS232C) variant, including the dongle licensing model, STEP 7 project changes, cable design, and the field-experienced failure mode where the TX and RX LEDs never illuminate when connecting to a Modbus slave or simulator.

1. Hardware Identification: CP 341 Variants

The CP 341 is a serial communication processor for the S7-300 family. Three physical interface variants are produced, and the variant determines which transceiver, connector, and cable topology applies. Before any reconfiguration, confirm the part number on the front panel label.

The subject of this guide is the RS232C variant. The CP 341 is wired as a DTE device: pin 2 = TD (transmit data, output from CP 341), pin 3 = RD (receive data, input to CP 341), pin 5 = signal ground. Any Modbus slave that exposes a DB9 male connector and labels it "RS232" is almost always also a DTE, so a crossover (null-modem) cable is required to connect two DTEs.

2. License Architecture: Loadable Drivers and Dongles

The CP 341 does not contain a fixed Modbus stack. Each protocol (Modbus master, Modbus slave, ASCII, 3964R, RK512) is delivered as a loadable driver on a 3.5" floppy disk and is unlocked by a hardware dongle plugged into the CP 341's parallel port on the front of the module. The dongle is matched to the driver — a Modbus slave dongle will not unlock a Modbus master driver, and vice versa.

For the master role, the dongle must be physically present in the CP 341, and the matching loadable driver must be installed on the programming PG/PC. The driver is loaded into the CP 341 during the project download. The CP 341's firmware will not boot a protocol it cannot authenticate against the dongle.

The dedicated Modbus instruction interface for CP 341 in the TIA Portal (V20) documentation is MODB_341 – Modbus slave instruction for CP 341 (S7-300, S7-400). The slave instruction is the conceptual reference for understanding how the loadable driver is invoked from a user program; the master counterpart uses a parallel instruction family (typically named for the master role) and is configured in the same hardware catalog slot.

3. Prerequisites for Reconfiguration

Convert a slave-configured CP 341 to a Modbus master only when all of the following are in hand. The job cannot be started incrementally — a partial setup will boot the CP 341 into a fault state and the SF LED will be lit.

1. Hardware
   • CP 341 module (6ES7 341-1AH01-0AE0 for RS232) seated in the S7-300 rack with the backplane connector fully engaged.
   • Modbus Master dongle inserted in the CP 341's front-facing dongle port.
   • RS232 null-modem cable terminated DB9 female at both ends (for DTE-to-DTE slaves) — see Section 5.
2. Software on the programming device
   • STEP 7 V5.x with SIMATIC Manager (typical for CP 341 native projects), or TIA Portal with the CP 341 HSP that bundles the Modbus master driver.
   • Modbus Master loadable driver (the floppy or installer that matches the dongle in the CP 341).
   • For test: a Modbus slave simulator on a PC (e.g., ModbusPoll, Modbus Tools, or the sample Siemens "Modbus Slave" project on a second S7 station).
3. Slave device documentation
   • Slave's supported Modbus function codes (1, 2, 3, 4, 5, 6, 15, 16 are the common set for the CP 341 master).
   • Register map: coil, input, holding, input-register addresses and their unit/scaling.
   • Serial parameters the slave requires: baud rate (e.g., 9600, 19200), parity (none/even/odd), data bits (7 or 8), stop bits (1 or 2).
   • Cable/connector requirements and whether the slave port is DTE or DCE.
4. Project state
   • A backup of the existing slave project archive (the master conversion overwrites hardware configuration and rewrites the program blocks).

4. Project Conversion Procedure

Treat the conversion as a new installation. The existing slave configuration in the STEP 7 hardware catalog (HW Config) cannot simply have its protocol swapped — the FB calls in the user program reference a different instruction family and a different instance data block layout.

4.1 Remove the Slave Protocol Bindings

1. Open the S7 project in SIMATIC Manager and open the S7-300 station in HW Config.
2. Double-click the CP 341 in the rack.
3. In the Properties – CP 341 dialog, change the protocol assignment back to the generic None / unconfigured state if available, or delete the CP 341 from the rack and re-insert it. Deleting and re-inserting is the cleaner approach for a role change.
4. Save and compile (Station > Save and Compile).

4.2 Re-Insert the CP 341 as a Master

1. In HW Config, drag the CP 341 (RS232 variant) from the hardware catalog back into the same slot.
2. Open the CP's properties and assign the slot's protocol to Modbus Master. The catalog entry text and the exact label vary between STEP 7 versions; in older versions the entry reads "Modbus Master RTU/ASCII" and requires the master dongle to be present at download time.
3. Configure the protocol parameters:
   • Baud rate: must match the slave (typical industrial default 19200 or 9600).
   • Parity: None / Even / Odd — must match the slave. Mismatched parity is the most common cause of silent communication (no errors, no data).
   • Data bits: 8 for RTU, 7 for ASCII.
   • Stop bits: 1 (2 if parity is None and the slave requires 2 stop bits).
   • Response timeout: typically 1000 ms for slow slaves; 200–500 ms for local simulators.
4. Download the new hardware configuration to the CPU. The CP 341 will restart and load the master driver from the dongle.

4.3 Rewrite the User Program

The user program must be rewritten from scratch for the master role. The slave program used the Modbus slave FB family (see MODB_341 as the conceptual reference) to expose data on request. The master program uses the master FB family to issue explicit read/write requests and to time-slice multiple slaves on a single port.

For each Modbus transaction in the master program, the call supplies:

• Slave address (1–247; 0 is broadcast and is read-only for most function codes).
• Function code (1 = read coils, 2 = read discrete inputs, 3 = read holding registers, 4 = read input registers, 5 = write single coil, 6 = write single register, 15 = write multiple coils, 16 = write multiple registers).
• Starting address in the slave's register map.
• Quantity of registers or coils.
• Source/destination DB in the S7 CPU where the read result is written or the write data is read from.

Calls are typically placed in OB1 (cyclic) or in a time-driven OB (e.g., OB35) and managed with a hand-shake bit (DONE, ERROR) to avoid issuing a new request before the previous one completes.

5. RS232 Cable Design for Modbus Master

The single most common cause of a CP 341 master that "talks to the project but never sees a slave" is a cable that does not match the slave's DTE/DCE expectation. The wiring 2↔3, 3↔2, 5↔5 that the user reports is a textbook null-modem (crossover) for data and signal ground, but the handshake lines are left floating. Many Modbus slaves require RTS/CTS or DTR/DSR to be looped or pulled in a specific way to enable the receiver.

5.1 Minimal DTE-to-DTE Null Modem (No Handshake)

5.2 Two Common Null-Modem Variants

The following is an SVG diagram of the two most widely used null-modem wirings. Variant A is a "partial" null modem where RTS/CTS is looped only at the slave end; Variant B is a "full" null modem with RTS/CTS crossed, used when the slave drives hardware flow control.

5.3 Practical Recommendations

• Always connect pin 5. RS232 is not differential; a missing ground is the most common reason the slave's input is biased into the mark state and never sees a start bit.
• Loop RTS/CTS back to the slave's DTR/DSR if the slave is a "3-wire" device (it only exposes TD, RD, GND on its terminal block). For DB9-to-DB9 slaves, the wiring in the table above is the typical starting point.
• Disable hardware flow control in the CP 341's protocol parameters if the slave does not drive CTS — otherwise the CP 341 will hold its transmitter off because CTS is de-asserted.
• Twisting 2 and 3 together is not a valid cable. The crossover (2↔3) is the data swap, not a wire splice — the signal on each pin must reach the complementary pin on the other end.
• Cable length: keep RS232 cables under 15 m for 19200 baud and well under that for higher baud rates. Long RS232 runs are the second most common cause of CRC errors after a baud-rate mismatch.

6. Troubleshooting: TX/RX LED Diagnostics

The CP 341 has three front-panel status LEDs relevant to commissioning: RUN (green), SF (red/yellow), and the per-port TXD/RXD indicators on the serial connector or front bezel. The reported symptom — TXD and RXD never lit, even with a Modbus simulator — narrows the fault to one of three causes.

The most informative single test in this failure mode is to connect the CP 341 directly to a PC running a Modbus slave simulator on a known-good null-modem cable. If the simulator responds and the LEDs behave correctly, the CP 341, its project, and the cable are validated end-to-end and the problem is the field slave, not the CP. If the simulator also produces no TX/RX, the problem is in the CP configuration or in the cable between the CP and the simulator — and a null-modem cable with 2↔3, 3↔2, 5↔5 plus the handshake loopback of Section 5.2 is the next thing to build.

7. Commissioning and Verification

1. Online diagnostics: with the PG connected to the S7-300 CPU (MPI/PROFIBUS/Ethernet depending on the CPU), open the CP 341 in Module Information. Confirm:
   • Diagnostic buffer shows the driver loaded successfully.
   • Protocol is set to Modbus Master.
   • No parameter assignment errors.
2. Single-poll test: temporarily reduce the master program to a single FB call that reads one holding register from slave address 1. Trigger it manually with a watchdog bit. Watch the instance DB's DONE bit transition to TRUE and the ERROR bit stay FALSE.
3. Loopback test (no slave): connect CP 341 pin 2 to pin 3 at the slave end of the cable (with the slave unplugged). Issue a read request. The master will receive its own transmission as an echo, which is a useful test to confirm the CP 341's transmitter and receiver are alive, although it will not validate the slave.
4. Modbus simulator end-to-end: run a simulator on a PC at the slave's configured baud rate/parity, with the null-modem cable of Section 5. Verify the simulator logs the master's request and returns the expected response bytes.
5. Replace simulator with real slave: keep the same cable, swap the simulator for the field slave, change the slave address in the FB call to match. Verify the same register read succeeds.
6. Document the wiring: pin-by-pin diagram, cable part number, baud rate, parity, slave addresses polled, function codes used, and the data block offsets. This is the single highest-value deliverable in the project handover because the next person to touch the system will not have to re-derive it.

8. Field-Proven Caveats and Edge Cases

• 3-wire vs 5-wire slaves: many simple Modbus sensors expose only A, B, and ground on a terminal block. The CP 341 RS232 cannot drive a true RS485 slave directly — the user must use a 6ES7 341-1BH01-0AE0 (RS485) CP 341 for those, or add an external RS232↔RS485 converter. Trying to re-use the RS232 CP 341 with a converter works, but the converter must handle the turn-around delay itself or the first byte of the slave's reply will be lost.
• Modbus ASCII vs RTU: the same CP 341 dongle typically supports both, but the slave's manual will state which it expects. The two are not interoperable — an RTU master cannot talk to an ASCII slave. The CP 341 project parameter selects the mode globally for the port.
• Broadcast (address 0): the master can broadcast a write to all slaves, but only some function codes (5, 6, 15, 16) are valid for broadcast. No slave will respond, and the CP 341 will not time out waiting for one only if broadcast is configured in HW Config.
• Dongle loss: if the dongle is removed after commissioning, the CP 341 will refuse to load the driver on the next power cycle and the SF LED will be lit. The same applies if the dongle is damaged by ESD or by being removed while the CP is powered (which is allowed but not recommended).
• CPU stop behavior: when the CPU goes to STOP, the CP 341 stops issuing new Modbus requests. Existing half-completed requests will time out. This is normal but can trigger transient SF entries in the diagnostic buffer; do not chase them as faults.
• Multi-slave polling on a single port: the master program must enforce a minimum inter-message delay (3.5 character times for RTU) to keep the bus silent between transactions, otherwise slaves cannot distinguish frame boundaries. The CP 341 driver enforces this internally, but only for the messages it issues — it will not enforce it for a user-written ASCII protocol on the same port.

9. Frequently Asked Questions