Simoreg 6RA24 o10.3 Fault: X500 and X501 Port Diagnostics

Problem Overview: Simoreg 6RA24 Communication Status o10.3

The SIMOREG 6RA24 DC MASTER is a fully digital converter used for armature and field control of DC motors. In a duplex drive configuration, two 6RA24 chassis are frequently linked through their serial ports to exchange setpoints, status, and control words while a third master — typically a SIMATIC S5 PLC — supervises the pair over USS. When the operator panel displays status word bit o10.3 = 1 on either unit, the drive is signalling that the on-board serial port monitoring has lost its expected handshake. In the field case behind this article, the S5 program reports that one of the two converters has stopped responding, although the wiring, parameter set, and operating conditions had not been altered prior to the fault. The challenge is to identify which physical port (X500 peer-to-peer RS232 or X501 USS RS485) has degraded, and whether the fault sits in the drive's communications board, the cabling, or the partner device.

The 6RA24 product line and its communications option boards are documented in the Siemens service manual available on the Siemens Industry Online Support portal — see the SIMOREG 6RA24 Installation and Maintenance Guide (PDF). Always cross-check fault conditions, parameter numbers, and connector pin-outs against the device-specific manual shipped with the unit because the 6RA24 went through several firmware and option-board revisions between 1990 and 2000.

Simoreg 6RA24 Communication Architecture

Each SIMOREG 6RA24 chassis contains a CUD1 (Control Unit, Digital) board that hosts the field-oriented control firmware, the operator panel interface, and two physically separate serial ports brought out to sub-D connectors on the front of the electronics box:

• X500 — RS232 port reserved for peer-to-peer coupling between two 6RA24 chassis. In a typical master/follower (lead/follow) arrangement, drive 1 broadcasts the torque, speed reference, and control word at a fixed cycle, and drive 2 imports the telegrams directly without a PLC in the loop. The peer-to-peer link can be configured as 2-wire (TX/RX only) or 4-wire (TX/RX plus RTS/CTS handshake) — the field installation behind this article uses 4-wire.
• X501 — RS485 port for the Siemens Universal Serial Interface (USS) protocol. This port is the path between the converter and the supervising PLC, in this case a SIMATIC S5 CPU with a CP524 or CP521 communications processor. The PLC polls both drives cyclically, reads parameter values, and writes control words.

The two ports are electrically isolated from each other and from the power section, but they share the same CUD1 microcontroller, the same firmware revision, and the same parameter non-volatile memory. A failure of the CUD1, a corrupted parameter set, or a loss of supply to the option board can therefore knock out both ports simultaneously. A failure that affects only one port almost always points to a port-specific hardware fault, the cable, or the partner device.

The 6RA24 hardware platform supports a parallel set of peer-to-peer protocols selectable by parameter. Before declaring a port dead, always confirm that the firmware revision installed on the CUD1 actually supports the protocol you expect. A downgrade or a board swap from a donor chassis with a different firmware is a common root cause of o10.3 on commissioning days.

Physical Port Specifications: X500 and X501

Verify the connector gender on the actual chassis label before plugging in a cable — the documentation is consistent across the product line, but field repair tickets are not. The 6RA24 peer-to-peer protocol uses a small fixed-length binary telegram; the telegrams are not encrypted and not echoed to the operator panel. This is the reason a fault on the link surfaces as a status bit (o10.x) rather than as a string the operator can read.

Interpreting Status Code o10.3

The 6RA24 status word o10 is a packed 16-bit field in which each bit represents a single condition. Bit 3 of o10 (o10.3) is set when the on-board serial-channel monitor declares a loss of communication on the configured port. The exact meaning depends on the firmware build and on which port is the active link in the current parameter set, so always read the parameter description for the firmware build installed on the CUD1 before making a decision.

For the field-proven interpretation used by maintenance teams familiar with the 6RA24, o10.3 typically means one of the following:

1. No valid peer-to-peer or USS telegram has been received within the configured monitoring time window on X500 or X501.
2. A telegram has been received but contains a checksum or address mismatch — corrupted frame.
3. The CUD1 has detected an internal buffer overrun on the selected UART, indicating either a baud-rate mismatch or a hardware fault on the receiver.
4. The peer drive or the PLC has stopped transmitting because its own end of the link is faulted.

To confirm which port is the failing one, switch the operator panel to the corresponding diagnostic parameter group (typically the U and n parameters for the serial port monitor). If the firmware exposes a per-port telegram counter or an error counter, capture it before and after a 30-second observation window — a non-zero increment in the error counter while o10.3 is set is direct evidence that the port is the failing one.

Parameter P51 and Access Rights

Parameter P51 on the 6RA24 is the parameter-access key. By default the drive is in a read-only state and a number of write-protected parameters refuse changes. Setting P51 to a value supplied by Siemens (typically a numeric key code printed in the parameter list for the specific firmware build) unlocks write access to the rest of the parameter set. The original poster in the field discussion confirmed that changing P51 was the step that first allowed them to modify other parameters — this is normal and expected on the 6RA24.

Important considerations for P51 when chasing an o10.3 fault:

• P51 unlocks write access, but it does not change the underlying parameter values. It is not a fault-clear and it is not a baud-rate selector.
• If the CUD1 is power-cycled, P51 reverts to the locked state. You must re-enter the key code on every commissioning session.
• If the parameter set was ever reloaded from a backup (SIMOVIS upload/download), confirm that the backup contains the same P51-unlock value the drive is currently using. A mismatch will not produce o10.3 directly, but it can prevent the operator from clearing the fault flag.
• Do not enter the wrong P51 value more than three times in a row. The 6RA24 firmware may impose a lockout and require a power-cycle before accepting another attempt.

If the parameters on the failing drive were ever reset to factory defaults and then partially re-entered, the baud rate, the USS node address, the peer-to-peer node ID, and the telegram timeout values are the four parameters most likely to have been left at the wrong value. Re-confirm each of them against the partner drive and against the PLC's expected configuration before continuing.

X500 Peer-to-Peer RS232 Diagnostic Procedure

1. Disconnect the peer-to-peer cable from X500 on both drives and inspect the sub-D connector. Bent pins, broken hoods, and missing screws are the three most common physical defects on units that have been in service for ten or more years. Replace the connector hood if any pin shows oxidation.
2. Use a multimeter to verify the cable pin-out. For 4-wire RS232 peer-to-peer on the 6RA24, the required signals are TX, RX, RTS, and CTS, plus signal ground. A 1-to-1 cable will not work; the 6RA24 expects a crossover (null-modem) pin-out. Confirm against the schematic printed on the inside of the option-board cover or in the maintenance guide linked above.
3. Reconnect the cable and power both drives. On the operator panel of each unit, navigate to the peer-to-peer diagnostic menu. Most 6RA24 firmware builds expose a "peer telegram received" counter and a "peer checksum error" counter under parameters in the U-group. Read the counters and record them.
4. Run the drive for at least 60 seconds under the normal operating command. Re-read the counters. If the received counter is incrementing and the error counter is stationary, X500 is healthy. If the received counter is stuck at zero, the partner drive is not transmitting — escalate to the partner unit's X500.
5. If the error counter is incrementing at the same rate as the received counter, the cable is the prime suspect. Swap the cable for a known-good unit and repeat steps 3 and 4.
6. With both X500 ports and the cable ruled out, the next step is the CUD1 board itself. The peer-to-peer UART is soldered to the CUD1 — there is no field-replaceable sub-module on a stock 6RA24. Confirm by visual inspection that the option card (if fitted) is fully seated in its backplane connector. Reseat the card with the drive powered down. If the fault persists, swap the CUD1 with a spare if one is available (see Spare Control Card Swap Diagnostic below).

X501 USS RS485 Diagnostic Procedure

1. Power down the drive and disconnect the USS cable from X501. Inspect the connector and the cable. RS485 is differential and tolerates some wiring abuse, but a shield that has been pinched in a cable gland is enough to leak common-mode noise into the receivers and to cause intermittent telegram corruption.
2. Measure the resistance between pins A and B of the cable end that was just disconnected. With the drive end of the cable disconnected, you should read approximately 120 Ω if a termination resistor is fitted at the far end. If you read open circuit, the bus is unterminated. If you read below 60 Ω, more than two terminations are fitted — this is a common installation defect on multi-drop RS485 networks and will distort the signal.
3. Reconnect the cable and check the bias. RS485 requires idle-biasing on the bus. On the 6RA24 the bias is provided either by the master or by a dedicated bias resistor network on the bus. Without bias, the receivers float and the 6RA24 will report telegram timeout.
4. On the operator panel, read the USS diagnostic counters (typically n72x, n73x or similar in the firmware-specific parameter map). Compare the running telegram counter and the checksum error counter for the two drives. The drive that the PLC reports as failed should show zero new telegrams in a 60-second observation window; the healthy drive should show steady increment.
5. Confirm the USS node address of each drive. The 6RA24 default is 1; a duplicate address on a multi-drop bus produces a silent collision that may be reported as o10.3 on one of the two units. Re-address the drive and re-test.
6. Confirm the baud rate. USS standard is 9 600 bit/s with even parity and 2 stop bits. The 6RA24 also supports 4 800, 19 200, and 38 400 on later firmware builds. Whatever the drive is set to, the PLC must be set to the same value or the telegram stream is silently rejected.
7. Use an RS485 line monitor (a USB-to-RS485 adapter plus a protocol analyser such as the free "Modbus Poll" set to raw mode, or a dedicated USS monitor tool) to tap the bus. You should see the PLC polling both node addresses in a steady round-robin. If only one node is being polled, the issue is on the PLC side, not the drive.
8. Swap the X501 cable with a known-good shielded twisted pair. If the fault clears, replace the cable permanently — RS485 cables that have been flexed for years develop internal wire fractures that are invisible from the outside.

SIMOVIS-Based Port Verification

SIMOVIS is the original Siemens parameterisation and diagnostics tool for the SIMOREG 6RA24 family. It runs on a Windows PC and connects to a single drive at a time through a serial cable on X500. SIMOVIS does not communicate on X501; it is a service tool that uses the peer-to-peer port in service mode. The field technician who originated this question tried to bring up SIMOVIS over a PC serial port and failed — that is a useful diagnostic in itself, and the failure modes are predictable:

1. The PC's COM port is not configured to match the 6RA24's peer-to-peer service baud rate. The default in SIMOVIS is 9 600 8E1 (8 data bits, even parity, 1 stop bit). The 6RA24 may have been reconfigured to 19 200 or to no-parity by a previous commissioning session.
2. The PC's COM port is a USB-to-serial adapter that does not support the required handshaking. The 6RA24 peer-to-peer service channel uses full hardware handshaking on RTS/CTS. Many cheap USB adapters do not implement these signals in the Windows driver.
3. The 9-pin sub-D cable is wired 1-to-1. SIMOVIS requires a null-modem cable. Re-wire or replace the cable.
4. SIMOVIS is locked to a specific drive node address and will not connect if the drive's peer-to-peer node ID is set to anything other than the default.
5. The 6RA24 electronics box is unpowered at the auxiliary rail. The peer-to-peer UART is supplied from the auxiliary rail, not from the main power section. If the auxiliary fuse has blown or the auxiliary transformer is disconnected, the port is dead and no PC tool will see the drive.

If SIMOVIS connects successfully to either drive, it confirms that the X500 hardware on that drive is functional. The fact that SIMOVIS did not connect in the field case is not a definitive answer — it is a procedural failure. Retry with a known-good null-modem cable, a native PC COM port (or a high-quality USB-to-serial adapter with full handshake support), and the correct baud rate, and re-test. Once one drive responds to SIMOVIS and the other does not, you have isolated the fault to the non-responding drive's X500 hardware — most likely the CUD1 board.

Hardware Jumper and Cable Verification

The 6RA24 uses a small set of on-board jumpers to configure the option cards and the serial ports. The exact positions depend on the option board installed. The most relevant jumpers for the X500/X501 fault are:

If the drive was opened recently for a repair, or if a control card was replaced, the jumper positions may have shifted. The field-proven approach is to compare the jumper positions of the failing drive against the healthy drive. They should be identical. If they are not, copy the healthy drive's settings onto the failing drive and re-test.

Cable inspection should cover four items in this order: connector pin integrity, shield continuity, conductor continuity, and cable routing. RS232 in particular is sensitive to cable routing alongside VFD power cables or DC armature cables. The 6RA24 is a DC drive and the armature cable carries the full motor current at high dV/dt; running an RS232 cable in the same tray for any length is a recipe for induced noise that the UART will interpret as checksum errors.

PLC-Side Communication Verification with S5

The fact that the S5 program reports a communication failure on one of the two drives is itself a useful data point. To interpret it correctly, the engineer needs to know which of the following the S5 is doing:

1. Cyclic polling of both USS nodes with a configurable timeout. The S5 sets a "communication OK" flag that is reset on every timeout. The flag pattern on the operator panel can be cross-referenced against the S5 status to determine which side raised the alarm first.
2. Reading specific parameters from each drive (typically the actual speed, the actual current, and the status word) on a slow scan. The scan rate is irrelevant for the link integrity test but matters for the operator's response time.
3. Writing control words to both drives on a faster scan. If the S5 stops writing to one drive, the drive may time out and enter its own internal fault state.

To verify the PLC side, connect a service laptop running SIMATIC STEP 5 to the S5 and observe the online USS error counter. A high error count on one node is consistent with a cable or drive issue; an error count that alternates or is high on both nodes is consistent with a CP524 hardware fault or with a bus wiring problem that affects every node. The CP524 is itself a known weak point on aged S5 systems; if spare CP524s are available, swap the suspect one and re-test.

Spare Control Card Swap Diagnostic

If the diagnostic chain above narrows the fault to the drive itself and SIMOVIS still cannot reach the CUD1, the final field-proven step is to swap the control card. On the 6RA24, the CUD1 board is a single PCB that mounts to the electronics box via a backplane connector. The procedure is:

1. Record the full parameter set of the failing drive through SIMOVIS (if SIMOVIS is operational) or by hand from the operator panel. The parameter set is non-volatile on the CUD1 — if the new CUD1 ships with default values, the drive will not run.
2. Power down the drive, wait five minutes for the DC bus to discharge, and verify zero voltage at the armature terminals with a properly rated meter.
3. Open the electronics box, disconnect the ribbon cables and plug-in connectors, and remove the CUD1. Mount the spare CUD1 and reconnect.
4. Download the recorded parameter set into the new CUD1 using SIMOVIS, or enter the parameters by hand from the operator panel.
5. Power up and verify that o10.3 has cleared. If the fault has moved to the partner drive's panel, the original CUD1 is confirmed as the root cause and should be returned to Siemens for repair under the exchange programme referenced in the maintenance guide.

Siemens historically offered an exchange programme for out-of-warranty 6RA24 parts — the maintenance guide states that the Drive Products Business Unit offers an excellent exchange programme for repair of parts which are no longer under warranty. Use that channel rather than scrapping the CUD1; the repair cost is usually a small fraction of the new price.

Field-Proven Troubleshooting Matrix