For a few years now, the motion control conversation in this industry has been about standardization — PLCopen’s motion function blocks giving controls engineers a common vocabulary across Beckhoff, Siemens, Rockwell, and B&R platforms so an MC_MoveAbsolute call means roughly the same thing regardless of vendor. That fight is mostly won. Adoption is broad enough that it’s now an expectation, not a differentiator. The friction has moved one layer down, into safety-rated motion: safe torque off (STO), safely-limited speed (SLS), safe direction (SDI), safely-limited position (SLP), and the family of function blocks PLCopen has been extending to cover them consistently across platforms.
This matters more in 2026 than it did two years ago because cobot deployments have stopped being pilot-cell curiosities. They’re getting bolted into lines alongside servo-driven material handling, sharing safety zones with fenced robots, and increasingly running on Safety over EtherCAT (FSoE) or PROFIsafe networks that also carry standard motion traffic. The integration question isn’t “can we make this move safely” anymore — vendors solved that years ago at the drive level. The question is: where does the safety logic that decides when to invoke STO or SLS actually live, and how do you keep from writing the same safety function three times across three different pieces of hardware.
Three places safety logic can live — and why that choice isn’t cosmetic
In most mixed cells today, you have three legitimate homes for safe-motion logic, and the decision about which one owns it drives everything downstream.
The dedicated safety PLC
A safety-rated controller — running a TÜV-certified safety application separate from the standard control task — evaluates inputs from light curtains, e-stops, and area scanners, and issues safety commands to drives over FSoE or PROFIsafe. This is the traditional architecture, and it’s still the right default when a cell has multiple safety zones, multiple robot types, or safety interlocks that span more than one machine. The safety PLC becomes the single source of truth for the whole cell’s safety state, which auditors and integrators both like, because there’s one place to look during a functional safety audit.
Integrated safety motion function blocks in the motion controller
This is what’s new and worth paying attention to. Beckhoff’s TwinSAFE Motion, Siemens’ Safety Integrated within TIA Portal, and Rockwell’s integrated safety on CompactLogix/GuardLogix with Kinetix drives now let you configure SLS, SDI, and SOS (safe operating stop) as function blocks that live inside the same engineering environment as your standard motion code, executing on safety-rated logic that’s tightly coupled to the drive. The appeal is obvious: no duplicated logic, no separate safety PLC to maintain, and safety limits that are parameterized right next to the axis configuration they protect. The tradeoff is that you’re now depending on a single vendor’s safety ecosystem end to end, and if your cell has a cobot from a different manufacturer sharing the same zone, you still need a bridge between that cobot’s native safety system and your PLC’s safety logic.
The cobot’s native safety system
Cobots from the major collaborative robot manufacturers ship with their own safety-rated monitoring — force/torque sensing at the joints, configurable safety zones, and built-in speed and separation monitoring that satisfies ISO/TS 15066’s power-and-force-limiting provisions without any external safety controller at all. For a standalone cobot cell, this is often sufficient and genuinely simpler. The problem shows up when that cobot has to coordinate with a servo-driven conveyor or a second robot in the same fenced or unfenced space — now you have two independent safety authorities that both think they’re in charge, and neither one natively knows what the other is doing.
The decision framework, in practice
Use the cobot’s native safety system when it’s genuinely a standalone cell with no shared motion from other equipment in the collaborative workspace. Use integrated safety motion function blocks when the cell is single-vendor top to bottom and the servo axes and any cobot involved all speak the same safety network natively. Fall back to a dedicated safety PLC as the arbitration layer the moment you mix vendors, mix safety protocols, or need one safety state to gate multiple pieces of equipment. The mistake integrators keep making is trying to make the cobot’s native safety system talk directly to a servo drive’s STO input through hard-wired relays, layering a slow, unauditable patchwork on top of otherwise well-documented safety logic. If you need cross-vendor coordination, put a certified safety PLC in the loop as the single decision-maker, even if it feels like overhead for a “simple” cell.
Where mixed-vendor cells actually break
The most common integration pitfall isn’t the function block configuration itself — PLCopen’s standardization has made the parameterization of SLS thresholds and SDI zones reasonably consistent across platforms. It’s the boundary conditions. A Beckhoff TwinSAFE Logic controller and a Siemens F-CPU can both be configured correctly in isolation and still produce a safety gap when a cobot’s safety-rated I/O crosses into the servo network’s safety domain through a gateway or protocol converter that isn’t itself safety-rated. Any conversion between FSoE and PROFIsafe, or between either of those and a cobot’s proprietary safety bus, needs to happen through a certified safety relay or safety controller with its own SIL/PL rating — never through a plain I/O mapping in the standard, non-safety part of the program. This is where auditors most often find gaps, and it’s where a system integrator’s paperwork trail matters as much as the wiring.
The other recurring issue is response time budgeting. Every safety function has a required response time baked into its risk assessment, and that time gets consumed by real, addable latencies: sensor debounce, safety network cycle time, safety logic scan time, drive-side STO reaction time, and mechanical stopping distance. Stack a cobot’s native monitoring, a safety PLC, and a servo drive’s own safety module in series, and the cumulative latency can quietly exceed what your ISO/TS 15066 power-and-force-limiting calculation assumed for separation distance — especially if the SLS threshold was set assuming a faster deceleration profile than the axis can actually deliver under load.
A validation checklist before you ever run a live pinch test
- Confirm which single system is the authoritative safety decision-maker for the zone, and document it — don’t leave it implicit.
- Verify every protocol boundary crossing (FSoE to PROFIsafe, cobot-native to either) passes through certified safety hardware, not standard I/O mapping.
- Measure actual safety function response time end to end — sensor to STO engagement — using the real hardware, not the datasheet worst case for each component in isolation.
- Recalculate ISO/TS 15066 separation distances using measured response time and measured (not rated) deceleration, since worn mechanics and load variation both extend stopping distance.
- Confirm SLS and SDI thresholds are set against the actual payload and speed profile used in production, not the default values left over from commissioning.
- Re-validate whenever any component in the safety chain changes firmware, since safety function timing can shift between revisions even when the configuration file doesn’t.
- Run the risk assessment under ISO 10218-2 as a live document tied to the as-built system, not the original cell layout drawing.
PLCopen’s push to standardize safety motion function blocks is a real improvement — it means an SLS configuration in one vendor’s engineering tool now maps conceptually to the same thing in another, which makes cross-training engineers and auditing safety logic genuinely easier than it was. But standardized function blocks don’t standardize architecture decisions. Somebody still has to decide who’s in charge of the safety state in a mixed cell, and that decision, not the function block library, is what determines whether your cobot deployment scales cleanly or turns into a stack of safety patches nobody fully trusts.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
