S7-1200 CB 1241 Modbus RTU and PTP Multiplexing: Root Cause and Fix

This reference explains why an S7-1200 fitted with a CB 1241 RS485 board cannot reliably interleave MB_MASTER (Modbus RTU master) with SEND_PTP/RCV_PTP (Freeport ASCII) on the same physical port, what the "infinite busy, no done, no error" symptom really means, and the Siemens-recommended ways to keep both protocols running on one CPU. The article is targeted at commissioning engineers who are staring at MB_MASTER.BUSY = 1 and MB_MASTER.DONE = 0 while an RS485-TTL converter carrying ASCII traffic is connected to the same terminals.

1. Problem Statement: One Port, Two Protocols

The reported configuration is:

• Controller: SIMATIC S7-1200 (any CPU 1211C/1212C/1214C/1215C/1217C that accepts a Signal Board).
• Communication Board: CB 1241 RS485 (Siemens part number 6ES7241-1CH30-1XB0), plugged into the CPU's front SB slot.
• Modbus RTU master blocks: MB_COMM_LOAD V2.1, MB_MASTER V2.2 from the S7-1200 Modbus library (MODBUS family in TIA Portal).
• Freeport/PTP blocks: SEND_PTP and RCV_PTP V1.0 from the PtP library (formerly called USS/ASCII library).
• Termination convention for PTP: each frame is terminated by carriage return (0x0D).
• External hardware on the PTP side: an RS485-to-TTL converter, so the bus carries both a Modbus RTU master and an ASCII "PTP" device on the same twisted pair.

Behaviour as reported:

1. Modbus RTU alone, with the PTP cables physically disconnected: MB_MASTER returns DONE = 1 with valid data.
2. PTP alone, with the Modbus slaves disconnected: SEND_PTP returns DONE = 1 and RCV_PTP frames arrive terminated by 0x0D.
3. Both connected simultaneously: MB_MASTER sits at BUSY = 1 forever. DONE and ERROR never assert. The PTP traffic is also corrupted or lost.

The user has correctly observed that pulling the PTP cable "fixes" Modbus. This is the diagnostic fingerprint of a single-stack bus, and the rest of this article unpacks why.

2. Hardware Reference: CB 1241 RS485 Capabilities

The CB 1241 RS485 is a Signal Board (plug-in, mounted on the front of the S7-1200 CPU) that adds one isolated RS485 port. It is electrically and logically a single UART channel; there is no second serial interface hidden behind the same connector.

Critical consequence: the protocol stack is selected by the function block that issues the configuration. The port is not a multi-protocol channel; whichever function block is currently "owning" the port sets the framing rules (character format, parity, inter-character timing, line discipline). The Modbus RTU master, ASCII Freeport, USS, and 3964(R) stacks all assume exclusive ownership.

3. Modbus RTU Master Library on the S7-1200

The S7-1200 Modbus library (sometimes referred to as the "MODBUS" family) contains three blocks of interest:

Key parameters on MB_COMM_LOAD:

Key parameters on MB_MASTER:

Status outputs on MB_MASTER are the heart of the diagnosis:

Modbus RTU uses a strict framing rule: 3.5 character times of bus silence mark the start and end of a frame, and 1.5 character times of silence inside a frame are an inter-character error. At 9600 8N1, 3.5 character times ≈ 4 ms, 1.5 character times ≈ 1.75 ms. These numbers are baked into the MB_MASTER state machine - it cannot be told to be "lenient" about random bytes appearing on the bus.

4. PTP Instructions in TIA Portal

The PtP communication library on the S7-1200 contains:

For an ASCII device that terminates each frame with carriage return, Receive_Config is typically set with:

• Start condition: any character after silence, or a fixed start character.
• End condition: character 0x0D (CR), and possibly an inter-character timeout.
• Length: 0 (variable), max length as a safety stop.

Notice what is absent: there is no Modbus address byte at the start, no CRC-16 at the end, and no 3.5 character inter-frame discipline. The PTP stack treats the bus as a stream of free characters bounded by user-defined conditions. From the moment the port is handed to the Freeport stack, any Modbus-shaped bytes on the wire are meaningless to it; conversely, any ASCII byte from the PTP device is meaningless to the Modbus stack.

5. Why Multiplexing Two Protocols on a Single UART Fails

A UART (universal asynchronous receiver/transmitter) is a hardware block that shifts bits in and out at a configured bit rate with a configured character format. Each character is 8N1, 8E1, 8O1, etc. There is no concept of "this byte belongs to protocol A and that byte belongs to protocol B" inside the silicon. Whatever byte comes back from the line goes into the same receive FIFO.

The protocol stack running on the CPU decides whether the byte stream is valid. For the S7-1200 the choice is made implicitly by which function block has the port "open":

1. MB_COMM_LOAD with MODE = 1 leaves the port under Modbus RTU master control. The Modbus state machine expects a slave response beginning with a 1-byte address, a function code, payload, and CRC-16, all bracketed by 3.5 character silences.
2. The PTP blocks (Port_Config + SEND_PTP / RCV_PTP) put the port into Freeport mode. The receive state machine expects a configurable end condition (here, 0x0D).
3. Re-running MB_COMM_LOAD re-initialises the port and forces it back into Modbus mode; the next ASCII byte that arrives is then re-interpreted by the Modbus state machine as the first byte of a response.

Two stacks on one port means two parsers reading the same byte stream with two different grammars. Neither can succeed:

• When an ASCII frame (...0D) is on the line and the Modbus master is listening, the Modbus state machine sees 0x0D as a data byte inside a frame. If it falls within a 3.5 character window of the previous 0x0D, the frame is invalid; if it falls outside, a new "Modbus frame" begins with no valid slave address and no CRC. The master keeps waiting for a CRC that never arrives.
• When a Modbus frame is on the line and the PTP receiver is listening, the ASCII terminator 0x0D may or may not be present. Most Modbus payloads contain 0x0D bytes by coincidence (function code, address, CRC), so the ASCII receiver will terminate early, hand the user a corrupted buffer, and reset.

This is why pulling the PTP cable "fixes" Modbus. The bus is no longer carrying competing grammars.

6. Root Cause of "Infinite Busy, No Done, No Error"

The combination of BUSY = 1, DONE = 0, and ERROR = 0 is the most informative symptom. It is not a hardware fault. It is the Modbus state machine doing exactly what it was designed to do:

1. Master transmits a valid Modbus request (address, FC, payload, CRC) on the bus.
2. Master enters the response window. The state machine listens for at least 3.5 character times of silence, then a valid response frame.
3. The PTP device, in the meantime, transmits an ASCII frame that ends in 0x0D.
4. The Modbus state machine accumulates these bytes. No byte sequence satisfies "address + FC + payload + CRC" so the state machine never asserts DONE.
5. It also never asserts ERROR, because the bytes it has seen are not internally illegal - they just do not form a complete response. The block is "busy waiting for the response window to time out and the next request to be issued".

In other words, BUSY without DONE/ERROR means the master is talking, but no compliant Modbus slave has replied within the response window. On a clean RS485 bus with one master, this state is transient - a single timeout and the master moves on. On a contaminated bus, the master keeps being "distracted" by non-Modbus traffic and the busy state appears continuous.

7. Sequencing, Timing, and Port Configuration Rules

The questions asked in the original post - "Are pauses needed between MB and PTP calls? Do I need to execute MB_COMM_LOAD after each PTP? Is Port_Config required, once or after every MB?" - all have the same answer: protocol stacks are not designed to be hot-swapped inside one OB1 cycle. The Siemens libraries explicitly assume one stack owns the port for the lifetime of the session.

Reference rules from the S7-1200 communication documentation:

1. Call MB_COMM_LOAD once at startup, or once on a parameter change, with a rising edge on REQ. It is not required after every PTP message, nor after every Modbus request.
2. Do not call SEND_PTP / RCV_PTP while Modbus mode is active. The blocks will be rejected by the port driver, and a Modbus request in flight will be corrupted.
3. Do not call MB_MASTER while Freeport mode is active. The MB_COMM_LOAD call must be re-issued to return the port to Modbus mode, but doing so mid-bus will break any PTP session.
4. Port_Config is required once per port before the first Freeport send or receive. After that, SEND_PTP and RCV_PTP are sufficient for normal operation.
5. There is no way to "share" the port between two stacks by adding delays. The two stacks are time-sliced by Siemens' system resources (the serial port driver), not by the user program. The only thing a delay does is mask the symptom for a while.

There is no documented Siemens function block that performs protocol-stack switching on a per-cycle basis. The closest industrial solution is a hardware-level RS485 multiplexer (a "Y" switch controlled by a discrete output of the S7-1200), or two physical ports. See Section 9.

8. Diagnostic Procedure for the Reported Fault

Use this checklist before changing any hardware:

1. Confirm part numbers and firmware. CPU firmware, CB 1241 hardware version, and the Modbus/PTP library versions must match. In TIA Portal: Project tree → Devices & networks → Device properties → General → Catalog. Mismatched library versions are a common cause of hung masters.
2. Confirm device configuration of the CB 1241. In Device view → CB 1241 → Properties → Port configuration, verify baud rate, parity, data bits, and stop bits. They must match the PTP device's serial parameters, since the bus is shared in the user's wiring.
3. Confirm MB_COMM_LOAD wiring. REQ must be a one-shot (e.g. a tag set in OB100 or a first-scan bit), PORT must be the hardware ID of the CB 1241, and MODE must be 1 for Modbus RTU.
4. Check the call order in OB1. If MB_MASTER is called in the same OB1 cycle as SEND_PTP/RCV_PTP, only one of them can be active. The library documentation explicitly states that the PtP and Modbus libraries share the same serial port resource.
5. Capture the bus. Connect a Modbus RTU scanner (e.g. a notebook running Modbus Poll) or an oscilloscope/Logic Analyser to D+ and D-. A working Modbus master should produce 11-bit Modbus RTU frames (start bit, 8 data bits, parity, stop). If you see ASCII text or stray 0x0D bytes between master polls, the conflict is confirmed.
6. Measure inter-frame timing. Verify that the silence between Modbus frames is > 3.5 character times. If PTP traffic is interleaved inside this window, the Modbus state machine will not start a new frame.
7. Check MB_MASTER.STATUS at runtime. Even with ERROR = 0, STATUS can hold a non-zero transient code (e.g. 0x0001 for "response in progress"). Log the value over time to see if it ever changes.
8. Discipline one protocol at a time. First get Modbus working with the PTP cable physically removed. Then get PTP working with the Modbus cable physically removed. If both work alone but not together, the diagnosis is the protocol-stack conflict described in this article.

9. Recommended Fixes (Three Options)

Option A - Add a second physical port

Best engineering choice for any production system. Separate ports eliminate the protocol-stack conflict at the hardware level.

• Add a second CB 1241 RS485 (Signal Board). Note that most S7-1200 CPUs accept only one SB. If a second SB is not possible, use a CM 1241 module on the left-side bus.
• Or add a CM 1241 RS485 (left-side module) on CPUs that support it, e.g. CPU 1214C, 1215C, 1217C. Part number 6ES7241-1CH32-0XB0 for basic RS485, or 6ES7241-1CH40-0XB0 for the RS422/RS485 variant.
• Modbus stays on port 0 (CB 1241 in front slot), PTP goes on port 1 (CM 1241 on left side). The two stacks never compete for the same UART.

Option B - Convert one side to Ethernet

If either the Modbus device or the PTP device has an Ethernet variant, move it off RS485 entirely.

• Replace a serial Modbus slave with a Modbus TCP slave and use the S7-1200's onboard PROFINET port with the MB_CLIENT / MB_SERVER blocks (Modbus TCP is a separate library - the same naming collision is a common confusion point).
• Add a CM 1243-1 (industrial Ethernet) for additional PROFINET ports if the onboard port is fully used.
• Use a serial-to-Ethernet gateway (e.g. a Siemens SCALANCE or a third-party Modbus gateway) to bridge the serial device onto Ethernet.

Option C - Hardware RS485 multiplexer (last resort)

If adding hardware is impossible, an external RS485 multiplexer can switch the bus between two masters (or between a master and a freeport listener) under discrete control from the S7-1200. This is a field-proven workaround, not a Siemens-recommended solution.

• The PLC owns a digital output that selects which port of the multiplexer is connected to the bus.
• When Modbus needs to talk, the PLC deselects the PTP side, calls MB_COMM_LOAD (only once at startup is fine), then runs MB_MASTER.
• When PTP needs to talk, the PLC deselects the Modbus side and runs the Freeport sequence.
• The crucial rule: never have both ports of the multiplexer enabled at the same time. Otherwise the bus is electrically shared and the conflict returns.

10. Recommended Siemens Communication Hardware for the S7-1200

For an engineer choosing hardware, the following Siemens catalog references are the relevant options (selection depends on the CPU's free slots and the bus type):

For Modbus RTU on a Siemens PtP module, the same Siemens application note family that covers the S7-1500 (e.g. Master-Slave Communication via a CM PtP Using the Modbus RTU Protocol, available on the Siemens Industry Online Support portal under entry ID 68202723) is the canonical reference for the state machine, timing, and configuration approach, and the principles apply to the S7-1200 CB/CM 1241 modules. The S7-1500 PDF specifically covers the CM PtP variant, but the configuration philosophy - MB_COMM_LOAD is called once, MB_MASTER issues requests, the port is owned exclusively by the Modbus stack - is identical on the S7-1200.

11. Commissioning Checklist for the S7-1200 + CB 1241 Bus

Apply this checklist whenever you bring up a new RS485 segment on the CB 1241, regardless of whether you run Modbus or Freeport on it:

1. Cable: shielded twisted pair, characteristic impedance 100-120 Ω, ≤ 1000 m at ≤ 19200 bit/s.
2. Termination: 120 Ω at both physical ends of the bus, never in the middle. The CB 1241 has a switchable termination - use it only if the CB 1241 is at a physical end.
3. Common ground: the shield should be bonded at one end only (typically the cabinet entry); the signal ground reference must be common across all devices to avoid ground loops.
4. Pull-up / pull-down: many RS485 transceivers require fail-safe bias resistors (typically 680 Ω to Vcc and 560 Ω to GND) on the bus to define the idle state. Check the transceiver datasheet.
5. Baud rate match: every device on the bus must use the same baud rate, parity, and stop bits. The CB 1241 default for Modbus RTU is 9600 8E1.
6. Modbus address uniqueness: every slave must have a unique 1-247 address. The Modbus master assumes one slave per address.
7. Inter-frame timing: at 9600 8E1, 3.5 character times ≈ 4 ms. If the slaves are slow to respond, increase the MB_MASTER timeout - do not lower it.
8. Bus traffic logging: capture at least one minute of traffic with a serial analyser or Modbus scanner to confirm the master is the only transmitter during a Modbus session.
9. Diagnostic LEDs: the CB 1241 has transmit and receive LEDs. A green Tx flash with no Rx flash indicates that no slave is responding. A continuous Tx with no Rx is the visual signature of the "infinite busy" symptom described in this article.
10. Library versions: pin the Modbus and PtP library versions in TIA Portal so that firmware updates do not silently change block behaviour.

12. Inline Reference: ASCII Topology of the Conflict

The diagram below shows the physical wiring that produces the symptoms. Both stacks are present on the same two wires, which is the structural reason the conflict is unavoidable.

   +-------------------+        RS485 bus (D+, D-, GND)        +---------------------+
   |   S7-1200 CPU     |----------------------------------------|   Modbus RTU slave  |
   |   + CB 1241 RS485 |          (the CB 1241 is the           |   (FC 03 / FC 06)   |
   |                   |           only RS485 port)             +---------------------+
   |   MB_MASTER ----> |----> x x x x x x x x x x x x x x x x x x x x x x x x <-----+
   |   SEND_PTP  ----> |----> x x x x x x x x x x x x x x x x x x x x x x x x x x  |
   |                   |                                          +---------------------+
   +-------------------+                                          |  PTP device (ASCII, |
                                                                   |  frames end 0x0D)   |
                                                                   +---------------------+

   Note: a single UART cannot be owned by both the Modbus RTU stack
   and the Freeport (PtP) stack at the same time. The bus is
   electrically shared, so the two stacks corrupt each other.

13. Inline Reference: Modbus RTU vs ASCII Framing

The following comparison summarises why the two grammars cannot coexist on one bus.

The address and CRC-16 are mandatory in Modbus RTU. Their absence in an ASCII frame means the Modbus state machine will never validate a PTP frame, and the presence of a CRC-16 in a Modbus frame will never be expected by the ASCII receiver.

14. Verification: Confirming the Fix

After applying Option A (a second physical port) or Option B (Ethernet conversion), verify as follows:

1. With both cables connected, MB_MASTER.BUSY toggles between 0 and 1 per request. DONE asserts within the configured response window. STATUS is 0 on success.
2. The PTP side: SEND_PTP.DONE asserts after the configured number of characters are clocked out. RCV_PTP.NDR (new data received) asserts once per ASCII frame, and the received buffer ends in 0x0D.
3. Capture the bus with a serial analyser. Modbus frames and ASCII frames appear on separate physical wires (D+/D- of two buses), and the analyser's Rx traffic log shows clean Modbus RTU on one bus and clean ASCII on the other.
4. Run a 24-hour soak test. Modbus and PTP traffic coexist without errors. MB_MASTER.ERROR stays at 0. SEND_PTP.ERROR stays at 0.
5. Cycle power 10 times. Both stacks come up cleanly each time. The first Modbus request after a power cycle must succeed - this is the classic regression test for shared-resource bugs.

15. Key Takeaways

• The CB 1241 is a single-port, single-stack serial board. Modbus RTU and Freeport are not designed to be time-sliced on it.
• MB_MASTER at BUSY = 1 with DONE = 0 and ERROR = 0 is the diagnostic fingerprint of a Modbus master that has transmitted a request but is not seeing a compliant Modbus response. Non-Modbus traffic on the bus is the most common cause.
• MB_COMM_LOAD is called once, not on every cycle. Port_Config is called once, not on every cycle. The two configuration blocks belong to mutually exclusive operating modes.
• Adding a second physical port (CB 1241 + CM 1241, or two CM 1241 modules) is the cleanest fix. Converting one side to Ethernet (Modbus TCP or Modbus-to-Ethernet gateway) is the next best. A hardware RS485 multiplexer is a workaround and should be a last resort.
• For the S7-1200, the Modbus RTU master state machine cannot be reconfigured to tolerate random ASCII bytes; the protocol grammar is fixed by the library. Trying to add "pauses" between Modbus and PTP calls does not change this.

FAQ