CP441-1 Modbus RTU Slave over RS485: Capabilities and Limits

CP 441-1 Hardware Identification and Variants

The CP 441-1 is the single-channel, firmware-fixed point-to-point communication processor for the SIMATIC S7-400 family. It plugs into a single slot of an S7-400 central rack (CR) or expansion rack (ER/UR) and provides the CPU 41x with one serial interface to a field device. Siemens positions the module as the cost-reduced, limited-feature variant of the CP 441-2: a basic PtP module for the built-in drivers (ASCII, 3964, 3964R, RK512), not for the open, loadable-driver installations of the larger module.

Confirm the active MLFB against the Siemens Industry Mall or the S7-400 module catalog before procurement. Older revisions are subject to phase-out and reduced spare-part availability. For documentation, search the Siemens Industry Online Support at support.industry.siemens.com for the manual entry SIMATIC S7-400 Point-to-point connection CP 441 Installation and Parameter Assignment.

Module Architecture Summary

• One configurable serial port: RS232C, RS422 (4-wire full-duplex), or RS485 (2-wire half-duplex)
• Internal protocol firmware for ASCII, 3964, 3964R, and RK512 (master/slave)
• No socket for loadable drivers; the firmware cannot be extended by Modbus, USS, or third-party drivers
• Communication to the CPU is via the S7-400 backplane using the standard PII/PIQ I/O image area
• One 9-pin sub-D male connector at the front panel for the serial line

Physical Interfaces: RS232C, RS422, RS485

The front-panel connector is a 9-pin sub-D (DB-9M). The electrical standard is selected by a hardware jumper block on the module and is mirrored in the STEP 7 hardware configuration. The same connector pinout is used for all three electrical standards; only the jumpers and the configuration change.

RS485 Two-Wire Configuration Procedure

1. Power off the S7-400 rack. The jumper block on the CP 441-1 selects the electrical standard; on older revisions, it is a 6-position jumper strip (S1) on the module's left side.
2. Set jumpers for RS485 (refer to the silk-screen on the module; on revision 4 the silk-screen reads 485).
3. Wire the bus as 2-wire twisted pair, characteristic impedance ≈ 120 Ω, terminated at both ends with 120 Ω across A-B.
4. Bond the shield on one end only (typically the cabinet entry) to protective earth (PE).
5. Power the rack and configure the module in STEP 7 (HW Config) - see the configuration section below.

Native Protocol Stack and Why It Matters

The CP 441-1 carries its protocol firmware in on-board ROM. The four built-in drivers are:

These four are the only drivers the CP 441-1 will ever run. There is no firmware update mechanism that adds new drivers and no loadable-driver socket. If the remote device does not speak ASCII, 3964, 3964R, or RK512, the CP 441-1 cannot talk to it without custom code on the S7-400 CPU side that implements the missing protocol on top of the free-form ASCII driver.

Modbus RTU Master/Slave Support Matrix

The question most often asked of the CP 441-1 is whether it can serve as a Modbus RTU master or slave. The direct answer is no. The Modbus protocol stack is delivered as a loadable driver (DLL on the module's flash file system), and that delivery mechanism exists only on the CP 441-2 and the CP 341 - not on the CP 441-1.

This is a hardware-and-firmware constraint, not a configuration choice. The CP 441-1 firmware does not contain the Modbus state machine, the CRC-16 polynomial (0xA001), or the 3.5-character inter-frame silence timer. The module can drive the physical RS485 line, but it cannot impose Modbus semantics on the bytes that flow over it.

Workaround: Free ASCII Driver with Custom Modbus FB

There is a workable path: use the CP 441-1's free-form ASCII driver and implement the Modbus RTU state machine in the S7-400 CPU using the function blocks (FBs) supplied for ASCII transmission and reception. The work is non-trivial and is a real engineering project, not a configuration change.

Protocol State Machine (CPU-side)

1. On the first byte received after > 3.5 character times of silence, decode the slave address. If the address matches the local station, claim the frame; otherwise reset the receiver.
2. Buffer the function code, the data bytes, and the trailing 16-bit CRC (Modbus RTU CRC, poly 0xA001, init 0xFFFF, low byte first).
3. Validate the CRC over the entire frame. If it fails, drop the frame silently; the master's timeout will handle the retry per Modbus spec.
4. Build the response frame, prepend the address, append the CRC, and hand it to the CP via the SEND FB. Use the ASCII driver's option to monitor CTS during transmit to drive the half-duplex turnaround.
5. Implement function codes 01, 02, 03, 04, 05, 06, 15, 16 at minimum for holding and input registers and coils. Add exception codes 01, 02, 03 for illegal function, illegal address, illegal data value.

ASCII Driver Configuration on the CP 441-1

The biggest practical issue with the ASCII driver for Modbus is the absence of a built-in 1.5 / 3.5 character silence timer. The CP 441-1 ASCII driver waits for user-supplied start and end characters, not for line silence. The CPU must therefore implement a free-running timer interrupt (e.g., OB35 at 100 ms) and measure the inter-byte interval itself, declaring a frame end when 3.5 character times have passed without a new byte. The math: at 19200 baud with 11 bit-times per byte (1 start, 8 data, 1 parity-or-stop, 1 stop), 1 character time ≈ 0.52 ms, so 3.5 char ≈ 1.83 ms.

ST Code Skeleton: Modbus RTU Frame Validator (CPU-side)

// Pseudo-code: validate incoming Modbus RTU frame
// Inputs:  pFrame : POINTER TO BYTE
//          uLen   : UINT  (received length, includes CRC)
// Output:  bOk    : BOOL  (TRUE = CRC valid)

FUNCTION_BLOCK fbModbusCrcCheck
VAR
  crc    : WORD := 16#FFFF;
  i      : UINT;
  lowBit : BOOL;
END_VAR

FOR i := 0 TO uLen-1-2 DO          // exclude last 2 bytes (CRC)
  crc := crc XOR pFrame[i];
  FOR bit := 0 TO 7 DO
    lowBit := (crc AND 16#0001) <> 0;
    crc := SHR(crc, 1);
    IF lowBit THEN crc := crc XOR 16#A001; END_IF;
  END_FOR;
END_FOR;

// Compare low byte first (Modbus RTU wire order)
IF (crc AND 16#00FF) = pFrame[uLen-2]
   AND (SHR(crc, 8) AND 16#00FF) = pFrame[uLen-1] THEN
  bOk := TRUE;
ELSE
  bOk := FALSE;
END_IF;

Migration Path to CP 441-2 (Native Modbus Support)

When the protocol, response time, and engineering budget make the custom-FB route uneconomical, the correct action is to swap the CP 441-1 for a CP 441-2. The slot, backplane interface, and STEP 7 project structure remain identical. The differences the engineer must plan for are:

Use the Siemens Modbus Master and Modbus Slave loadable drivers (search the Siemens Industry Online Support at support.industry.siemens.com for the current driver article number) to add native Modbus RTU support. The license key for the driver is delivered with the package; the driver itself is installed into the module's file system via the CP 441-2's web interface or via STEP 7.

STEP 7 Hardware Configuration

Configure the CP 441-1 in HW Config so the engineering tool knows the protocol driver, the baud rate, and the start-of-receive / end-of-receive semantics. The procedure below applies to STEP 7 V5.5; TIA Portal HSP workflows differ slightly but expose the same parameters.

1. In SIMATIC Manager, open the S7-400 station. In HW Config, drag the CP 441-1 from the hardware catalog (SIMATIC 400 > CP-400 > PtP) into the slot it physically occupies.
2. Open the module's properties. Set the interface type (RS232C / RS422 / RS485) under the Interface tab; this must match the hardware jumper position.
3. Under the Protocol tab, select ASCII driver (or 3964, 3964R, RK512). The Modbus Master and Modbus Slave entries are greyed out for the CP 441-1.
4. Set baud, parity, data bits, stop bits, the start-of-receive character (optional), and the end-of-receive character (optional). For Modbus-emulation work, set both start and end characters to none and rely on the silence timer implemented in the CPU.
5. Under Diagnostics, enable the diagnostic buffer entries. These buffer entries are what STEP 7's Module Information (online > module information > diagnostic buffer) reads back when troubleshooting.
6. Compile and download the HW Config. Restart the CPU if prompted.

Programming Interface: FBs, Status Words, and Error Codes

Application programs on the S7-400 CPU exchange data with the CP 441-1 using three function blocks from the Standard Library > Communication Blocks package. These FBs ship with STEP 7 V5.x and do not require a license.

Status Word (STATUS) Bits

Both P_SND and P_RCV return a STATUS word. The most relevant values for RS485 half-duplex and Modbus-emulation work are:

These status codes are documented in the CP 441 installation and parameter assignment manual and are the primary field-debugging handle when an integration with a third-party device fails.

Diagnostic LEDs, Buffer, and Error Codes

The CP 441-1 front panel carries a small set of status LEDs. The SF (group error) LED is the only one to monitor during commissioning; on later hardware revisions the panel also shows per-port TX/RX activity. The diagnostic buffer is the authoritative source for time-stamped events; it is read with STEP 7's online Module Information tool.

When the SF LED is lit, open the online diagnostic buffer first. Common events include RS485 framing error, no CTS for > x ms, and buffer overflow - each is timestamped and points to the line, not the application.

Timing, Throughput, and Buffer Constraints

Engineers forget the buffer limits. The CP 441-1 has fixed-size send and receive buffers; exceeding them drops characters without raising an application error.

Commissioning Checklist and Verification

1. Set the hardware jumpers for the required electrical standard before powering the rack.
2. Configure HW Config: interface type, protocol, baud, parity, data bits, stop bits, start/end characters (or none for Modbus-emulation).
3. Wire RS485 with 120 Ω termination at both physical ends; verify the shield is bonded to PE at one end only.
4. Power the rack; confirm the SF LED is off. Read the diagnostic buffer; it should be empty after a clean start.
5. Run the supplied sample program (e.g., the CP 441 ASCII example project) to send a known test string to a PC running a terminal emulator.
6. From the PC, send a known string back; verify it lands in the configured receive DB and the P_RCV STATUS is 0.
7. For Modbus RTU slave emulation: use a Modbus master (e.g., a PC running Modbus Poll or a real master PLC) to read holding registers 40001-40010. Verify the response frame in a bus analyzer (Wireshark + RS485 tap, or a dedicated protocol sniffer) matches the spec exactly: address, function code, byte count, register values, CRC low byte first.
8. For long-term stability, run the link for 24 h with the master polling at 100 ms and log all FB STATUS values to a data block. A non-zero STATUS repeating more than 1% of polls is a sign of line or timing trouble.

Comparison Matrix: CP 441-1 / CP 441-2 / CP 341

Frequently Asked Questions