Troubleshooting Siemens CP 341 Modbus Errors 0x830/0x831 with Schenk Intecont Plus Weighing Units

1. Problem Overview

A Siemens S7-300 station with a CP 341 communication processor (RS-422 physical interface, Modbus RTU master driver) is unable to read more than one Schenk Intecont Plus weighing terminal on the same multi-drop bus. Single-slave communication works reliably; as soon as a second slave is added, the master returns Modbus error codes 0x830 and 0x831 sporadically. A trace taken on the slave's fieldbus monitor shows that every master request triggers a correct reply and a second reply, containing only zero bytes, sent approximately two seconds later (equal to the configured Reply Monitoring Time).

The symptom is characteristic: one valid response frame followed by an unsolicited all-zero frame every time the master polls any slave on the bus. The problem does not appear with only one slave connected; it appears the moment a second Schenk Intecont Plus node is placed on the same differential pair.

2. System Configuration

2.1 CP 341 Module Identification

The CP 341 (order number 6ES7341-1xH0x-0AE0 family) is a single-port serial module for S7-300 with three physical variants:

• 6ES7341-1AH00-0AE0 — RS-232C (20 mA TTY as option)
• 6ES7341-1BH00-0AE0 — RS-422/RS-485 (X27 interface)
• 6ES7341-1CH00-0AE0 — RS-485 (X27 interface)

The Modbus master and slave protocols are loadable drivers delivered as a separately licensed package. Confirm the licensed driver is present in the CP 341's flash and matches the module variant (RS-422/RS-485 for the multi-drop application).

2.2 Schenk Intecont Plus

The Schenk Intecont Plus is a belt scale / weighfeeder controller with serial Modbus RTU interface. The Schenk documentation shows both RS-422 (4-wire full-duplex) and RS-485 (2-wire half-duplex) topologies for multi-drop networks. The Easyserve configuration software includes a "Fieldbus monitor" that can be used to capture frames on the slave side for comparison with master-side traces.

3. CP 341 Modbus Error Code Reference

The Modbus driver running on the CP 341 returns error codes in the STATUS parameter of the loadable function blocks. Two error codes appear in this case:

3.1 Reading the Status Word

In an S7-300 / Step 7 classic project the error is normally evaluated as:

// ST example - evaluate CP 341 Modbus master call
IF FB8_RET <> 0 THEN              // P_SND_RK / Modbus master
    CASE STATUS OF
        W#16#0830: // protocol error - inspect RX buffer
        W#16#0831: // timeout - check RMT and physical layer
        W#16#0832: // frame error - check baud, parity, cabling
        W#16#0833: // parity or overrun
        ...
    END_CASE;
END_IF;

Activate the "Receiving buffer enabled" option in HW Config for CP 341 so that the unsynchronized all-zero frame can also be examined via P_RCV_RK, which makes the diagnosis of a slave-echo problem straightforward.

4. Root Cause Analysis

Three independent failure mechanisms are credible; field evidence in this case points to the first one.

4.1 Slave-Echo / Bus-Contention Hypothesis (confirmed)

When the master sends a request to slave A, slave A correctly answers with a valid Modbus RTU frame. Two seconds later (equal to the RMT configured on the slave), an unsolicited frame containing only 0x00 bytes is transmitted on the bus. When two slaves are on the same pair, every master request produces:

• 1 correct response from the addressed slave
• 1 unsolicited all-zero response from the other slave

With three slaves, you get one correct frame and two all-zero frames per request, which matches exactly what the fieldbus monitor captured. The most likely cause is that the Schenk firmware is broadcasting a passive "no-data" frame on the RS-485 driver whenever it is addressed or whenever a bus idle timer expires, and that frame is being interpreted as a reply to the previous request by the master state machine.

4.2 Termination and Bias Issue (secondary)

RS-422 and RS-485 require proper termination at both ends of the bus (typ. 120 Ω) and fail-safe biasing to keep the differential line in a defined idle state when no driver is active. Without fail-safe bias, the CP 341's UART may interpret line noise as a start bit and latch the receiver, producing short all-zero frames that masquerade as valid Modbus responses. In this case the Schenk manual does support bias, and the symptom persists with bias configured, so this is not the primary cause.

4.3 RMT Mismatch Hypothesis (ruled out)

Increasing Reply Monitoring Time from 2 s to 10 s on both master and slave did not change the result. The all-zero frame is therefore not a late correct response; it is a separate, unsolicited broadcast by a slave. Lengthening RMT only shifts the time at which the error appears.

5. RS-422 vs RS-485 for Multi-Drop Modbus

Modbus over RS-485 (2-wire half-duplex) is the de-facto standard for multi-drop. RS-422 (4-wire full-duplex) is permitted by the Intecont Plus manual but is rarely used for Modbus RTU because:

• RS-422 has separate TX and RX pairs; only one pair carries data in Modbus RTU, leaving the other pair idle.
• Drivers on the unused pair can remain enabled, turning the bus into an accidental multi-transmitter system that is hard to bias.
• Most CP 341 applications that need multi-drop select the 2-wire RS-485 variant (6ES7341-1CH00-0AE0) and configure the X27 jumper for "RS-485 2-wire".

Switching to a 2-wire RS-485 topology did not resolve the issue in this application because the root cause was the slave firmware, not the topology. In 2-wire mode, the receiver on the master stayed enabled, causing it to "see" every passive frame including the spurious ones from the second slave. The bus thus looked continuously busy even when no master request was on the wire.

6. Reply Monitoring Time (RMT) and Interference Suppression

6.1 Reply Monitoring Time

The CP 341 Modbus driver uses RMT to determine how long to wait for a slave response before reporting timeout. Default values depend on baud rate:

For Intecont Plus, RMT 2000 ms is appropriate. If the firmware requires more than 2 s to assemble a reply, raise it to 5000 ms or 10000 ms only after confirming the slave itself is set to a matching value; otherwise the slave drops its reply before the master starts listening.

6.2 Interference Suppression Mode

CP 341 driver offers two operating modes for Modbus master:

• Normal mode: Receiver is enabled immediately after the master finishes transmitting. Any echo on the bus can be picked up as data.
• Interference suppression mode: Receiver is held disabled for a configurable settling time after TX completes. This blocks short echo/reflection bursts from corrupting the response.

Set Interference Suppression to 50–100 ms for 9600 baud multi-drop. The CP 341 documentation lists the supported values; a too-high value will delay valid responses and may exceed RMT on slow slaves.

7. Diagnostic Procedure

1. Capture with Easyserve Fieldbus monitor. On each Intecont Plus, start the Easyserve "Fieldbus Monitor" and log traffic with only one slave connected. Confirm a clean master/slave exchange with no all-zero frames.
2. Add the second slave and re-capture. Confirm the appearance of unsolicited all-zero frames.
3. Enable "Receiving buffer enabled" on CP 341 in HW Config. Wire FB 7 P_RCV_RK into the OB1 cycle and dump the RX buffer to a DB so the master side sees the same zero-frame evidence.
4. Run a bus analyser on the differential pair (e.g. a USB-RS485 dongle with Modbus Poll in "Listen Only" mode) to confirm the slave is the source of the zero frame, not noise.
5. Try Interference Suppression mode at 50 ms increments. If the error disappears for some settings but not others, the cause is reflection/echo.
6. Try each Schenk firmware revision in turn if the vendor offers a multi-drop-tested build.
7. Try a 2-wire vs 4-wire topology as recommended by Kaulquappe's classical advice: use 2-wire RS-485 for multi-drop.
8. If nothing works, fall back to a multiplexer. See Section 8.

8. Multiplexer Workaround (DO + Relays)

When the slave firmware is unable to coexist with another Modbus slave on the same bus, the only practical remedy is to keep the slaves on separate point-to-point links and switch between them with a hardware multiplexer. In this project the user built such a multiplexer using the S7-300's digital outputs and a relay bank.

8.1 Architecture

                +----------- CP 341 (RS-485, 2-wire)
                |
       +--------+--------+
       |                 |
       |                 |
   [DOut Q0.0]      [DOut Q0.1]   ... [DOut Q0.n]
       |                 |
   +---+---+         +---+---+
   | Relay|         | Relay|
   +---+---+         +---+---+
       |                 |
       +-- RS-485A ------+-------- A
       +-- RS-485B ------+-------- B
                                |
                            Intecont Plus #1
                            (point-to-point, no bus contention)

Identical for slave #2 .. #n, each on its own relay pair.

8.2 Ladder Logic Skeleton

// Each cycle:
// 1. Open all relay outputs
// 2. Wait for line to settle (50-200 ms timer)
// 3. Close the relay for the addressed slave
// 4. Wait for relay contact bounce (e.g. 200 ms)
// 5. Send Modbus request via FB 8 P_SND_RK to FB 7 P_RCV_RK
// 6. Read response
// 7. Store or process
// 8. Move to next slave on next scan

This converts a multi-drop Modbus network into a round-robin poll of point-to-point links. Each slave sees only its own request and only its own reply, so the bus-echo problem cannot occur.

8.3 Relay Selection

• Use DPDT (or DPST-NO × 2) signal relays rated for low-level switching.
• Choose relays with gold-plated or silver-palladium contacts; common Cu contacts oxidise and produce intermittent open circuits.
• Typical pick: Finder 55.34, Omron G6K-2F-Y, or Phoenix Contact PLC-OSC relay modules.
• Add 120 Ω termination at each slave end, not at the relay contact side, to avoid reflections when contact bounce occurs.

8.4 Cabling Considerations

9. Alternative Solutions

9.1 Upgrade Intecont Plus Firmware

Contact Schenk Process (now part of Schenck Process Group) for firmware revisions with confirmed multi-drop support. Some early firmware loads only support Modbus point-to-point and the unsolicited zero-frame is a side-effect of the legacy broadcast logic.

9.2 Use a CP 341 per Slave

Each S7-300 slot accepts one CP 341. For systems with many slaves the simpler architecture is one CP 341 per slave (each with its own point-to-point Modbus link). This eliminates the multiplexer at the cost of extra hardware. Modern equivalents (CM 1241 for S7-1200, CM PtP for S7-1500) are smaller and cheaper than the legacy CP 341.

9.3 Replace CP 341 with a Modbus TCP Gateway

Add a Modbus RTU-to-Modbus TCP gateway (e.g. Anybus X-gateway, HMS Edge, Phoenix Contact GW MODBUS) and talk to each slave as a separate TCP connection. The gateway manages RS-485 contention internally and exposes a clean Modbus TCP interface to the S7-300/400 via CP 343-1.

9.4 Use S7-1200/1500 Instead of S7-300

Modern CM PtP modules (CM 1241 RS-485, CM 1541 RS-485) ship with native Modbus master/slave libraries, eliminating the loadable driver and providing better diagnostic buffers and status codes. Status reporting in TIA Portal makes it easier to identify the same 0x830/0x831 errors.

10. Verification

After installing the multiplexer workaround, verify the following:

1. Polling cycle time. Cycle every slave within the required update period. With N slaves and 200 ms relay settling + 50 ms Modbus turnaround + actual transaction time, budget (N × 0.5 s) minimum. At 9600 baud with 16-byte requests, total poll time for 4 slaves is approximately 2 s plus Modbus turnaround per slave.
2. No error codes. STATUS from FB 8 should return W#16#0000 for every poll cycle. If 0x830 still appears, the relay contact is not opening fully or the unused branch is picking up induced voltage.
3. Data validity. Compare the values returned by the master against the Easyserve fieldbus monitor and against a manual reference weight placed on the scale. Confirm reading stability within the Intecont Plus datasheet accuracy.
4. Long-run stability. Run for 24 hours and verify no intermittent dropouts. Relay contacts can wear; check for contact resistance drift with a milliohm meter after 1,000,000 cycles.
5. EMI margin. With drives or VFDs on the same cabinet, repeat the long-run test under load conditions to confirm the multiplexer introduces no EMI susceptibility.

11. Troubleshooting Matrix

12. Field Commissioning Checklist

• Verify all CP 341 jumpers are set for the chosen physical variant (RS-422 4-wire vs RS-485 2-wire) before powering the rack.
• Confirm the Modbus master driver is licensed and matches the module variant.
• Set identical baud rate, parity and data bits on every device.
• Set identical RMT on master and slaves; document the value in the project folder.
• Configure fail-safe bias on the RS-485 master end if the CP 341 variant does not include it.
• Configure one and only one termination at each end of the bus.
• Capture a baseline Easyserve trace for each slave; archive as commissioning record.
• Document the multiplexer wiring and interlock logic so future maintenance is straightforward.

13. Standards and References for Verification

When validating any Modbus RTU multi-drop network, the authoritative reference is the Modbus Serial Line Protocol and Implementation Guide v1.02 by the Modbus Organization. It defines the 3.5 character inter-frame silence, the maximum 247 slave addresses and the 1200 m / 32 device bus limits. Verify the Schenk Intecont Plus meets these requirements against the actual product manual, not against marketing material.

The Siemens CP 341 manual covers the Modbus driver licensing, parameter assignment in HW Config and the loadable function blocks FB 7 / FB 8. Cross-check the STATUS return values against the manual version that matches the driver installed on the module.