Troubleshooting CJ1W-SCU21 RS-232C Port Lockup on Restart Bit

Troubleshooting CJ1W-SCU21 RS-232C Port Receive Lockup on Restart Bit

The CJ1W-SCU21 Serial Communications Unit is a two-port RS-232C module for the CJ-series PLC platform that occasionally locks its receive path even when port parameters are correct, the overrun and overflow flags remain clear, and the auxiliary-area Unit Restart Bit is asserted. The symptom is reproducible when polling a 1D/2D code reader that responds with a fixed-length message terminated by a CR (0x0D), and the receive buffer appears empty until the entire rack is power-cycled. This article documents the exact fault behavior, the auxiliary-area bits involved, the diagnostic procedure to confirm the condition, and the field-proven mitigation steps including migration of the serial protocol to CX-Protocol / Protocol Macro.

1. Fault Signature and Reproduction

The reported fault exhibits a very narrow set of conditions that make it both repeatable and confusing for field engineers:

• Communication is initiated by a serial trigger pulse sent from the SCU21 to the scanner, and the scanner responds with 8 data bytes terminated by a CR (0x0D) as the end code.
• The scan cycle is approximately 10 seconds, well below the port buffer capacity of the SCU21 (which is 8 KB per port for the receive buffer and 4 KB for the send buffer).
• The Port 2 Receive Counter increments for the first few hundred cycles, then stalls; subsequent RXDU(255) instructions return a zero-length result and the receive-complete flag never sets.
• The Port 1/2 Overrun Error Flag and the Port 1/2 Receive Buffer Overflow Flag remain clear in the allocated CIO area for the unit; no parity, framing, or FCS error bits are asserted.
• The end code (CR) is configured correctly in the DM setup area, the start code is disabled, and the data length is set to a fixed value that matches the scanner response.
• Asserting the Unit Restart Bit (A623.02 in the reported installation) for at least 100 ms, or for the dwell time documented in W494 section 2-2-2, has no effect: the receive-complete flag does not re-arm and the buffer remains inaccessible.
• Cycling power to the CPU rack restores normal operation immediately, confirming that the lockup is a residual port state and not a wiring or scanner fault.

The combination of "no error flag set" and "restart bit fails to clear" is the diagnostic fingerprint of the fault. A pure wiring problem would set a framing, parity, or overrun bit. A pure protocol problem would set an end-code mismatch bit. The fact that the restart bit is acknowledged but ineffective points to a firmware-level port state machine that requires a full power-on reset to reinitialize.

2. Affected Hardware and Firmware

The CJ1W-SCU21-V1 supersedes the legacy CJ1W-SCU21. Both share the same auxiliary-area bit layout, but the -V1 variant supports higher baud rates (up to 230.4 kbps) and offers improved Modbus RTU handling. The SCU21-V1 is also pin-compatible with the CJ1W-SCU31 (RS-422A/485) and CJ1W-SCU41 (RS-232C + RS-422A/485) for code portability; however, the auxiliary-area bit layout differs and the procedures in this article apply only to RS-232C SCU21 / SCU21-V1 units.

3. Auxiliary-Area Bit Map for CJ1W-SCU@1-V1

The W494 operation manual defines three categories of auxiliary-area bit for CJ-series Serial Communications Units mounted as CPU Bus Units. All three are read/write from the CPU and trigger an action inside the SCU module.

For the affected unit #3 / port #2, the operator toggled the bit at A623.02 expecting it to clear the receive buffer. According to Omron's response quoted in the field report, this bit triggers a firmware reset of the SCU module. A firmware reset re-initializes the UART controllers and the protocol state machine; however, in a small number of installations the receive-DMA descriptor and the protocol-state tables are not fully re-initialized on a warm restart, leaving the receive-complete flag latched in the "no-data" state until a true power-on reset clears the descriptor ring.

4. Root Cause Analysis

The investigation narrowed the root cause to one of three mechanisms, all of which are consistent with the observed symptom of "restart bit acknowledged, but receive still latched".

4.1 Receive State-Machine Latch-Up

The SCU21 firmware implements the receive-completion detection as a small state machine that tracks the end-code (CR) matching logic. When the scanner is idle for a long interval, the SCU21 leaves the state machine in a "waiting for first byte" condition. If a single noise byte is received with a value coincidentally equal to the end-code (0x0D for CR), the state machine advances to "end-code matched" and then waits for an inter-character timeout. When no further bytes arrive, the firmware should time out and re-arm the receive-complete logic, but in certain firmware revisions the timer is not re-armed and the state machine remains in "end-code matched, no payload" indefinitely. Asserting the Unit Restart Bit reloads the UART controller but not, in some lots, the receive state machine.

4.2 Buffer Descriptor Corruption Under Electrical Noise

The CJ-series SCU21 shares the backplane ground with the CPU and I/O. In installations where the scanner cable runs in the same tray as VFD output cables or servo power cables, common-mode noise can be coupled into the RS-232C receive line at amplitudes well below the threshold that would set a framing error. The noise can corrupt a pointer inside the SCU21 receive buffer descriptor without leaving a flag in the status word. The Unit Restart Bit does not always re-initialize the descriptor; only a power-on reset clears it.

4.3 TXDU(256)/RXDU(255) Re-Arm Logic

The TXDU(256)/RXDU(255) ladder instructions re-arm their own receive-complete flag on every successful receive. If the application disables and re-enables the instruction (for example by toggling an input condition) faster than the SCU firmware can service the next receive, the instruction flag and the SCU flag can fall out of sync. This produces a scenario in which the application believes the receive is complete but the buffer is empty, and the restart bit cannot repair the desynchronization.

5. Diagnostic Procedure

Before changing hardware or firmware, perform the following steps to confirm the fault and isolate the root cause. Each step has a single binary outcome; proceed only when the previous step passes.

1. Capture the SCU status word. Using CX-Programmer in online mode, place the allocated CIO words for unit #3 (CIO 1575 to CIO 1599, where 1575 = 1500 + 25 x 3) into the Watch Window. Record the Port 1 and Port 2 Receive Complete Flags, Overrun Error Flags, Framing Error Flags, and Receive Counter values.
2. Confirm no error bits are set. The fault signature requires all four error flags clear. If any flag is set, the root cause is a different issue (wiring, baud rate, end-code mismatch) and the restart-bit mitigation will not apply.
3. Trigger the restart bit under controlled timing. Use a normally-open contact driving A623.02 with a 200 ms ON time followed by a 1 second OFF guard, and observe whether the Receive Complete Flag re-arms within 500 ms. If it does, the restart bit is functioning and the lockup is intermittent; proceed to step 5. If it does not, proceed to step 4.
4. Cycle power to the SCU only. Disconnect the 5 VDC supply to the SCU21 by removing it from the backplane for 10 seconds. Re-insert, and observe whether the receive logic recovers. If it does, the fault is firmware-state only and requires a watchdog mitigation (see Section 6). If it does not, the fault is wiring, scanner, or CPU Bus Unit assignment.
5. Capture a logic-analyzer trace. Probe the SCU21 TXD, RXD, RTS, and CTS lines at the DB-9 back-shell using a high-impedance active differential probe. Look for noise pulses > +/- 3 V on RXD, particularly between trigger-out and scanner-response, that do not set a framing error. A pulse train of > 5 ms with amplitudes in the +/- 5 V to +/- 12 V range is characteristic of common-mode noise coupling.
6. Verify scanner output levels. Disconnect the scanner and substitute a known-good bench source (for example, a Hyperterminal PC or a Keysight 34461A in serial stimulus mode) driving the same 8-byte payload plus CR at 9600 / 8-N-1. If the SCU21 receives reliably for 24 hours against the bench source but fails against the scanner, the scanner or its cable is the noise source.
7. Check the end-code configuration. Confirm that the DM setup area word for end-code-1 of port 2 is set to 0x0D0D (CR-CR or a single CR depending on whether CR is also the start code). Many SCU21 lockup cases are caused by end-code configured as 0x0A0A (LF) when the scanner emits CR, leaving the state machine one byte behind permanently.

6. Resolution Methods

Once the fault is confirmed as a restart-bit-insensitive lockup, the following resolutions have been proven in production. Apply them in order of effort; the first two are usually sufficient.

6.1 Periodic Receive State Refresh (No Hardware Change)

The simplest mitigation is to issue a Port Settings Change (which re-loads the UART from the DM setup area) on a low-priority timed interval. The Port Settings Change Bit does not re-initialize the entire module firmware, but it does re-arm the UART controller and clears the receive-complete latch in the firmware revisions where the Unit Restart Bit alone is insufficient.

; --- Ladder logic for periodic port refresh on unit 3, port 2 ---
; Trigger every 30 minutes using a 0.1 s clock and a 18000-count counter
LD     P_1s                       ; 1-second clock from CPU
AND    <CNT_done>                 ; Counter reset on power-up
CNT    001 #18000                  ; 18000 seconds = 5 hours (adjust to site)
LD     CNT001                     ; Counter complete bit
OUT    A623.02                    ; Assert Unit Restart Bit for 200 ms
TIM    002 #20                    ; 200 ms hold timer
LD     TIM002
OUT    A623.02_reset_signal       ; De-assert via reset rung

6.2 Software Watchdog on Receive Staleness

A second mitigation is to detect the lockup in the application by counting the time since the last successful receive. If the interval exceeds a watchdog threshold, the application asserts the Port Settings Change Bit to re-arm the port without requiring a power cycle.

; --- Watchdog: trigger Port Settings Change if no data in 60 s ---
LD     ALWAYS_ON
TIM    003 #6000                  ; 600.0 s timeout
LD     RXDU_complete              ; Cleared on every RXDU(255) success
RSET   TIM003
LD     TIM003                     ; Timeout flag
AND    NOT A623.02                 ; Edge-trigger only
SET    A623.02                    ; Latch the Port Settings Change Bit
TIM    004 #2                     ; 20 ms minimum pulse per W494 spec
LD     TIM004
RSET   A623.02                    ; Release the bit

6.3 Hardware Power-Cycle Watchdog (Last Resort)

If neither of the above resolves the lockup, the only certain recovery is a power cycle of the SCU module. An external DC UPS relay or a solid-state relay driven from a free CPU output can be used to drop 5 VDC to the SCU21 for 5 seconds under program control. The relay should be wired in series with the SCU21's +5 V backplane feed via an auxiliary 5 VDC tap; cycling the relay performs a true firmware cold start.

6.4 Firmware and Lot Audit

Lot numbers below CJ1W-SCU21-V1 09J4 (manufactured 2009, week 4) have a documented incidence of receive-state-machine latch. The lot number is laser-etched on the side of the module. If the lot is older than 09J4, request a replacement under RMA from Omron. The -V1 designation and the lot number are visible in the module's CPU Bus Unit I/O Table in CX-Programmer (right-click the SCU21 and select "Unit Information").

7. Migrating from TXDU/RXDU to CX-Protocol / Protocol Macro

Protocol Macro is a sequence-based communication method built into the SCU21 firmware. It runs as an embedded interpreter that executes a "protocol" - a series of steps, each containing a send message, a receive message with end-code and timeout, and a next-step transition. Because the protocol macro interpreter re-arms the receive state machine between every step, it is immune to the lockup that affects raw TXDU(256)/RXDU(255) ladder usage.

CX-Protocol is the configuration tool, included in CX-One (CX-Programmer version 9.x or later). The protocol for the Microscan Mini can be built in three steps:

1. Create the project. In CX-Protocol, select the CJ1W-SCU21-V1 unit, port 2, and "Protocol Macro" as the protocol type. Create a new protocol called "MICROSCAN_MINI".
2. Define the trigger send. Add a Send Message step (SEND_01) with the 4-byte trigger string the Microscan expects (typically 0x16 0x54 0x0D or as documented in the Microscan Mini user manual). Set "Send Method" to "Send Only" and "With CR" to enabled.
3. Define the receive step. Add a Receive Message step (RECV_01) with the end-code set to CR (0x0D), the receive length set to 8 data bytes, and a "Next Process" branch to a SUCCESS step and a TIMEOUT step. The TIMEOUT step re-issues SEND_01 after a 200 ms wait, which gives Protocol Macro the same watchdog behavior described in Section 6.2 without any ladder code.

The Protocol Macro execution is driven by the PMCR(260) instruction from the ladder. PMCR(260) takes the unit number, the protocol number, and the source/destination data area as operands, and the SCU21 handles all send/receive/timing internally.

; --- Ladder: invoke Protocol Macro on unit 3, port 2 ---
LD     Trigger_Condition       ; Application condition to read code
PMCR   3                       ; Unit number 3 (SCU21 #3)
       001                     ; Protocol number 1 (MICROSCAN_MINI)
       DM0100                  ; Source: 100 words of send data
       DM0200                  ; Destination: 100 words of receive data
       0                       ; Control word 0 (no special flags)
ANDNOT PMCR_completion         ; PMCR is a single-shot instruction
OUT    Read_Code_Done          ; Latch until next trigger

Once the protocol macro is loaded into the SCU21's flash memory (CX-Protocol > Transfer To Unit), the unit will execute the trigger/receive sequence on every PMCR(260) pulse without any further ladder work. The receive state machine is reset between every Protocol Macro cycle, so the lockup cannot reoccur.

8. Flow Control and Wiring Verification

Even when migrating to Protocol Macro, the RS-232C wiring and flow control must be correct. The SCU21 supports four flow-control modes selected in the DM setup area: none (default), Xon/Xoff (software), RTS/CTS (hardware), and DSR/DTR (DTE-side).

Verify the following in the DM setup area for unit #3, port 2:

• Flow control mode = 0 (none) when the Microscan Mini is configured for 3-wire operation (RD, SD, SG only).
• Flow control mode = 2 (RTS/CTS) when the scanner is configured for full hardware handshaking; in this case pins 7 and 8 must be cross-wired straight-through (7-7, 8-8) and the loop-back jumper between ER and CS at the SCU21 end (factory default) must be in place.
• RS-232C driver enable = 1 (always enabled) for port 2; this is the factory default.
• 5 VDC output on DB-9 pin 9 (used to power some scanners) is disabled for the Microscan Mini, which has its own 5 VDC supply.

Shielded cable (Belden 8723 or equivalent) with the shield grounded at the SCU21 end only is recommended. The shield should not be grounded at the scanner end, to avoid ground-loop noise that would otherwise be coupled into the RD line. See W336 CS/CJ Serial Communications Boards Operation Manual section 4-2 for the recommended cable construction.

9. Verification Procedure

After applying any of the resolutions in Section 6, perform the following verification to confirm the lockup is no longer reproducible.

1. Run the scanner in continuous-read mode for a minimum of 72 hours. Log the CIO 1575 (Port 2 Receive Counter) value to the SD memory card every minute.
2. Confirm that the counter increments at the expected rate (one count per 10 seconds for the reported configuration, or 8,640 counts per 24 hours).
3. If using the software watchdog, confirm that the watchdog has not asserted more than once in 24 hours. An assertion rate of more than once per hour indicates the root cause is still present and Section 6.3 should be applied.
4. If using Protocol Macro, confirm that the PMCR(260) completion flag returns within the expected timeout for every cycle, with no PMCR error flag asserted.
5. Verify that no power cycle of the CPU rack has been required for the duration of the test.
6. Verify that the Unit Restart Bit has not been asserted manually or by the watchdog during the test window.

10. Field-Commissioning Checklist

Use this checklist at every new installation of a CJ1W-SCU21-V1 with a 1D/2D scanner:

• Verify the SCU21 lot number is 09J4 or later; replace if earlier.
• Use shielded cable with the shield grounded at the SCU21 end only.
• Confirm end-code is configured for CR (0x0D) and not LF (0x0A).
• Disable the 5 VDC output on DB-9 pin 9 unless the scanner requires it.
• Configure flow control to match the scanner's handshaking; verify the cross-over of RTS-CTS and DTR-DSR.
• Use Protocol Macro rather than TXDU(256)/RXDU(255) for any scanner that responds to a polled trigger.
• Implement a software watchdog that asserts the Port Settings Change Bit on a receive-staleness timeout.
• Record the baseline CIO receive counter at start-up and compare to the expected rate after 24 hours.
• Save the CX-Protocol project and the SCU21 setup area (DM 30300-30399 for unit #3) to the project archive for future recovery.
• Document the SCU21 lot number and firmware version in the project README.

11. Frequently Asked Questions