How Do I Select a SCARA Cobot Without Hidden Risk?

A robot purchase starts with the command path: the engineering workstation creates the job, the robot controller interprets it, drives move the axes, feedback closes the motion loop, and the safety chain decides whether motion is permitted. Follow that path before comparing purchase prices. A low-cost arm has little production value if one undocumented interface, unavailable spare, or unverified safety function stops commissioning.

Where does the command path start and stop?

Define every interface needed by the machine before requesting a quotation. The required path may include an engineering computer, robot controller, machine PLC, safety system, end-effector controller, and production network. Similar-looking robots can have entirely different controller architectures, licensing rules, and integration limits.

Do not infer shared electronics, software, or support from enclosure shape or branding. A claim that one robot is a rebranded version of another requires matching controller hardware, software, documentation, service parts, and contractual support. Check: complete a witnessed backup, restore, and offline production run before evaluating motion performance.

Does the mechanical package fit the real duty?

Layer one first. Confirm mounting, payload, tooling mass, center of gravity, reach, cable routing, utilities, and environmental limits from controlled documentation. Payload alone does not define suitability; an offset tool creates joint torque that a centered payload does not.

One used Precise Automation/Brooks candidate was described as carrying 5 kg, moving at 2000 mm/s, limiting manual mode to 250 mm/s, and weighing 75 lb. A Hitbot comparison claimed approximately 9 lb. These values describe different mechanical packages, not equivalent capability. The 250 mm/s manual-mode value also does not prove human-presence detection or collaborative operation.

1. Obtain the load diagram rather than relying on the headline payload.
2. Add the gripper, adapter, workpiece, hoses, and cables to the moving load.
3. Plot every required point, including approach, retreat, service, and fault-recovery positions.
4. Run the full path at intended acceleration and payload while recording tracking errors, vibration, joint limits, and controller warnings.
5. Repeat after thermal stabilization and after removing and reinstalling the tool.

Check: the robot completes every production and recovery position with the real tool and payload, without entering a prohibited configuration or producing a controller warning.

Can the controller execute and recover the application?

A demonstration cycle proves motion, not maintainability. Commission a representative task containing normal sequencing, interlocks, rejected-part handling, restart logic, and loss-of-communication behavior. Simple pick-and-place may require little programming, but production recovery exposes undocumented state machines and incomplete diagnostic access.

Documentation quality becomes a production constraint when parameter meanings, program syntax, or recovery states are unclear. Translation quality matters less than whether the manual defines each state and action precisely. Check: have a technician who did not build the test recover one induced communication fault using only the delivered documentation.

Does the claimed collaborative function control the hazard?

“Cobot,” manual speed, and safe operation are separate claims. Human detection, safety-rated speed limiting, safety-rated position limiting, protective stop behavior, and safe torque removal solve different parts of the hazard chain. A conventional SCARA can be integrated into a guarded cell; a collaborative label does not remove the need to assess the complete application, tool, workpiece, fixtures, and foreseeable contact.

Epson SafeSense on the GXB series was described with software-configured speed and operating limits in the RC700E controller, optional safety hardware cards, and safety-rated I/O. The description also notes that a separate safety PLC or controller may still be required in larger systems. Those features illustrate the questions to ask; they do not establish equivalent behavior in another robot.

1. List each hazardous motion and energy source, including sharp tools, dropped parts, trapping points, and stored pneumatic energy.
2. Map every safeguard to the controller input, safety output, drive action, and required restart behavior.
3. Request safety documentation that identifies the implemented functions and validation method.
4. Test each gate, stop device, mode selection, communications loss, power interruption, and reset sequence.
5. Measure the resulting stop performance under the worst intended payload and speed, then use that measured result in the cell layout.

Where a claimed function cannot be validated, design the cell around independent hardwired safeguards and physical separation. Check: record a witnessed test for every safety input, output, stop response, reset condition, and operating mode.

Can the supplier support the installed life cycle?

Purchase price is only one branch of life-cycle cost. Reported Hitbot offers included a $3000 SCARA cobot, a cancelled $500 order, a video advertising $120 domestically, and a proposed $4000 replacement model. Such variation makes the written quotation, exact supplied configuration, cancellation terms, and payment protection more important than an advertised headline.

A Precise Automation/Brooks robot was reported at 140,000 hours MTBF, while current robots from that supplier were described in the $25,000-$35,000 range. Treat MTBF as a population-level reliability claim, not a promise that one unit will run that long. Ask for its calculation basis, covered components, operating conditions, repair definition, and spare-part lead times.

Check: place the bill of materials, software rights, spares, warranty, training, acceptance criteria, and remedies in the purchase order before payment.

How do you prove the cell is ready for production?

Finish with an acceptance test that follows the complete path from production request to verified motion and safe completion. Use the intended PLC or host, network, tool, payload, operator actions, and fault recovery—not a supplier demonstration program.

1. Restore the approved controller and robot projects from the delivered backups.
2. Confirm addressing, ports, I/O mapping, operating mode, payload data, tool data, and motion limits against the signed configuration record.
3. Run the complete automatic cycle at the agreed production settings and record cycle results, controller warnings, and rejected-part handling.
4. Interrupt each communication and utility connection individually; verify the machine reaches its defined state and reports a usable diagnostic.
5. Trip each safeguard and verify motion response, reset restrictions, and restart sequencing.
6. Power down the complete cell, restart it, and confirm that no undocumented account, service connection, parameter entry, or supplier action is required.
7. Have maintenance restore a backup, replace a defined service item, diagnose an induced fault, and return the cell to automatic operation from the supplied documentation.

Final verification: issue one production request from the real host, trace it through every communication and safety hop, complete the loaded robot cycle, confirm the expected result at the host, and archive the matching controller logs and configuration backup.

FAQ