The common misunderstanding
A collaborative-rated arm holding a sharp deburring tool, or a hot part, or moving a two-kilogram casting at speed, is not a collaborative application. ISO/TS 15066 governs the application; the arm merely makes certain application types achievable. We have seen more than one plant install collaborative robots behind fences because the risk assessment, done properly and late, required them.
Four collaborative modes, only two of which are common
- Safety-rated monitored stop. The robot stops when a person enters the shared space. Simple, robust, and it costs whatever the interruption rate costs in throughput.
- Speed and separation monitoring. The robot slows as a person approaches and stops if they come within a calculated protective separation distance. This is the most commonly deployed mode and it requires accurate stop-distance calculation, not a datasheet figure.
- Hand guiding. Useful for teaching and for heavy-part positioning assistance. Rarely the basis of a production cycle.
- Power and force limiting. Contact is permitted within measured biomechanical limits. This is the mode people mean when they say cobot, and it is also the one that requires physical force and pressure measurement to validate — a measurement, not a calculation.
The framework we actually use
Four questions, in this order:
- Does a person need to be in the working envelope during the cycle? If not, fence it. A fenced industrial arm is faster, cheaper per unit of throughput, and the safety case is simpler.
- Is the end effector or workpiece inherently hazardous? Sharp, hot, energised or heavy defeats power-and-force limiting regardless of the arm.
- What does the cycle time budget tolerate? Collaborative speeds are substantially below industrial speeds. If the takt has no slack, the answer is a fence.
- What floor space exists? This is often the deciding factor. Where a fence and its access door will not fit, collaborative operation is the only route to automation at all — and accepting the cycle time penalty is a rational trade.
What people underestimate
Two things, consistently. First, the validation effort: power-and-force-limited applications require instrumented measurement against biomechanical limits for every contact scenario, documented and retained. That is real engineering time that rarely appears in the initial budget.
Second, the throughput cost. A collaborative cell that stops every time an operator reaches past it can lose a great deal of its nominal capacity to interruption. Layout — where the operator stands, where material arrives, which direction the arm reaches — matters more to realised throughput than the robot's rated speed.
A reasonable default
If floor space allows a fence and no person needs to be inside during the cycle, fence it and buy the faster arm. Use collaborative operation where shared space is genuinely required by the process or forced by the building, and budget properly for the validation it obliges you to do.
Talk to us about this
If this is relevant to a line you are working on, our engineers are happy to look at the specifics. Related capability: Robotics Integration. You can also browse delivered projects, the technology stack or contact the engineering team.