Mitsubishi FX1S USB-SC09 Cable Setup and Batch Ladder Programming

Mitsubishi FX1S USB-SC09 Cable Setup and Batch Ladder Programming

Engineer field notes covering two interlocking tasks that converge on the same workstation: establishing reliable programming communication between a USB-only laptop and a Mitsubishi FX1S-30MR-ES/UL base unit through a CH340-based SC-09 clone, and structuring a sequential batch program that drives three independent flight bars through a PCB etching emulation without ever doubling up a physical output coil. Both tasks are core competencies for an automation technician entering the field and both respond to documented methodology rather than trial-and-error.

1. Overview: Two Problems, One Training Rig

Symptom one: a USB-to-RS422 cable advertised as "SC-09 compatible" refuses to handshake with GX Developer against an FX1S base unit. The workstation runs Windows 7 64-bit, the cable is listed in Device Manager as "USB-SERIAL CH340", and GX Developer's Connection Test returns "Cannot communicate with PLC". Symptom two: a PCB etching training machine requires a program that drives three flight bars through ten sequential phases each, with dwell values stored as tunable constants rather than hard-coded timer presets, and a single physical actuator must be shared between three bars without conflict.

The two problems share a root cause in that both require disciplined use of internal relays, data registers, and subroutine partitioning. Solving them in order — cable first, then program — keeps the bench usable throughout the training cycle and lets the same PLC be re-tasked between students without re-wiring.

2. Prerequisites

For structured self-study, Mitsubishi Electric maintains a dedicated training portal covering the MELSEC family, including the FX series: Mitsubishi Electric PLC Training. Allen-Bradley and RSLogix fundamentals are covered by Rockwell Automation's workforce development catalogue at Workforce Development & Industrial Training Services. Free introductory modules for ladder fundamentals, scan time, and I/O concepts are available through AutomationDirect PLC Training.

3. PCB Etching Flight Bar Process Specification

The training machine emulates a small PCB plating or etching line. Three flight bars carry workpieces between stations. Each flight bar performs the same ten-phase cycle but offset in time so that three bars are always in motion, never idle. The motor outputs (pick, X-traverse, Y-traverse, lift) are exposed to the PLC as single points; the program must therefore arbitrate the demand from three independent state machines into one physical actuator at a time.

Each bar spends 50 s in a full cycle. With three bars, the steady-state hand-off interval between releases is therefore 50 / 3 ≈ 16.7 s. Because every dwell value is likely to be retuned during commissioning (the printed solution uses them as pluggable constants), the values must be stored in a data register file rather than burned into timer K-values. Operator-tunable dwell is a standard commissioning pattern: it lets the trainer adjust cycle time on the HMI without re-downloading the program and lets students see the effect immediately.

4. Sequential Process Decomposition with a Time Diagram

Before any ladder is written, draw a "time diagram" — a Gantt-style chart whose x-axis is elapsed seconds and whose y-axis lists each flight bar's current phase. The diagram forces every dwell value, every overlap, and every hand-off to be drawn explicitly so that no implicit timing assumption leaks into the code. A four-minute investment in the diagram saves an afternoon of scan-time debugging.

4.1 Reading the Diagram

Reading vertically at any instant t tells you which bar is in which phase, which outputs are currently demanded, and which timer presets must be active. Reading horizontally for a single bar gives its full phase sequence. The diagram is also the single document from which the register layout is derived — every dwell value visible on the chart becomes one entry in the D-register file.

4.2 Construction Rules

1. Allocate one row per flight bar (Bar 1, Bar 2, Bar 3).
2. Allocate one column-block per phase (10 columns total per the specification above).
3. Write the dwell in seconds at the bottom of each column-block; sum to 50 s per bar.
4. Mark the bar-release instant at the right edge; mark the next bar's pick instant 16.7 s later.
5. Highlight any instant at which two bars demand the same physical output. Resolve the conflict by inserting a hand-off offset or by inserting a token-passing queue as described in Section 5.
6. Confirm that no bar requests the same output within the arbitration window; if it does, redesign the dwell distribution before writing ladder.

5. Internal Relay Architecture for Multi-Resource Coordination

The single-output-per-actuator constraint is solved by inserting an intermediate layer of latched "bar-active" bits between the phase sequencer and the physical outputs. On the FX1S these are M-coils (auxiliary relays); on the SLC 500 they are integer bits in file B3. The sequencer writes only to M-coils; a separate arbitration ladder translates those M-coils into output requests.

Each bar's phase sequencer sets exactly one M1xx bit at a time. A second ladder file ("LAD 2" in RSLogix 500, subroutine 1 in GX Developer) performs priority arbitration: a token-passing ring that hands pick-output ownership from Bar 1 → Bar 2 → Bar 3 → Bar 1 as each bar finishes its pick phase. Only the bar holding the token is permitted to drive M200. The same pattern applies to X-traverse, Y-traverse, and lift, with independent token rings so that a bar can be at the X-traverse phase while another bar is at the lift phase.

5.1 Token-Passing Sequence (illustrative ladder for pick-motor ownership)

// FX1S, GX Developer — Subroutine SBR 1: Pick-motor arbitration
//
// Row 1: Token grant to Bar 1 if Bar 1 is requesting and nobody owns yet
LD   X012              // Bar 1 at pick station (sensor)
OR   M210              // Bar 1 already owns
ANI  M211              // Bar 2 does NOT own
ANI  M212              // Bar 3 does NOT own
ANI  M213              // Bar 1 pick-phase not yet complete
OUT  M210              // Bar 1 owns pick motor

// Row 2: Bar 2 takes token when Bar 1 finished pick
LD   M213              // Bar 1 pick complete (phase-1 done bit)
AND  X013              // Bar 2 at pick station
ANI  M211
ANI  M212
OUT  M211

// Row 3: Bar 3 takes token when Bar 2 finished pick
LD   M214              // Bar 2 pick complete
AND  X014              // Bar 3 at pick station
ANI  M210
ANI  M212
OUT  M212

The principle generalises to every shared physical actuator: each shared output sits behind a one-of-N decoder driven by the phase sequencers. A downstream fault (e.g., Bar 2 home-proximity sensor stuck) cannot energise the same motor from two rungs because only one M21x bit is ever set at a time.

5.2 State Machine per Flight Bar

6. Timer Preset Storage in Data Registers

Hard-coding the dwell values into T0 K5, T1 K10, etc., is brittle: changing a dwell requires a full download and forces the operator to wade through the program to find the right timer. The cleaner pattern stores every dwell in a contiguous data-register block and uses MOV (FX) / MOV (SLC) to copy the value into the timer's preset at the moment the timer is armed.

6.1 Loading the Timer Preset at Phase Entry

// FX1S: on entering Tank 1 dwell phase for Bar 1 (M102 ON)
LD    M102              // Bar 1 phase = Tank 1 dwell
MOV   D102  T0          // Copy dwell value (5 s) into T0 preset

// SLC 500 equivalent
LD    B3:0/2            // Bar 1 phase = Tank 1 dwell
MOV   N7:2  T4:0.PRE    // Copy dwell into Timer 4 preset

Because the preset is fetched from the data file at the moment the timer is armed, an operator can change any dwell by writing a new value into the HMI or by editing the data table online — no program edit, no full download, no scan interruption.

6.2 Why Not NEQ on the Running Timer?

Comparing the running timer to its target with NEQ is technically possible but functionally wasteful: there is no need to compare when the timer's done bit (T0 in FX, T4:0/DN in SLC) already provides the same information with zero scan-time overhead. NEQ also creates a race window between the comparison and the timer's auto-reset. Reserve NEQ for diagnostic display paths that must run continuously without disturbing the scan.

7. Program Skeleton: 10-Subroutine Layout

The "10 ladder diagrams" referenced in the training material correspond to one logical subroutine per major function, not to ten repetitions of the same logic. The recommended decomposition is:

1. LAD 1 / SBR 0 — First scan, reset, fault clear. Use M8002 (FX) or S2:1/15 (SLC) to detect first-scan and clear all M1xx phase flags and M21x token bits.
2. LAD 2 / SBR 1 — Token-passing arbitration for every shared actuator (pick, X-traverse, Y-traverse, lift).
3. LAD 3 / SBR 2 — Bar 1 phase sequencer: reads current-phase M1xx, advances on timer-done or sensor input, sets next-phase M1xx, resets current.
4. LAD 4 / SBR 3 — Bar 2 phase sequencer.
5. LAD 5 / SBR 4 — Bar 3 phase sequencer.
6. LAD 6 / SBR 5 — Dwell-preset loading block. One rung per phase transition copies D10x into T0-T9.
7. LAD 7 / SBR 6 — HMI data exchange (data table → operator panel, e.g., D100 displayed as "Tank 1 dwell = 5 s").
8. LAD 8 / SBR 7 — Fault handling (E-stop, home-prox lost, motor overload, bar-stuck timer).
9. LAD 9 / SBR 8 — Manual / jog mode (training aid; isolated from auto-run by an M-coil guard).
10. LAD 10 / SBR 9 — Handshake to upstream pick-station and downstream unload; sets the "release complete" flag that frees a token slot.

Each sequencer is responsible for advancing exactly one bar. It reads its current-phase M-coil, performs the per-phase action (energise a request line, MOV a preset, start a timer), waits for the timer's done bit, and sets the next-phase M-coil while resetting the current-phase M-coil. Sequencing therefore collapses into a chain of SET / RST pairs and the program reads like a state diagram rather than a tangle of interlocks.

8. Mitsubishi FX1S USB-SC09 Communication Troubleshooting

Symptom: GX Developer reports "Cannot communicate with PLC" or "no connection" when Transfer Setup → Connection Test is run, with the SC-09 USB cable plugged into the FX1S programming port and the workstation running Windows 7 (64-bit). Device Manager lists "USB-SERIAL CH340" under Ports (COM & LPT), confirming that the cable is electrically enumerated. The fault is therefore in the driver stack, the GX Developer setup, or the PLC programming port — not in basic USB enumeration.

The cable is electrically a USB-to-RS422 adapter built around a WCH CH340 (or CH341) chip. The original Mitsubishi SC-09 is a passive cable with a built-in RS232-to-RS422 level shifter powered from the PLC port; USB clones integrate both conversions into one dongle. Both end-points present a virtual COM port to Windows, which GX Developer treats identically.

8.1 Decision Tree

GX Developer "Cannot communicate with PLC"
        |
        |-- Device Manager shows "USB-SERIAL CH340" with COMx? -- No --> Driver not installed. Install CH340 driver (Section 9).
        |                                                          Yes
        |
        |-- Cable seated at both ends, PLC powered? -- No --> Power PLC; reseat cable at both ends.
        |                                          Yes
        |
        |-- Transfer Setup COM port matches Device Manager COMx? -- No --> Fix COM port.
        |                                                          Yes
        |
        |-- Transfer Setup parameters 9600 / 7E1? -- No --> Fix parameters.
        |                                            Yes
        |
        |-- Loopback test on cable passes? -- No --> Cable defective; replace.
        |                                  Yes
        |
        --> PLC programming port hardware fault or firmware lock.
            Replace FX1S base unit or contact a Mitsubishi FA distributor.

8.2 Fault Symptom Matrix

9. CH340 Driver Installation and Verification

Windows 7 does not ship a native CH340 driver. The bundled mini-CD supplied with cheap cable clones typically contains an unsigned or 32-bit-only driver that fails to install on a 64-bit Windows 7 build, leaving the device listed under Device Manager with a yellow warning triangle. Windows 10 1709 and later auto-install a working CH340 driver without intervention.

9.1 Driver Identification Procedure

1. Identify the chip revision. Open Device Manager → right-click the unknown "USB-SERIAL" device → Properties → Details → Hardware Ids. Look for USB\VID_1A86&PID_7523 (CH340) or USB\VID_1A86&PID_5523 (CH341). The driver file in use, ch341s64.sys, is the 64-bit WCH driver that covers both revisions.
2. Download the current signed driver directly from the chip vendor (WCH). Avoid the CD-ROM bundled with the cable if Windows refuses the signature.
3. Extract the ZIP to a known folder. Right-click the unknown device → Update Driver Software → "Browse my computer for driver software" → "Let me pick from a list of device drivers on my computer" → "Have Disk…" → point to the driver .inf.
4. Reboot if prompted. Re-open Device Manager and confirm "USB-SERIAL CH340" appears without warning under Ports (COM & LPT), and note the COMx number assigned.
5. Record the COM number; GX Developer must be pointed at the same COM.

9.2 Driver Verification Checklist

10. GX Developer Transfer Setup and Serial Parameters

The FX1S programming port uses a fixed protocol: 9600 baud, 7 data bits, even parity, 1 stop bit (7E1). GX Developer must be configured to match exactly. The FX1S does not auto-baud — any deviation produces "Cannot communicate with PLC" with TX activity but no RX reply.

10.1 GX Developer Menu Path

1. Open the project. From the menu bar, select Online → Transfer Setup.
2. In the PC side I/F list, double-click "Serial" (or "USB" if using a Mitsubishi-validated USB driver; the CH340 clone must use the Serial entry with the virtual COMx).
3. Set the COM port to the Device Manager COMx.
4. Click "Connection Test". A successful test returns "Successfully connected to FX1S". A failure returns "Cannot communicate with PLC" with the connection log showing TX but no RX.
5. Click "OK" to close the dialog. The PC side I/F is now bound to the COMx; subsequent Online menu operations (Read from PLC, Write to PLC, Monitor) reuse the same channel.

11. Hardware Verification and Loopback Test

Before suspecting a cable fault, confirm three things in order: the PLC is alive, the cable is alive, and the driver is alive. The order matters because PLC port hardware is more expensive to replace than a cable, and a cable is more likely than the integrated RS-422 transceiver on the base unit.

11.1 PLC Alive Check

1. Power the FX1S with the correct mains voltage. The "POWER" LED on the base unit must illuminate solid green; the "RUN" LED must be either solid green (program executing) or flashing (program stopped / no program loaded).
2. If neither LED illuminates, check the supply and the fuse. FX1S AC variants use a non-resettable internal fuse on the mains input; the 24 VDC variants are self-protecting but will latch on reverse polarity.
3. If POWER is on but RUN is dark and ERR is lit solid, the CPU has detected a fatal error (watchdog, syntax error in program, memory corruption). Clear the error by powering down, holding the RUN/STOP switch to STOP for 5 s, powering back up, and downloading a known-good program.

11.2 Cable Loopback Test

A loopback test verifies the cable's TX and RX paths independently of the PLC. It is the fastest way to isolate a cable fault.

1. Disconnect the cable from the PLC, leaving the USB end in the workstation.
2. Open PuTTY (or any terminal emulator) on the workstation, set it to the same COMx at 9600 7E1.
3. Short pins 2 and 6 on the FX1S end of the cable with a jumper wire. On the SC-09 8-pin mini-DIN, pin 2 is SD (send data, PLC → PC) and pin 6 is RD (receive data, PC → PLC).
4. Type any character in the terminal. If the same character echoes back, the cable's RX and TX paths are intact. No echo indicates a broken shield, a bad CH340, or a wrong pinout clone.

11.3 Driver Alive Check

1. Confirm Device Manager shows "USB-SERIAL CH340" with no warning.
2. Open PuTTY on the same COMx at 9600 7E1 and type characters; if PuTTY accepts the port and characters reach the terminal, the driver stack is healthy.

If all three checks pass and GX Developer still reports "Cannot communicate with PLC", the fault is on the FX1S programming port or in the GX Developer protocol parameters. The PLC programming port is a non-isolated RS-422 transceiver; an over-voltage event on the I/O terminals (especially the 240 VAC outputs of an MR base unit) can destroy the port without affecting the scan engine. Replace the base unit or contact a Mitsubishi FA distributor for an RMA.

12. RSLogix 500 / MicroLogix 1000 Cross-Reference

The same PCB etching rig can be replicated on an Allen-Bradley MicroLogix 1000 (catalog 1761-L20BWA) with RSLogix 500 v7.x. The cross-platform exercise is valuable because it forces the same program-design questions to be answered in two different instruction sets, exposing the underlying methodology rather than the syntax of any one vendor.

The SLC 500 Reference Manual (publication 1747-RM001) contains worked application examples in its appendix covering sequencing, dwell storage, and one-of-N selection — directly applicable to the flight-bar rig. The MicroLogix 1000 instruction set is a strict subset of SLC 500, so the same examples translate without modification. This makes the MicroLogix 1000 the ideal parallel rig for a technician learning both platforms: same ladder mechanics, different instruction mnemonics, identical program-design methodology.

13. Edge Cases and Failure Modes

14. Putting It Together: Commissioning Checklist

1. Install CH340 driver from WCH, reboot, confirm COMx assignment.
2. Connect SC-09 cable to FX1S programming port, power PLC, confirm POWER and RUN LEDs.
3. Open GX Developer, set Transfer Setup to COMx at 9600 7E1, run Connection Test.
4. Download the flight-bar program (LAD 1-10 / SBR 0-9). Place PLC in STOP before download.
5. Set the PLC to RUN. Verify the operator panel echoes the dwell values from D100-D109.
6. Trigger a manual pick request. Verify M200 (pick request) energises and only one bar's M21x ownership bit sets.
7. Cycle one bar through all ten phases; confirm the timers tick from the D-register presets rather than from hard-coded K-values.
8. Cycle all three bars simultaneously; confirm no double-energisation of any physical output by monitoring the relevant output LEDs on the base unit.
9. Tune dwell values from the operator panel; confirm timers re-load with new presets without re-downloading the program.
10. Test E-stop: assert mid-cycle, confirm all bars halt and all phase flags reset, confirm first-scan restore on release.
11. Document any deviations and back up the project to two physical media stored in separate locations.

15. Frequently Asked Questions