CP 340 Modbus RTU to DCS Resolving CRC Errors and Protocol Limits

Problem Definition

A SIMATIC S7-300 station equipped with a CP 340 point-to-point communication processor must exchange process data with a Delta Distributed Control System (DCS) over a serial line. The DCS exposes only a Modbus RTU slave port (RS-485 two-wire, 9600 bit/s, 8E1) for third-party integration. The engineering team wires the CP 340 to the DCS, installs the SIMATIC PtP library shipped with STEP 7 V5.x, calls FB 2 P_SEND and FB 3 P_RCV in OB1, and begins hand-rolling Modbus request telegrams: slave address, function code, starting register, quantity, payload, and a manually computed CRC-16.

The very first transaction returns "CRC error" on the DCS engineering station. The PLC transmits frames that look correct in a serial analyzer, but the DCS rejects every telegram. Retries with reversed byte order, swapped polynomial, and different initial values of the CRC register (0xFFFF vs 0x0000) do not clear the fault.

This is a deterministic outcome of the CP 340 hardware/firmware design: the CP 340 does not contain a Modbus RTU data link layer. There is no on-board CRC-16 generator, no inter-frame timer, no automatic function-code dispatch, and no slave address filtering. The only protocols burned into the CP 340 firmware are ASCII and 3964R. Any Modbus RTU behavior on the wire is being synthesized in the PLC scan, and that synthesis cannot meet the timing tolerances the Modbus specification requires.

Root Cause

The CRC error reported by the Delta DCS is the visible symptom. Three independent root causes are stacked beneath it:

1. Protocol mismatch. The CP 340 firmware contains no Modbus RTU driver. Per the official CP 340 manual, the loadable drivers available for the module are ASCII, 3964R, and a printer driver; Modbus RTU master/slave is not on that list. See the protocol matrix in the Siemens CP 340 PtP documentation.
2. CRC-16 implementation drift. Modbus RTU specifies CRC-16 with polynomial 0xA001 (reflected 0x8005), initial value 0xFFFF, and no final XOR. Common PLC implementations compute the CRC over the wrong byte range, swap the low and high bytes when transmitting, transmit the CRC big-endian instead of little-endian, or include the silent interval bytes in the CRC window. Each of these defeats the DCS check.
3. Inter-frame timing violations. Modbus RTU requires a 3.5 character silence to mark frame start and end, and frames must be transmitted as a contiguous stream. The PLC scan is non-deterministic (typically 10 to 80 ms); if the user program builds the telegram inside DBs and then hands it to P_SEND, the bytes are buffered in the CP and emitted back-to-back, which is fine, but if the CRC is computed by user code in OB1 with multiple intermediate function calls, the CP 340's send buffer can be flushed in two segments separated by more than the 1.5 character inter-character threshold — causing the DCS to interpret the second half as a new, malformed frame.

CP 340 Hardware Identification

The CP 340 family is identified by MLFB (order number). Confirm the physical variant before any configuration work, because each interface type has different electrical limits and pin assignments.

Every variant above carries firmware that exposes only two protocol drivers: ASCII (transparent character mode with optional start/end characters and configurable fill time) and 3964R (Siemens proprietary SDLC-like protocol used between S5 and S7 partners).

Protocol Matrix — What CP 340 Will and Will Not Run

The Modbus RTU master/slave driver for CP 341 is sold as a separate package (MLFB 6ES7870-1AA01-0YA0 historically; the current designation lives under the SIMATIC S7-300 communication catalog). It is delivered on a floppy / DVD and bound to the CP 341 by a license key / hardware dongle. Without that dongle present on the CP 341, the loadable driver will not initialize and the CP falls back to ASCII / 3964R only.

Modbus RTU Frame Structure Expected by the DCS

Before choosing a fix, document exactly what the Delta DCS expects. A Modbus RTU frame follows this layout:

| Slave ID | Function Code | Data Field              | CRC-16 Lo | CRC-16 Hi |
| 1 byte   | 1 byte        | N bytes (variable)      | 1 byte    | 1 byte    |

For function code 03 (Read Holding Registers), the data field contains a 2-byte starting address, a 2-byte quantity, and the CRC-16 is computed over the entire preceding bytes (slave ID through last data byte). For function code 06 (Write Single Register), the data field contains 2-byte address and 2-byte value. For function code 16 (Write Multiple Registers), the data field contains 2-byte starting address, 2-byte quantity, 1-byte byte count, N x 2-byte registers.

CRC-16 parameters:

• Polynomial: 0xA001 (reflected form of 0x8005)
• Initial value: 0xFFFF
• Final XOR: 0x0000
• Byte order on the wire: low byte first, then high byte

A reference CRC-16 routine in Structured Text is shown later in the article so that engineers can verify the calculation when debugging third-party packages.

Solution Path Selection

Three legitimate solutions exist, ranked by Siemens-preferred order:

1. Path A — Upgrade to CP 341 with Modbus master/slave loadable driver. The supported, sanctioned path. Adds hardware cost and one-day commissioning but eliminates CRC and timing concerns.
2. Path B — Negotiate ASCII protocol with the DCS. If the Delta DCS exposes a generic ASCII serial port (many Delta controllers offer both Modbus RTU and a free-form ASCII channel), the existing CP 340 can be used with no hardware change.
3. Path C — Third-party Modbus RTU driver for CP 340. Available from independent vendors. Provides FB blocks similar to the CP 341 set. Siemens provides no support for these packages, and they often target a specific CP 340 firmware revision.

Solution Path A — Upgrade to CP 341 with Modbus Master

Hardware swap

1. Power down the S7-300 rack.
2. Remove the CP 340 module; preserve the backplane connector wiring list.
3. Insert the CP 341 in the same slot. The CP 341 is pin-compatible at the backplane but requires its own MLFB per interface type:
   • 6ES7341-1AH02-0AE0 — RS-232C
   • 6ES7341-1BH02-0AE0 — RS-485 two-wire
   • 6ES7341-1CH02-0AE0 — RS-422/RS-485 four-wire
4. Order the loadable Modbus driver license (dongle) from your Siemens distributor. The license is hardware-bound; one dongle authorizes one CP 341 module.
5. Wire the serial connector identically to the CP 340 wiring. RS-485 two-wire is the typical Modbus RTU wiring: A+ to DCS A+, B− to DCS B−, shield to ground at one end only, 120 Ω termination at each end of the trunk.

STEP 7 hardware configuration

1. Open the SIMATIC Manager project containing the S7-300 station.
2. In HW Config, delete the CP 340 from the rack and insert the CP 341 in the same slot.
3. Double-click the CP 341 to open its properties dialog. Under Interface, select the protocol: Modbus Master (RTU) or Modbus Slave (RTU). The CP 341 will refuse to load the driver if the dongle is not detected.
4. Configure the serial line parameters: 9600 bit/s, 8 data bits, even parity, 1 stop bit (8E1 is the most common Delta DCS setting; verify against the DCS documentation).
5. Set the CP 341 diagnostic interrupts if you want OB82 to fire on line faults.
6. Save and download the hardware configuration.

STEP 7 program structure with the Modbus master library

The loadable Modbus master driver exposes two FBs (block numbers vary by driver version; the modern designation is in the SIMATIC manual that ships with the dongle). The typical call pattern is:

// OB1 — cyclic call
CALL FB_MODBUS_MASTER, DB_MODBUS
   REQ        := M_REQ_START        // start a single transaction
   ID          := 0                  // logical CP 341 address (from HW Config)
   slave_addr  := MB_SLAVE_ID        // 1..247, Delta DCS node
   function    := MB_FC_READ_HOLDING // 03, 06, 16 etc.
   start_addr  := MW_MODBUS_START    // 0-based register offset
   qty         := MW_MODBUS_QTY      // number of 16-bit registers
   tx_data_ptr := P#DB_TX.DBX0 BYTE 32
   rx_data_ptr := P#DB_RX.DBX0 BYTE 256
   done        := M_DONE
   error       := M_ERROR
   status      := MW_STATUS

The library handles CRC-16 generation, inter-frame silence, and response validation internally. The status word returned to MW_STATUS follows the Siemens Modbus master convention:

Map each of these status codes to a tag in the PLC and to an alarm or HMI message so that operators can distinguish a real DCS fault from a wiring fault.

Solution Path B — ASCII Protocol to Delta DCS

Many Delta DCS controllers (e.g., DVP series PLC used as DCS node, or AH series with serial card) expose a configurable ASCII mode. In this mode the DCS sends and receives CR/LF-terminated text strings. The CP 340 handles ASCII natively with FB 2 P_SEND and FB 3 P_RCV; no CRC, no Modbus framing, no third-party driver.

Configure the CP 340 for ASCII

1. In HW Config, double-click the CP 340, select protocol ASCII.
2. Set baud rate to match the DCS (9600 8N1 is the typical default for Delta).
3. Set end-of-receive delimiter: CR (0x0D) or LF (0x0A) — match the DCS configuration exactly. If both are required, set both.
4. Set fill character delay if the DCS is slow (10 to 50 ms is common).
5. Disable XON/XOFF and disable any 3964R-specific parameters.

Application frame

Define a fixed-format text protocol with the DCS team. Example for a periodic data push:

<STX>PLC1,AI01=23.45,AI02=110.2,DI01=1<CR><LF>

The CP 340 transmits the entire DB byte-for-byte; the receiving DCS parses the CSV fields. CRC is not part of the protocol — protect integrity with a checksum character at the end of the line or rely on the parity bit and the periodic retransmission.

Solution Path C — Third-Party Modbus RTU Driver for CP 340

Independent vendors sell a Modbus RTU master/slave package that loads into a CP 340. Search the SIMATIC third-party catalog or contact your Siemens distributor for the current options. Each package typically provides:

• A DLL / loadable firmware for the CP 340 module.
• Two FBs callable from OB1 (one for sending, one for receiving) — block numbers vary by vendor; some assign FB 42 / FB 43 in the user project as the suggested block numbers, others use FB 100+.
• An installation routine that registers the driver against a specific CP 340 firmware version (commonly 1.x and 2.x; check the matrix in the vendor's release notes).

Reference CRC-16 Routine for Diagnostic Use

When debugging a third-party driver or hand-rolled implementation, drop this Structured Text function into a STEP 7 SCL source file and call it from OB1 to compute the expected CRC of a buffer. Use it to compare against what arrives at the DCS or against what the CP transmits:

FUNCTION FC_CRC16 : WORD
VAR_INPUT
   pData   : POINTER TO BYTE;
   iLen    : INT;
END_VAR
VAR
   i       : INT;
   j       : INT;
   crc     : WORD;
   b       : BYTE;
END_VAR
BEGIN
   crc := 16#FFFF;
   FOR i := 0 TO iLen - 1 DO
      crc := crc XOR WORD(pData^[i]);
      FOR j := 0 TO 7 DO
         IF (crc AND 16#0001) <> 0 THEN
            crc := (SHR(crc,1) XOR 16#A001);
         ELSE
            crc := SHR(crc,1);
         END_IF;
      END_FOR;
   END_FOR;
   FC_CRC16 := crc;
END_FUNCTION

Test vector: 01 03 00 00 00 0A → CRC = C5CD, transmitted as CD C5 (low byte first).

Hardware Configuration Walk-Through (CP 340 ASCII Example)

1. Open the STEP 7 project and load HW Config.
2. Drag the CP 340 from the hardware catalog onto the S7-300 rack. Confirm slot number matches the physical module.
3. Double-click the CP 340 → Properties. Set the interface to RS-485 if the DCS uses two-wire Modbus or to RS-232C for point-to-point ASCII.
4. Select protocol ASCII. (The Modbus RTU option will not appear — this is the confirmation that the CP 340 cannot do Modbus natively.)
5. Configure baud rate, parity, data bits, stop bits to match the DCS.
6. Set the start-of-receive trigger if the DCS sends framing characters; otherwise leave blank.
7. Assign the CP 340 to a logical interrupt OB if you need immediate notification of receive events (OB40).
8. Save, compile, download to the PLC. The CP 340 will not initialize until the configuration is downloaded.

Program Structure (CP 340 ASCII Path)

// OB1 — cyclic
// Build outbound data in DB100
      L     DB100.DBB0          // first byte
      T     DB110.DBB0          // mirror to send buffer
// ... copy full payload ...
// Trigger send
      A     M    10.0           // rising edge trigger from HMI or sequencer
      =     L     0.0
      A     L     0.0
      FP    M    10.1
      =     M    10.2
      CALL  FB    2, DB20
         REQ   := M10.2
         ID    := 0                // logical CP address from HW Config
         LADDR := W#16#100         // I/O base address of CP 340
         DB_NO := 110              // DB containing send buffer
         DBB_NO:= 0                // start byte offset in DB110
         LEN   := 64               // byte count
         DONE  := M20.0
         ERROR := M20.1
         STATUS:= MW22

// Receive
      CALL  FB    3, DB21
         EN    := TRUE
         ID    := 0
         LADDR := W#16#100
         DB_NO := 111              // receive DB
         DBB_NO:= 0
         LEN   := 256              // max buffer length
         NDR   := M21.0            // new data received
         ERROR := M21.1
         STATUS:= MW23
         LEN_OUT:= MW24            // actual byte count received

RS-485 Wiring Notes for Modbus / ASCII to Delta DCS

Do not ground the shield at both ends — this creates a ground loop that injects common-mode noise and corrupts bytes, surfacing as CRC errors or framing errors.

Verification and Commissioning

1. With the CP powered and configured, check HW Config → Online → Module Information. Confirm the diagnostic buffer shows no entry of type Module fault or Parameter assignment error.
2. From the STEP 7 online portal, open Monitor/Modify on the CP 340/341 diagnostic tags. Verify the line status (line idle, no break, no framing errors).
3. Connect a serial analyzer (or use a passive tap) between the CP and the DCS. Capture the first 10 transactions. Confirm byte timing and CRC visually.
4. Trigger a single read transaction from the PLC. Verify the DONE flag rises, the STATUS word is 0x0001, and the receive DB contains the expected register values mapped to the Delta DCS tag.
5. Trigger a single write transaction (function code 06 or 16). Read the same register back from the DCS to confirm the write landed.
6. Run the link under full PLC scan load for at least 30 minutes; verify no CRC errors appear in the CP diagnostic buffer or in the DCS event log.
7. Force a DCS-side slave fault (disconnect the A wire momentarily) and confirm the PLC ERROR flag rises within the configured response timeout and the STATUS word returns 0x8181 or the equivalent for your driver.

Troubleshooting Matrix

Choosing Between the Three Paths

For most brownfield integration projects where the Delta DCS is fixed and only exposes Modbus RTU, Path A is the correct answer. The cost of a CP 341 plus license is small compared to weeks of debugging hand-rolled CRC code on the CP 340, and the result is a Siemens-supported, deterministic link.

FAQ