3964R vs Modbus Slave on Siemens CP 341: Protocol Comparison

Engineers selecting a serial protocol for a SIMATIC S7-300 point-to-point link face a recurring question: should the application use the legacy Siemens 3964R procedure, or should it use the open Modbus protocol implemented as a loadable driver on the CP 341? The two are not interchangeable, and the wrong choice produces either a non-functional link (because the remote device does not speak the protocol selected) or a fragile link (because the protocol's addressing model does not match the data being exchanged). This reference details the technical differences between the two protocols, the CP 341 hardware variants, the STEP 7 parameter assignment, the programming blocks, and the field-proven decision path for a typical BMS (Building Management System) alarm integration.

1. Protocol Landscape on the CP 340 / CP 341

The SIMATIC S7-300 family supports a set of point-to-point (PtP) protocols through two communication processors:

The CP 341 additionally offers higher transmission rates (up to 76.8 kbit/s depending on firmware and interface) and supports the Modbus loadable drivers that are purchased as separate license dongles. The five protocols visible in the HW Config connection parameter dialog of STEP 7 / Simatic Manager (3964R, RK512, ASCII, Modbus master, Modbus slave) reflect this division:

• Siemens-proprietary — 3964R, RK512, ASCII (free, included in the CP firmware)
• Siemens loadable driver for an open standard — Modbus master / Modbus slave (licensed option)

The protocol selection is made in HW Config when the CP 341 is inserted into the S7-300 rack. The "Protocol" dropdown of the PtP port is the single point of decision; once a protocol is selected, the related FBs (function blocks) and DB (instance data block) structures become specific to that protocol. Re-selecting a different protocol after commissioning requires deleting the protocol DB and re-initializing the link.

2. The 3964R Procedure — Origin and Frame Structure

The 3964R procedure is a Siemens-developed data-link layer originally introduced for the SIMATIC S5 range. It was engineered for point-to-point, full-duplex connections and was paired with the higher-layer RK512 protocol to deliver a complete S5↔S5 (and later S5↔S7) file-transfer mechanism. The "R" in 3964R denotes Rückwärts-Sicherung (reverse / block-check security), and is what separates it from the basic 3964 procedure:

• 3964 — Uses control characters for handshaking but performs no block check. A corrupted block is detected only at the higher layer or not at all.
• 3964R — Adds an additive Block Check Character (BCC) over the user data; a NAK response requests retransmission on a checksum mismatch.

The protocol is described in chapter 2.5 of the Siemens manual SIMATIC S7 CP 340/CP 341 Communication — Manual (entry ID 1137332). Frame mechanics:

The transmission sequence for a master→slave frame is:

1. Master sends DLE+STX to request send priority.
2. Slave acknowledges within QVZ with DLE (priority granted).
3. Master transmits n user-data bytes. Any DLE inside user data is doubled (DLE stuffing).
4. Master closes the frame with DLE+ETX and the BCC.
5. Slave computes its own BCC; if it matches, slave replies DLE. If it does not match, slave replies NAK and the master retransmits.

The two time parameters that govern 3964R behavior are configurable in the CP 341's HW Config under the "Protocol" tab:

The 3964R layer is intentionally minimal: it has no addressing, no register model, and no function codes. It only knows how to deliver a block of bytes from one device to one other device. That is the entire reason 3964R is paired with RK512 when a structured S5↔S7 exchange is required.

3. RK512 — The Upper Layer Above 3964R

RK512 is a Siemens-defined application layer that turns the byte-pipe provided by 3964R into a request/response protocol with a small set of operations:

Each RK512 frame contains a 10-byte header (length, command, source DB/DW, target DB/DW, coordinator byte, payload type, data length) followed by the user data (up to 128 bytes per transaction in the classic implementation, 240 bytes in extended S7 implementations). Because RK512 references Siemens DB / DW addresses directly, it is essentially a Siemens-to-Siemens protocol. It has no native registration with any third-party device vendor, and any non-Siemens partner would have to re-implement the entire header semantics — which is rarely done in practice.

4. The Modbus Protocol Family

Modbus was released by Modicon (now Schneider Electric) in 1979 as a master/slave serial protocol. It became the de-facto standard for industrial serial communication and was later published openly. As documented in Different Types of Modbus (Chipkin Technical Article), there are three variants in active use:

Modbus TCP runs on an Ethernet physical layer and uses a 6-byte MBAP (Modbus Application Protocol) header to allow routing. Unlike RTU/ASCII, Modbus TCP allows multiple clients (not a strict master/slave) and is not limited to 32 devices on a segment. The CP 341 itself does not implement Modbus TCP — Modbus TCP on S7-300 is realized through a CP 343-1 Lean / CP 343-1 Ethernet interface, and a different software stack (e.g. the Modbus TCP library FB blocks) is used. The CP 341's Modbus loadable driver is strictly Modbus RTU master or Modbus RTU slave.

The Modbus register model is a flat 16-bit address space of four data tables:

32-bit values (REAL, DWORD) are not native to the protocol. They are transported as two consecutive 16-bit registers with the byte order big-endian by default; the CP 341 Modbus driver can be parameterized to swap word order to match little-endian S7 conventions. The engineer must specify in the Modbus database the start register and the word count for every variable exposed to the Modbus master.

5. Side-by-Side Technical Comparison

6. CP 341 Hardware Variants and Physical Interfaces

The selection of the physical interface on the CP 341 determines the cable, the maximum cable length, and the maximum number of devices on the bus. The three CP 341 variants in current production are:

For Modbus multi-drop BMS integration, the CP 341-RS422/485 is the correct choice. The RS-232C variant can only support a single point-to-point link and cannot connect to a multi-drop BMS trunk; if the BMS vendor requires RS-232C only, the network is reduced to one device per CP 341.

7. Protocol Configuration in STEP 7 / Simatic Manager

For the CP 341, the protocol is bound at the point of insertion in HW Config. The path is:

1. In SIMATIC Manager, open the S7-300 station and double-click Hardware.
2. In the hardware catalog, expand SIMATIC 300 > CP-300 > PtP and drag the required CP 341 onto slot 4–11 of the S7-300 rail.
3. Double-click the CP 341 in the rack to open its Properties - CP 341 dialog.
4. Switch to the Protocol tab and select either 3964R or Modbus slave from the dropdown. The dialog changes its sub-tabs accordingly.

For the Modbus slave selection, the engineer must:

• Enter the slave address (1–247) on the Modbus network.
• Configure the baud rate (1200, 2400, 4800, 9600, 19200, 38400, 57600, 76800 bit/s).
• Configure parity (Even, Odd, None-2-stop). Modbus RTU classically uses 8E1.
• Build the Modbus database (the mapping between Modbus registers and S7 DB addresses) — see Section 8.

For the 3964R selection, the engineer must:

• Set the baud rate and frame format (8E1 is the default).
• Set ZVZ and QVZ (defaults are 220 ms and 2000 ms; raise QVZ to 4000 ms for S5 partners).
• Decide whether the CP 341 is to be the active (initiating) or passive partner.

For modern S7-1200 controllers the configuration is performed in TIA Portal under Devices & Networks > PtP module > Port configuration > Protocol. The Configuring 3964(R) Communication page in the TIA Portal S7-1200 manual collection documents the field-of-view. The user is offered the same three drop-down options (3964, 3964R, ASCII) plus the Modbus RTU instructions. The TIA Portal path also exposes Modbus_Comm_Load (PT100) for parameterizing the port, and Modbus_Master / Modbus_Slave instructions for runtime.

8. Programming the Modbus Slave on the CP 341

When the CP 341 is parameterized as a Modbus slave, the engineering tool generates a single protocol DB that contains the entire Modbus database mapping. The runtime block on the S7-300 CPU is a single FB, typically FB80 (MODB_SLAVE) for the CP 341 Modbus slave loadable driver (per CP 341 Modbus Slave manual, entry 1218007):

Typical OB1 call:

CALL "MODB_SLAVE", DB80
  LADDR    := W#16#100          // CP 341 logical base address
  START_TIME := TRUE
  END_TIME := FALSE
  MODBUS_DB := "CP341_DB"
  OB_MASK  := B#16#FF           // all function codes 01/02/03/04/05/06/15/16
  STATUS   := MW100
  ERROR    := M101.0

The "protocol DB" itself is generated by HW Config under CP 341 Properties > Modbus Slave > Modbus Database. Each row in the table maps a Modbus register to an S7 DB and byte offset:

After the protocol DB is generated, the FB80 call above is the only periodic work required from the CPU — the CP 341 handles the Modbus state machine autonomously on its own processor.

9. Programming the 3964R Link on the CP 341

For a 3964R link, the CP 341 is parameterized as "active partner" or "passive partner" depending on whether the S7-300 initiates exchanges or simply answers. The runtime blocks for the legacy library are:

For 3964R with the RK512 upper layer, the Siemens FBs are typically called BSEND / BRCV (S7 communication) or the older SEND_RK / RECV_RK blocks. Because RK512 references DB / DW addresses, the engineer must define the partner's DB numbers and data word offsets in the call. There is no Modbus-style "register table" — the addressing is implicit in the block parameters.

10. Application Scenario: Sending Alarms to a BMS

The original question comes from a control engineer in Vietnam who must send alarm signals from a CPU 314 system to a third-party BMS. The relevant rack contains:

• CPU 314 (e.g. 6ES7314-1AF10-0AB0)
• CP 342-5 (Profibus DP master for S7-300 / S7-200 / ACB COM15)
• CP 341 (one slot free for PtP)
• DI / DO modules

The decision tree is short:

1. Identify the protocol the BMS supports. Honeywell EBI / E3, Schneider EBO / Continuum, Johnson Controls Metasys, ABB Cylon, Tridium Niagara — all support Modbus RTU as a standard driver. None of them support 3964R or RK512.
2. If the BMS supports Modbus TCP and not Modbus RTU, the CP 341 cannot be used — replace it with a CP 343-1 Lean (e.g. 6GK7342-1AL10-0XE0) and load the Modbus TCP FB library.
3. If the BMS supports Modbus RTU, install the Modbus slave loadable driver on the CP 341. License dongle order number is 6ES7870-1AA01-0YA0 (Modbus Master RTU) and 6ES7870-1AB01-0YA0 (Modbus Slave RTU).
4. Configure the CP 341-RS422/485 as Modbus slave, address 1, 9600 8E1, and build the protocol DB exposing the alarm coil / input register / holding register tables.
5. In OB1, call FB80 with the protocol DB. The BMS polls continuously; the CP 341 answers autonomously.

11. Commissioning Verification and Diagnostics

After the program is downloaded, verify the link with this checklist before handing over to the BMS vendor:

1. CP 341 module status — the SF (system fault) and BF (bus fault) LEDs must be off. A steady BF LED on the CP 341-RS422/485 means no character received in the last character-delay window; this is normal when the BMS is not yet polling but indicates a cable / termination problem if the BMS is actively polling.
2. Loadable driver active — under CP 341 > Module Information > Diagnostics, confirm the Modbus driver version (e.g. "Modbus Slave Vx.xx") is reported.
3. FB80 STATUS — should return W#16#0000 (no error) within 1–2 scan cycles of OB1 startup.
4. Frame capture — connect a serial tap (RS-232C / RS-485 line monitor such as a Wireshark with a serial adapter, or a Modbus-specific tool like Modbus Poll / ModScan) and confirm: BMS sends function code 02 / 03 / 04 with a valid CRC; CP 341 replies with the requested registers and a valid CRC.
5. End-to-end alarm test — force a real alarm bit in the S7 DB and verify the BMS receives the corresponding coil / register change within one BMS scan cycle (typically 1–5 s for RTU polling).

12. Troubleshooting Matrix

13. Frequently Asked Questions