Home / Insights / STO and Functional Safety in DC Servo Drives: What It Does and Does Not Cover

Technical note

STO and Functional Safety in DC Servo Drives: What It Does and Does Not Cover

STO on these 48 V DC servo drives is available on the EtherCAT R-suffix models only, with two inputs and one output, and it is worth being precise about what it does and what it does not do. This note covers the hardware behaviour, the parts of a safety argument that a torque-off function cannot carry on its own, how the two-channel input should be used in a real machine, and what I would check before signing off an STO chain.

What STO does inside the drive

STO, safe torque off, does one thing at the drive: it removes the torque the drive can produce. On these drives the implementation is described as cutting motor current and disabling output torque, triggered through safety inputs rather than through the motion control path. The practical effect is that the motor stops producing torque and the drive enters a state where it cannot be driven by the normal command path until the safety chain is released. It is a hardware-level intervention: the function is available whether or not the motion bus is connected, and the transition does not depend on the fieldbus being healthy. That last property is the reason STO exists as a separate function rather than as a software command — a stop command sent over the bus can be delayed, lost, or overtaken by the same fault that made you want to stop in the first place.

What STO does not do

Here is where I would push back on most datasheet language, including my own. STO is not a certified safety function by itself. A drive with STO does not carry a performance level or a safety integrity rating until the whole chain — the sensor, the safety logic, the wiring, the feedback and the risk assessment — has been designed and validated for the machine. A drive that stops producing torque does not stop a load that is being pushed by gravity, and it does not bring a machine to a controlled stop; it removes the drive's contribution to the motion. If the hazard in your machine comes from stored energy, from a hanging axis, from a part that can be ejected, or from a second actuator, none of those are addressed by STO. And the force-control functions on these drives — contact force typically around 10 grams, with roughly ±1 gram variation — are a separate matter from the safety function. Do not let a force specification and a safety specification share a column in your evaluation sheet.

Availability by model

The practical constraint that catches people out is not what STO does, it is which models have it. On the D, DS, UF and DG families, STO is present on the R-suffix EtherCAT models only, and the CANopen, Modbus-RTU and pulse/direction variants do not support it. That is a selection decision that has to be made at quotation stage, not discovered at commissioning stage.

Why the EtherCAT versions, and only those

The restriction is structural rather than mysterious: STO is wired to the model's safety input interface, and the R-suffix models are the ones built with that interface populated. If your architecture is EtherCAT-based, you have the option. If it is a Modbus or pulse/direction machine, the safety function has to live elsewhere in your design, and that changes the conversation at the quotation stage rather than at the commissioning stage. The G series core modules and multi-axis units do not carry STO, so an embedded or multi-axis design needs a different safety strategy, and it is worth saying so early rather than discovering it when the risk assessment is finished.

Building a safe stop around it

Building a safe stop around STO is standard engineering work and it is yours to do: STO gives you a hardware torque-off function with two inputs and one output for feedback on the D, DS and UF models, and the DR ring model supports STO cascading so several drives can be chained into one safety chain. Around that you need a proper architecture under the framework your market expects — ISO 13849-1 or IEC 62061 for the machine's safety functions, with a documented risk assessment determining the required performance level and the diagnostic coverage. Practical elements usually include a monitored emergency stop device with dual-channel contacts, a safety relay or safety controller that decides the STO request, feedback of the STO output back into that controller, and a mechanical brake sized and wired for the hazard where one is needed. The two-channel STO input arrangement exists precisely so that a single wire break cannot silently defeat the function, so use both channels and monitor them.

Commissioning checklist

Before you sign off a machine, I would walk the following, and none of it is optional. Function-test each STO channel individually with the drive enabled, so you know both channels act. Confirm the drive really reaches the torque-off state and that the feedback output changes accordingly. Verify that the machine stops or holds as the risk assessment requires, not merely that the drive stopped driving. Check the restart path: whether the axis has to re-home, whether it is restored automatically, and whether a restart is permitted while a person is inside the guarded space. And test the behaviour when the bus is disconnected or the controller fails, because in that scenario STO may be the only protection left. One caution for machines that use the probe function for contact detection: a force-related function is not a safety function, and it must not be relied on as one.

Where I would push back

Where I would push back on a customer is the request to treat the presence of STO as the safety argument in a supplier comparison. STO is a well-implemented torque-off function and it belongs in the architecture, but it is one element, and on a machine whose hazard is mechanical rather than electrical it may be the least significant element. The more useful comparison is on the mechanical and process side — rigidity, brake behaviour, repeatability of the contact force — because that is where failures actually come from. For model-by-model STO availability, the ordering tables are on the model parameters page, and the safety precautions and wiring documents are in the document library. If you want to send me your machine's risk assessment, I will tell you honestly whether these drives fit the architecture it describes.

Key takeaways

• STO cuts motor current and disables output torque through hardware safety inputs, and it is available on the EtherCAT R-suffix models only — CANopen, Modbus-RTU and pulse/direction variants do not have it.
• STO removes torque; it does not stop a machine, hold a hanging axis, or carry a performance level on its own.
• Use both STO channels, monitor the feedback output, and test the behaviour on bus loss before you sign the machine off.

Common questions

Which of your drives support STO?

The EtherCAT R-suffix models on the D, DS, UF and DG families, and the EtherCAT version of the DR ring unit, which supports STO cascading. The CANopen, Modbus-RTU and pulse/direction variants do not support STO, and neither do the G series core or multi-axis products.

Does having STO make the machine safety-rated?

No. STO is one element of a safety architecture. The performance level of the machine safety function comes from the whole chain — the sensor, the safety logic, the wiring, the feedback and the risk assessment — and it has to be validated for the machine, not inferred from the drive.

Can STO replace a mechanical brake?

Not on its own. STO removes the drive's contribution to the motion, but it does not hold a load that is being pulled by gravity and it does not bring a moving axis to a controlled stop. Where the hazard requires a holding brake, size and wire it as part of the architecture.