Resolving Modbus RTU Errors on Sartorius Biostat with OMRON CJ1M

Connecting a Sartorius Biostat RM bioreactor that is supervised by an OMRON CJ1M-CPU23 to a Windows host over Modbus RTU frequently surfaces a stack of compounding errors: non-standard 9-pin pinouts, scrambled first bytes in the response payload, exception codes -2/-4/-8 from generic scanners, and puzzling slave ID values such as 0x33 in the leading byte of the reply. Most of these faults are not Modbus protocol defects at all; they are physical-layer, protocol-selection, and address-mapping mistakes. This reference walks through the diagnostic layers, explains what each symptom means, and provides a field-proven commissioning procedure for the OMRON CJ1W-SCU21-V1 Serial Communications Unit that converts the controller's native CompoWay/F traffic into a true Modbus RTU master or slave.

1. Problem Overview

The fault picture on a Sartorius Biostat RM with an OMRON CJ1M-CPU23 controller is recognizable by the following telemetry:

• Single 9-pin D-sub on the controller (no native Modbus firmware; uses CompoWay/F).
• Vendor-supplied 9-pin connector on the bioreactor with non-standard pinout, including a 5 V source pin that is not present on a TIA-574 / RS-232 DB-9.
• Host running Chipkin CAS Modbus Scanner, with an RS-232 to USB converter between the laptop and the bioreactor.
• Polling Holding Registers using 1-based addresses such as 40001..40053 with offset 7000 (e.g., 47001-47053).
• Response payloads starting with 0x33 instead of the expected slave ID 0x01.
• Scanner exception codes: -2 Message too Short, -4 Invalid Function Code, -8 Response Unknown, plus Modbus exception code 0x80 (Illegal Function) wrapped in error code 0x8E.

2. System Architecture and Hardware Identification

The Sartorius Biostat RM is controlled by an OMRON CJ1M-CPU23 modular CPU. The CJ1M-CPU23 ships with one built-in RS-232C port (peripheral port on the CPU) used primarily for programming with CX-Programmer and for CompoWay/F or Host Link (SYSWAY) traffic with lower-tier OMRON components. The CPU serial port does not support Modbus RTU or Modbus ASCII as a native protocol option; the Serial Gateway feature referenced in some documentation is a routing helper between FINS messages and a Modbus device, not a full Modbus master/slave implementation on the CPU port.

To obtain true Modbus RTU/ASCII master or slave behavior on a CJ-series rack, install the OMRON Serial Communications Unit CJ1W-SCU21-V1. The SCU21-V1 supports:

Reference: CJ1W-SCU21-V1 Datasheet (I63E) and the CJ-series Serial Communications Units Operation Manual (W336-E1).

Without the SCU21-V1 installed, the only Modbus-class traffic the CPU can emit is via the Serial Gateway bridge, which still requires that the destination device speaks genuine Modbus RTU; it will not reinterpret CompoWay/F frames as Modbus.

3. Physical Layer: RS-232 Pinout and Signal Requirements

The Sartorius DB-9 connector reportedly carries a non-standard pinout including a +5 V source pin. This is typical of laboratory instruments that use the same D-sub shell for both RS-232 and a TTL-level debug tap. Before connecting the host, verify the following against the Sartorius service manual for the specific Biostat RM revision:

Standard RS-232 (TIA-574) is a 3-wire minimum interface: TX, RX, and Signal Ground. With no hardware flow control required, the chipset should ignore CTS/RTS/DTR/DSR. If the Sartorius firmware requires a handshaking pin to enable the transmitter (common on older OEM firmware), loop RTS to CTS and DTR to DSR on the device side of the cable. Do not loop these on the host side, because that defeats the purpose.

For Signal Ground versus Field Ground: in instrument installations, the chassis (field) ground and the signal ground are often isolated by a 100 MΩ resistor and a few nF of capacitance. On long cable runs this can float several volts above the host's USB ground. If polling times out completely when using Signal Ground, tie the host's GND to the same chassis/earth reference as the bioreactor and try the Signal Ground again with a short, shielded cable (≤ 3 m). For USB, use an isolated USB-to-serial adapter (e.g., FTDI USB-ISO or similar with 2.5 kV isolation) to break ground loops between the laptop and the bioreactor.

4. Protocol Layer: CompoWay/F vs Modbus RTU Identification

Once a 3-wire RS-232 link is established, the next diagnostic step is to determine which protocol the device is actually transmitting. Two protocols are typical on OMRON-driven laboratory hardware:

• Modbus RTU - binary, 8-bit, framed by a 3.5-character silence gap and terminated with a 16-bit CRC-16 (polynomial 0xA001). Frame format: SlaveID | Function | Data... | CRC-Lo | CRC-Hi.
• CompoWay/F - OMRON proprietary master/slave protocol with ASCII or binary sub-variants. Frame starts with STX (0x02) in ASCII mode or a fixed header in binary mode, and uses a single-byte FCS (sum or 2's complement sum) instead of CRC-16. Sub-command 0x30 / 0x31 / 0x32 etc. read variable areas.

A reliable first test: with a serial bus analyser (e.g., a Saleae Logic or a dedicated RS-232 sniffer) capture the raw reply to a known Modbus RTU poll such as 01 03 00 00 00 01 C4 0B. The expected response on a working Modbus RTU slave is 01 03 02 VV VV CRC CRC where VV VV is the requested register value. If the capture shows:

1. First byte 0x33 and the rest of the payload does not match the CRC-16 polynomial - you are looking at a CompoWay/F or other proprietary frame.
2. First byte 0x02 (STX) - you are looking at CompoWay/F ASCII.
3. First byte 0x01 or 0xFF (broadcast) and trailing CRC valid - the device is genuinely Modbus RTU and the issue is elsewhere.

The CompoWay/F identification is confirmed in this case by the leading 0x33 byte in every reply. 0x33 is the ASCII character '3', which is the CompoWay/F ASCII framing for the FINS-level sub-command byte in some OMRON header layouts, or the device address expressed as ASCII. The fact that the response does not contain a valid CRC-16 over its full payload and that the scanner reports "Invalid Function Code" (-4) is the second confirmation. A Modbus RTU slave would never reply with a leading character other than the polled slave ID or 0x00 (broadcast) - the exception response format 0x81 for an unsupported FC03 still starts with the slave ID, not with 0x33.

5. The OMRON CJ1W-SCU21-V1 Communication Card Solution

When the Biostat RM's supervisory loop is an OMRON CJ1M CPU running CompoWay/F, the only field-recoverable path to a Modbus RTU master (host) is to expose a Modbus endpoint from the CJ1M itself. The CJ1W-SCU21-V1 is the canonical way to do this. Two deployment options exist:

5.1 Option A - SCU21-V1 as Modbus RTU Slave

The SCU21-V1 acts as a Modbus RTU/ASCII slave. The CJ1M-CPU23 ladder uses PMCR instructions (or the dedicated Modbus-RTU Easy Master FB from CX-Programmer's library) to write values from DM / CIO / HR / WR / EM memory into the SCU21-V1's protocol buffer. The host then polls the SCU21-V1 as a normal Modbus slave at unit number and port configured in CX-Integrator.

Memory mapping conventions used in the field:

Configure the SCU21-V1 to map DM7000..D7053 to Modbus Holding Register addresses 0..53 (0-based) or 40001..40054 (1-based). In CX-Programmer, open the I/O Table, double-click the SCU21-V1 unit, switch to the Modbus-RTU Easy Master or Modbus-RTU Slave Setup tab, and define:

• Protocol: Modbus-RTU Slave
• Baud: 9600 / 19200 / 38400 / 57600 / 115200
• Data length: 8 bits
• Parity: Even (matches Sartorius 57600, 8-E-1)
• Stop bits: 1
• Slave address: 1 (must match what the host polls)
• DM-to-Holding Register mapping offset: 0

5.2 Option B - SCU21-V1 as Modbus RTU Master talking to a downstream Sartorius instrument

If the Biostat RM has a downstream Sartorius slave that natively speaks Modbus RTU (e.g., a balance, a pH probe head, or a subordinate motor controller), the SCU21-V1 can act as a Modbus RTU master. In this case, the host (laptop) talks to the CJ1M's CPU port, and the CJ1M ladder uses PMCR + the Modbus-RTU Easy Master FB to read from the Sartorius and expose those values via Host Link or via a second SCU21-V1 port.

Reference: CJ1W-SCU21-V1 Datasheet (I63E) and the CJ-series Serial Communications Units Operation Manual (W336-E1).

6. Register Addressing Analysis

Modbus Holding Registers are addressed two ways in practice:

• 0-based (PDU addressing) - the cleanest form, used in the actual Modbus Application Protocol. The register number sent over the wire is 0..65535. The 4xxxx offset is purely a SCADA / historical convention.
• 1-based (legacy 4xxxx) - many PLC vendors and OEM datasheets (Sartorius included) use this. The first Holding Register is 40001; the address on the wire is 0. The address on the wire is address - 40001.

The Sartorius manual is explicit: the registers are 1-based, starting at 40001. The map calls the registers D7000..D7053, so the wire-level addresses are 0..53 (0-based) or 40001..40054 (1-based).

Translating the test attempts into wire-level addresses:

All six attempts fall in the same failure cluster. Because the leading response byte is consistently 0x33, the slave is not interpreting any of these as a valid Modbus request. Once the SCU21-V1 is installed and configured as a Modbus RTU slave mapping DM7000..D7053 to Holding Register 0..53, the same six tests should produce well-formed 01 03 .. responses with valid CRC-16.

7. Modbus Exception Code Interpretation

The standard Modbus exception codes (returned as SlaveID | 0x80 | ExceptionCode | CRC-Lo | CRC-Hi) are defined in the Modbus Application Protocol Specification v1.1b3:

The Chipkin CAS Modbus Scanner host-side codes are different - they describe the host's view of the link:

When 0x80 ("Illegal Function") wraps a 0x8E, the SCU21-V1 is rejecting the FC. In the SCU21-V1 Modbus slave mode, FC03 (Read Holding Registers) and FC06/FC10 (Write Single / Write Multiple Registers) are always supported, but FC05 and FC0F (coil writes) require the corresponding memory area to be mapped in CX-Integrator. If the user issued an FC01 or FC02 poll against an SCU21-V1 whose only mapped area is DM, the SCU returns 0x80.

Reference: Modbus Application Protocol Specification V1.1b3 and Modbus over Serial Line V1.02.

8. Step-by-Step Troubleshooting Procedure

Follow this sequence in order. Each step is gated on the previous one passing; do not skip.

8.1 Step 1 - Verify the Sartorius Pinout

1. Obtain the Sartorius Biostat RM Electrical Schematics and the Communications Option manual for the specific serial board revision.
2. With the bioreactor powered off, use a multimeter to identify the +5 V pin (it will read +5 V referenced to chassis ground with no cable connected).
3. Identify TX (data out of the device) and RX (data into the device) by tracing back from the Sartorius UART or by shorting one pin to GND and observing the device's echo behaviour.
4. Identify the Signal Ground pin (it should be galvanically isolated from chassis ground by > 1 MΩ).
5. Build a 3-wire cable: host TX → Sartorius RX, host RX → Sartorius TX, host GND → Sartorius Signal Ground. Do not connect the +5 V pin to anything.

8.2 Step 2 - Confirm Serial Parameters

From the Sartorius manual, the fixed serial parameters are 57,600 baud, 8 data bits, Even parity, 1 stop bit (8-E-1). Configure the USB-serial adapter and the CAS Modbus Scanner to match exactly. Mismatched parity will scramble the payload and produce exception -2 ("Message too Short") because the UART will frame-error and drop bytes.

8.3 Step 3 - Capture Raw Traffic

1. Insert a passive RS-232 line tap (e.g., a serial port splitter or a USB sniffer) between the Sartorius and the host.
2. In CAS Modbus Scanner, send a single FC03 poll to read 1 register at wire address 0: 01 03 00 00 00 01 (CRC).
3. Capture the reply on both TX and RX lines.
4. Decode the first byte of the reply. If it is 0x01 and the trailing two bytes form a valid CRC-16, the device is Modbus RTU - proceed to step 4. If it is 0x33, 0x02 (STX), or any other value, the device is not Modbus RTU and you must install the CJ1W-SCU21-V1 - skip to step 5.

8.4 Step 4 - Walk the Holding Register Map

Once Modbus RTU is confirmed, poll a small block of registers (e.g., 1 register at a time) starting at 0-based address 0 and incrementing. Compare the value read to the Sartorius data sheet. Common field issues:

• Sartorius returns 0xFFFF for "register not implemented" - it does not raise exception 0x02.
• Some Sartorius Holding Registers are signed 16-bit INT, others are IEEE-754 32-bit FLOAT (occupying two consecutive registers with little-endian word order). Reading only the high or low word will look like garbage.
• Coil (FC01) and Input (FC02) addresses are not the same as Holding Registers. If the manual lists D7xxxx, you must use FC03/FC06/FC10, not FC01/FC02/FC05/FC0F.

8.5 Step 5 - Install and Configure the CJ1W-SCU21-V1

1. Power down the CJ1M rack. Insert the CJ1W-SCU21-V1 into an available CJ-series slot. Apply power.
2. In CX-Programmer, go online, open the I/O Table, and let the rack auto-discover the new unit. Confirm the SCU21-V1 appears with its correct unit number.
3. Double-click the SCU21-V1 unit. In the Setup tab, set Port 1 to Modbus-RTU Slave, 57,600, 8-E-1, slave address 1 (or whichever the host will poll).
4. In the Protocol Macro tab or Modbus Mapping tab, map DM7000..D7053 to Holding Registers 0..53. If coils (FC01/FC05/FC0F) are needed, allocate a CIO range.
5. Download the configuration to the SCU21-V1 and cycle power to the CJ rack to confirm persistent settings.
6. From the host, poll the SCU21-V1 with FC03 at wire address 0, length 1. Expected response: 01 03 02 VV VV CRC CRC.

8.6 Step 6 - Write a Verification Ladder

In the CJ1M program, write a small rung that copies a known constant (e.g., 1234 decimal = 0x04D2) into D7000 on each scan. Then poll 01 03 00 00 00 01 from the host. The reply should contain 04 D2 (little-endian). If not, the SCU21-V1 mapping is wrong.

9. Verification and Commissioning Tests

Once the SCU21-V1 is online and the host is reading clean frames, run the following verification matrix:

Use the Chipkin CAS Modbus Scanner "Diagnostics" tab to monitor request/response counters and exception counts. A clean link shows zero exceptions, request count = response count, and round-trip time in the 5-30 ms range at 57,600 baud.

10. Frequently Asked Questions