Fixing Omron ACE 3.8 Cobra 650: PLC Start, Wait, Safe Move

System Overview: Cobra 650 SCARA on ACE 3.8.3.150

The Omron Cobra 650 is a four-axis SCARA robot originally developed by Adept Technology, which Omron acquired in 2015. The platform runs on the eV+ programming language and is configured through the Automation Control Environment (ACE) software. Version 3.8.3.150 is a maintenance release in the ACE 3.8 line that introduced stability improvements for eV+ task execution, I/O mapping, and fieldbus handshakes used in PLC-integrated cells.

A typical Cobra 650 cell consists of:

• Cobra 650 robot with integrated controller (eAIB / eMotion-style amplifier board)
• 24 V digital I/O block for discrete handshakes (start, ready, done, fault)
• External PLC sending start bit, conveyor-ready, and safe-position commands
• Optional eV+ license dongle for conveyor tracking or vision-guided motion
• ACE workstation connected via Ethernet for development, debug, and download only

Once a program is downloaded and the controller is powered, the robot should execute its task list without a permanent ACE connection. The laptop is only required for development, simulation, and online troubleshooting. If the cell cannot run standalone, the issue lies in the program structure, the auto-start configuration, or the I/O handshake, not in the missing PC.

Problem 1: Robot Will Not Move Without ACE Connected

Symptom: PLC asserts the start bit; the robot acknowledges the input but does not execute motion. As soon as the engineer opens ACE 3.8.3.150 on the laptop and connects to the controller, the same start bit triggers the full motion sequence. Disconnecting the laptop returns the robot to a frozen state.

This symptom almost always indicates one of three configuration problems:

1. The robot is in Manual or Teach mode rather than Auto or Remote mode.
2. The auto-start task is not registered with the controller, so the eV+ program never launches on boot.
3. The eV+ program contains a WAIT FOR READY-style statement that depends on a flag the ACE workstation asserts when it is online.

Root Cause: Auto-Start Task and Mode Selection

ACE 3.8 distinguishes between two execution states:

When a program is launched from ACE, the workstation often injects implicit signal enables (e.g., SIG(1001) in eV+) that the controller does not assert on its own at cold start. The PLC then sees the start bit acknowledged, but the robot never moves because the implicit enable is missing. As soon as ACE reconnects, the workstation re-asserts the enable, and motion resumes.

On the Cobra 650 hardware, the front panel typically exposes only power and a high-voltage enable, not a mode selector. Mode selection is therefore software-defined through ACE or through a digital input wired to the controller's I/O block. Cells without a pendant rely on either:

• A hard-wired Auto/Manual input on the digital I/O board, or
• A mode flag set in the eV+ program via SIG() or a serial/TCP command from the PLC.

Solution 1: Configure Auto-Start and Mode Lock

To make the Cobra 650 run standalone after power-up:

1. In ACE, open the project and navigate to Project > Startup (or Project Properties > Startup Task depending on patch level).
2. Assign the top-level eV+ task that contains the pick routine as the Auto-Start Task. The Cobra controller will launch this task immediately after boot, before any external I/O is read.
3. Confirm that the program does not depend on ACE-injected signals. Replace any implicit WAIT FOR READY on workstation flags with an explicit wait on a real digital input assigned to the PLC handshake.
4. Set the controller's mode input to Auto via the hard-wired input or by asserting the corresponding eV+ signal. With no pendant, the default state at boot is whatever the digital input dictates.
5. Cycle controller power. The robot should now run its task list without ACE present. The PLC start bit is now read from physical I/O on every scan.

Verification of the fix: disconnect the Ethernet cable to the ACE workstation and cycle power to the Cobra controller. The robot should boot, load the auto-start task, and respond to the PLC start bit within one I/O scan.

Problem 2: Pick Subroutine Executes Even With No Part Present

Symptom: The pick subroutine is called regardless of the conveyor-ready signal. Simulating "no signal" in ACE does not block the pick; the robot moves to the pick position, attempts a gripper close, and either drops air or faults on a missed part.

This is a classic control-flow issue in eV+ programs that use a flat top-level structure. If the main program simply sequences through pick, move, and place steps without conditional gates, the conveyor-ready signal is never sampled at the right point in the cycle.

Solution 2: Insert If..Then Gates Before the Pick Call

The fix is to wrap the pick call in an IF..THEN block that reads the conveyor-ready digital input. The eV+ pseudocode pattern is:

// Top of cycle loop
IF DIN(conveyor_ready) == ON THEN
   CALL pick_part()
ELSE
   // Wait with a soft timeout so the loop does not stall on a failed part
   WAIT FOR DIN(conveyor_ready) == ON TIMEOUT = 5.0
   IF DIN(conveyor_ready) == ON THEN
      CALL pick_part()
   ELSE
      // Signal upstream that we are starved
      DOUT(part_starved) = ON
      WAIT FOR DIN(conveyor_ready) == ON
      DOUT(part_starved) = OFF
      CALL pick_part()
   END
END

Key points:

• The WAIT FOR statement must reference a real digital input bit, not a simulated value. ACE simulation can fake a signal for testing, but the production I/O mapping is what counts.
• Use a timeout on the wait so a permanently dead conveyor does not freeze the entire cell. The starved output can be wired back to the PLC for a fault or upstream pause.
• Place the IF..THEN at the top of the cycle, not inside pick_part(). This keeps the subroutine reusable and avoids re-entrancy issues if the PLC changes state mid-motion.

Original case resolution: the engineer's program had the pick call at the top level with no conditional. Reorganizing the main loop into IF conveyor_ready THEN pick ELSE wait restored correct sequencing.

Problem 3: Move to Safe Position via Input Signal

Symptom: The PLC needs a way to force the robot into a known safe pose (clear of the conveyor, clear of operators) for E-stop recovery, mode change, or handover. There is no teach pendant, so the operator cannot manually jog the arm.

Two reliable approaches exist in ACE 3.8 for the Cobra 650:

Approach A: Digital Input Bit Triggers a Safe-Move Task

1. Define a digital input, e.g., DIN(2001), as safe_position_request in the I/O mapping.
2. Pre-teach the safe position and record it as a location, e.g., safe_pose.
3. In the main cycle, add a high-priority check before each motion:

IF DIN(safe_position_request) == ON THEN
   DOUT(robot_in_safe) = OFF
   MOVE safe_pose
   DOUT(robot_in_safe) = ON
   WAIT FOR DIN(safe_position_request) == OFF
END

This pattern is interruptible at the next cycle boundary. For true mid-motion interrupt, an eV+ REACT or BREAK against the input may be required; check the eV+ language reference included with ACE 3.8 for the exact reactive syntax supported on the Cobra 650 firmware version installed.

Approach B: PLC Sends a Numeric Code via Fieldbus

If the cell uses EtherNet/IP or PROFINET for the PLC handshake, a register can carry an enumerated command (0 = run, 1 = safe, 2 = home). The eV+ program polls the register at the top of each cycle and dispatches the corresponding motion. This is cleaner than discrete bits when more than two states are needed.

PLC to Robot Signal Handshake Architecture

A robust PLC-robot handshake on the Cobra 650 uses at minimum the following signals. Pin numbers depend on the specific eAIB I/O board revision, so always cross-check against the controller wiring diagram shipped with the unit.

ACE Program Structure for Autonomous Operation

The following eV+ skeleton is a field-proven pattern for a pick-and-place cell that must run without ACE connected. It assumes the Cobra 650 is set up with the standard digital I/O mapping and an auto-start task registered in the ACE project.

PROGRAM main_cycle
   // ----- Initialization -----
   DOUT(robot_in_safe)   = OFF
   DOUT(cycle_complete)  = OFF
   DOUT(robot_fault)     = OFF

   // ----- Home on first entry -----
   IF first_run THEN
      MOVE home_pose
      first_run = FALSE
   END

   // ----- Main loop -----
   DO
      // Mode check (Auto/Manual wired input)
      IF DIN(mode_select) == MANUAL THEN
         WAIT FOR DIN(mode_select) == AUTO
      END

      // Safe-position override takes priority
      IF DIN(safe_position_request) == ON THEN
         MOVE safe_pose
         DOUT(robot_in_safe) = ON
         WAIT FOR DIN(safe_position_request) == OFF
         DOUT(robot_in_safe) = OFF
      END

      // Conveyor-ready gate before pick
      IF DIN(conveyor_ready) == OFF THEN
         DOUT(part_starved) = ON
         WAIT FOR DIN(conveyor_ready) == ON TIMEOUT = 30.0
         DOUT(part_starved) = OFF
      END

      // Execute the pick-and-place
      DOUT(in_cycle) = ON
      CALL pick_part()
      CALL move_to_place()
      CALL place_part()
      DOUT(in_cycle) = OFF
      DOUT(cycle_complete) = ON
      WAIT FOR DIN(start_bit) == OFF
      DOUT(cycle_complete) = OFF
   UNTIL FALSE
END

This structure addresses all three issues raised in the original case:

• No ACE dependency: the program runs on controller boot via the auto-start task.
• Conveyor-ready gating: the pick is only called when the input is true; otherwise the loop starves and signals upstream.
• Safe-position request: an explicit override branch forces the safe pose regardless of cycle state.

Verification and Commissioning Steps

1. Bench test in ACE: With the laptop connected, step the program in ACE's debug mode. Confirm each IF branch behaves as expected with simulated I/O.
2. Live I/O test in ACE: Switch from simulated to real I/O. Force the conveyor-ready input off at the PLC and confirm the robot does not call the pick routine. Force the safe-position input on and confirm the robot moves to the safe pose immediately.
3. Power-cycle test with no PC: Disconnect the laptop, cycle 24 V control power on the controller, and watch the boot sequence. Within a few seconds the robot should home and begin sampling the PLC start bit. Trigger the start bit from the PLC and confirm one full cycle runs to completion.
4. Fault injection: Open the safety circuit (E-stop pushbutton) and confirm the robot stops, drops the ready heartbeat, and latches a fault bit. Reset from the PLC and confirm the next start bit begins a new cycle.
5. Endurance run: Run the cell for at least one full shift (8 h) with real parts. Watch the starved output and fault counters for any intermittent wait-condition misses.

Best Practices and Field Notes

• Never rely on ACE simulation for production behavior. ACE can fake I/O states, and a program that tests clean in simulation can still fail in production if the I/O mapping is wrong. Always validate against physical inputs.
• Keep the auto-start task small and idempotent. A long boot-time task is harder to debug and more likely to race with the PLC's startup sequence.
• Use WAIT FOR ... TIMEOUT on every external wait. A cell that deadlocks on a missing input is worse than a cell that faults on a missing input.
• Wire the mode-select input even if you do not use it today. It is the cheapest insurance against a no-pendant cell booting into the wrong mode.
• Version-control the ACE project. ACE 3.8.3.150 project files (.apj) should be archived with the PLC program and the wiring diagram. Without the project, a controller swap is a full re-commission.
• Teach pendants are optional on this platform. The Cobra 650 family was designed to be deployed in pendant-less cells where the PLC owns the HMI. Do not assume a pendant is required for commissioning; ACE on a laptop is sufficient.
• Document every digital input and output. A 24-line I/O map in the PLC and a matching list in the eV+ program prevents the kind of "If..Then" mistakes that originally caused the issues in this case.

Troubleshooting Matrix

FAQ