Soft-Start & Soft-Release Profiles

When I plan brake soft-start and soft-release, I am really shaping the coil current over time. A hard 24 V step slams the brake mechanically: the armature hits the friction surface with a sharp click, the harmonic drive sees a sudden torque step and the whole axis feels rough. A shaped current profile lets me trade a few extra milliseconds of response time for lower noise, less shock and better lifetime.

On the mechanical side, a hard brake engagement injects a torque impulse through the output flange into the harmonic drive. If the joint is near a hard stop or carrying a large offset load, that impulse shows up as backlash take-up and micro-bounce. Over time it eats into the gearbox compliance margin. On the release side, an abrupt loss of holding torque can let the axis fall into gravity or spring forces before the servo has fully taken over, especially on vertical and safety-critical axes.

On the electrical side, a hard step to the rated pull-in voltage maximizes inrush current. With several joints sharing the same 24 V supply, that inrush can cause a short sag on the bus. If the sag crosses the undervoltage threshold of PLCs, drives or sensors, I end up with nuisance resets right when I need the system to be predictable. So I design the I(t) profiles with both mechanical and electrical limits in mind.

I usually consider three implementation options for shaping the current profile:

• Firmware-controlled PWM ramp: the MCU drives a high-side switch with PWM and ramps the duty cycle from zero up to a pull-in level, then down to a hold level. This gives me maximum control: I can tune ramp time, overshoot and hold current based on real current measurements and ambient conditions.
• Driver IC with built-in soft-start profile: some smart high-side switches and dedicated brake drivers implement an internal slew or current-limit ramp. I trade flexibility for simplicity: the hardware guarantees a controlled rise and fall time without loading my safety-rated firmware.
• Simple RC or delay circuits: on low-cost joints I can accept an analog compromise. Slowing down a MOSFET gate with an RC network or delaying brake release relative to servo enable gives a softer feel without a full control loop, at the cost of tolerance and temperature sensitivity.

The first design decision is how much time budget I really have for pull-in. Safety functions and functional requirements set upper bounds on the maximum brake release time. Within that window, I choose a ramp slope that is long enough to reduce shock and inrush, but still short enough that motion can start when expected. A typical compromise is a fast ramp up to a little above the minimum pull-in current, followed by a short verification step and then reduction to the hold current.

The second decision is the long-term hold current. From the brake data sheet and thermal tests I estimate the maximum safe coil power across ambient and duty cycle. That defines an upper bound for Ihold. At the same time, the mechanical holding torque and safety margin define a minimum Ihold. I make sure my soft-release profile ends in a current that sits comfortably between these limits, rather than blindly trusting the nominal rating.

Finally, I think about what happens when power is lost or an emergency stop is triggered. In a fail-safe design the brake must engage reliably on supply loss, which means my soft-release logic should not depend on perfect firmware behavior at the edge of a brownout. I keep the release and hold profiles simple enough that they can be reasoned about in a safety analysis, and I define how the servo torque, brake current and STO signals interact during both normal stops and emergency stops.

Position Sensing Around the Harmonic Drive

Around a harmonic-drive joint, I treat position sensing as its own design topic. The motor-side encoder is usually there already for FOC and servo control, but it does not tell me the full story at the output flange. Backlash, elasticity and couplings introduce a gap between what the motor sees and where the load really is, especially under changing torque.

For basic cost-driven joints, I accept this limitation and run with a motor encoder only, plus a simple home switch to establish a reference. For higher-precision or safety-relevant joints, I add an output-side absolute encoder at the flange. The pair of encoders lets me observe both the motor angle and the load angle, which is critical when I care about compliance, collision detection or safety zones in the workspace.

In addition to encoders, I nearly always reserve space for a home sensor and at least one over-travel limit. A dedicated home sensor makes commissioning and recovery faster: I can re-align encoder counts to a known mechanical reference without relying on absolute measurements alone. Over-travel limits protect cables, end-stops and the harmonic drive itself against software or parameter mistakes.

The key decision is when to invest in both motor-side and load-side feedback. I consider a second encoder when the backlash or compliance of the joint is high enough that the difference between motor angle and load angle starts to matter for my process quality or safety case. I also consider it when the joint is part of a force-controlled or collaborative application, where a small angular error at the flange can translate into a significant positional error at the tool tip.

Brake behaviour is also tied to sensing. Before releasing the brake, I need enough feedback to know that the joint is within a safe position and speed window. After issuing a release command, I watch the encoder and limit signals to confirm that the brake actually let go and that motion starts in the expected direction. When engaging the brake, I check that the joint is already within the intended hold window so that the brake does not have to catch a fast moving axis on its own.

On the electrical side, I keep the protocol and AFE details in their own topics. If I need to compare EnDat, BiSS or TTL / Sin-Cos encoder interfaces, I go to my Absolute Encoder Interface page. Resolver-to-digital converters and Hall-based feedback trade-offs live in my Motor Feedback AFE page. Here I stay focused on where I place sensors around the harmonic drive and how I use their signals to coordinate brake, motion and safety logic.

De-Mag Protection & Energy Dissipation

When I switch the brake coil off, I am really deciding where the stored magnetic energy will go and how quickly it will disappear. A brake coil is an inductive load, so its current does not stop just because I turn the MOSFET off. If I do not provide a controlled discharge path, the coil will drive the node voltage up until something conducts: the MOSFET body diode, an ESD structure, or a parasitic path across the 24 V bus and nearby I/O.

With a simple flyback diode across the coil, the current freewheels at roughly one diode drop above ground. This is gentle on the switch and on the supply, because the voltage never rises far above the nominal rail. The price I pay is time: the current decays slowly, so the brake releases later. On axes where the release time is not critical and where I value robustness and low cost, a plain diode is still a valid choice.

When I need a faster release, I look at clamping the voltage higher. Adding a TVS in combination with a diode lets the coil current fall at a higher voltage. The TVS defines the maximum voltage, the diode steers the current into a tight local loop, and the energy is burned in a known place instead of in random parasitics. Release time decreases, but the TVS has to survive the ½·L·I² energy per actuation and the full lifetime duty cycle.

On higher-end joints I consider active clamps or driver ICs with a defined VDS clamp. Instead of letting the voltage peak wherever the layout and MOSFET allow, the driver holds it around a design value, for example two to three times the supply. That gives the coil a faster de-magnetisation without pushing the switch or insulation right up to their absolute limits. The result is a predictable brake release time in the tens of milliseconds, which I can plug directly into my timing and safety analysis.

To choose between these options, I start from the mechanical and safety requirements. If the joint can live with a slow brake release and my main concern is protecting the electronics, I often stay with a single diode. If I have a hard limit on maximum release time, I work backwards from that time, the coil inductance and operating current and select a clamp strategy that lets I(t) decay inside that window. At the same time I check that the resulting voltage and dissipation are still compatible with my MOSFET ratings, creepage and EMC budget.

In multi-axis systems I also think about what happens when several brakes de-mag within a short time. Even if each coil has a perfect clamp, their combined discharge currents and voltage steps can disturb the shared 24 V rail and sensitive references. I stagger brake release and engage events, keep the de-mag loop local to the coil and driver, and give noisy return currents a short, well-defined path back to the bulk capacitors instead of across logic ground and measurement lines.

Diagnostics, Safety Hooks & Self-Test

Once the brake driver and de-mag network are in place, I still have to assume that something will eventually go wrong: a coil will age, a connector will loosen, a MOSFET will fail or a brake will start to drag. Diagnostics and safety hooks are how I stop those faults from silently eroding my safety margin. I plan what I can detect electrically at the driver, what I can infer from encoder and torque behaviour and which signals I feed into the safety MCU or PLC.

At the electrical level I expect the brake driver to detect open-load and short-circuit faults on the coil. With a current or voltage window it can tell the difference between a coil that draws no current when commanded on, and a coil or wiring that is shorted to ground or to the 24 V rail. Ideally the driver exposes this as a fault pin or a status bit, not as a silent derating. I route that fault indication both into my non-safety diagnostics and, where required, into the safety domain.

Mechanically, I treat the brake as stuck if the joint does not behave as expected after a command. When I issue a release command, I expect to see the motor or load encoder respond within a defined time and torque window. If the motor current rises and the axis barely moves, the brake may be dragging or not releasing at all. When I command the brake to engage, I expect that a moderate external torque cannot move the axis by more than a small, specified angle. In both cases I use encoder data and torque estimates from the drive to flag a brake performance issue.

Thermal behaviour is another diagnostic channel. I usually place an NTC near the brake housing or rely on a temperature sensor in the driver IC. From that signal I define a derating threshold where I reduce hold current or limit duty cycle, and a higher threshold where I treat the brake as overheated and raise an alarm. Having explicit thresholds and a clear reaction is more useful than a vague “high temperature” flag.

On the safety side I define clear hooks between brake control and the STO or emergency-stop function. In a normal stop, the drive can first ramp torque to zero, then engage the brake and finally apply STO, all within generous timing budgets. In a safety stop, the sequence is tighter: STO must act quickly to remove torque, and the brake must engage within a bounded delay so that the axis does not drift. I expose separate command, status and fault signals so the safety MCU or PLC can enforce its own sequence and cross-checks.

I also plan for periodic brake self-tests. Under controlled conditions—low speed, small load and no people in the workspace—I can briefly release and re-engage the brake while observing encoder motion and torque. If the brake no longer releases cleanly or can no longer hold its specified torque, the test reveals it before a safety function depends on it. In the specification I capture these expectations as concrete requirements, for example that the brake driver must provide open-load and short-circuit diagnostics and a feedback pin that reports the brake status to the safety controller.

IC & Module Selection Checklist

By the time I reach IC selection for the harmonic-drive brake, I already know how I want the coil to behave electrically and mechanically. This checklist is where I translate those behavioural requirements into concrete IC families and parameter dimensions. I group the devices into three buckets: smart high-side or low-side switches with diagnostics, dedicated brake-control drivers with current and timing profiles, and small auxiliary AFEs for temperature, current and isolation.

For smart high-side and low-side switches that can drive the brake coil directly, I look at them as generic 24 V load switches with a specific current and diagnostic profile. The key dimensions for this class are:

• Operating voltage range: the minimum and maximum supply voltage, including how much headroom there is for 24 V industrial rails with dips and surges.
• Current limit and maximum current: the continuous current per channel and any current-limit value in short-circuit conditions, so I know whether the part can handle pull-in current and survive fault cases.
• On-resistance (RDS(on)): the conduction loss in the switch at hold current, which sets how much heat I have to dissipate in the IC versus the coil.
• Protection types: which protections are implemented and how: over-current, over-voltage, under-voltage, over-temperature and whether short-to-battery, short-to-GND and open-load conditions are distinguished.
• Number of output channels: how many independent loads I can serve from one package, and whether that matches the number of brakes or other 24 V loads on my joint module.
• Control and diagnostic interface: simple enable and fault pins versus a full SPI interface with per-channel configuration and status bits.

Dedicated brake-control drivers form the second bucket. These are parts that are aware of pull-in and hold current, or that provide built-in soft-start and soft-release profiles. Here my checklist digs deeper into behaviour:

• Supply and clamp voltages: supported supply range and any internal VDS clamp level for de-mag, so I can tie release time and peak voltage back to the coil inductance and current.
• Configurable pull-in and hold current: minimum, maximum and resolution of Ipull-in and Ihold, and whether they can be configured independently per channel.
• Soft-start and soft-release behaviour: how the device shapes I(t) during engagement and release, whether ramp times are fixed or programmable and how they interact with protection thresholds.
• De-mag strategy: whether the device uses a diode-like freewheel, a defined clamp voltage or an active energy-dissipation scheme, and how that maps onto my target release time.
• Protection and diagnostics detail: how many fault types are reported separately (open-load, short-to-GND, short-to-battery, over-temperature) and whether they are exposed as dedicated pins or only via a serial interface.
• Channel count and independence: the number of brake channels per IC and whether each channel can have its own current and timing profile, which matters for multi-axis robots.
• Interface and safety fit: SPI, I²C or parallel pins, and whether the signalling lends itself to being monitored by a safety MCU or PLC on the appropriate side of any isolation barrier.

The third bucket holds small auxiliary AFEs that turn physical quantities into signals my controller can use. These include an NTC interface or temperature AFE near the brake, a current-sense stage for the coil and, when the safety architecture requires it, digital isolators between brake control and the rest of the system. For these elements, my checklist covers:

• NTC AFE: supported resistance range, linearisation behaviour, output format (simple voltage, ADC-integrated, or digital) and bandwidth, so I know whether it can capture the thermal behaviour I care about.
• Current sense: measurement range and accuracy at brake pull-in and hold currents, common-mode voltage range compatible with my high-side or low-side topology, and whether I only need a window comparator or a real measurement channel.
• Isolation (if used): isolation voltage rating, CMTI and channel configuration for any digital isolator carrying brake command, status or fault signals between domains.

With these three buckets and their parameter dimensions defined, I can build a brand mapping table: each row is one candidate IC or module and each column is one of these checklist items. That makes it much easier to compare options across vendors and to keep the brake-control design consistent across different robot platforms and joint variants.

BOM & Procurement Notes

To turn the brake and driver concept into something I can actually buy and assemble, I translate the design into explicit BOM fields. These fields describe the brake coil, the driver topology and the protection and timing behaviour in a way that purchasing and suppliers can understand. When I send an RFQ or ask for alternatives, I point suppliers to these fields instead of vague phrases like “24 V brake driver”.

I usually organise the BOM information for the brake function into four groups: the coil itself, the driver and topology, protection and diagnostics, and timing and safety. A compact way to capture this is a table like the one below, with each row as a field name that becomes a column in my BOM or sourcing spreadsheet:

When I contact suppliers, I do not just send these fields as a table; I also ask a few direct questions to understand how well their parts fit a multi-axis robot brake use case. Typical RFQ questions I keep in my template are:

• Release time and clamp behaviour: “For this brake coil and my 24 V system, what release time and clamp voltage can your driver guarantee across temperature and lifetime, and how do you recommend sizing the de-mag network?”
• Diagnostic resolution and safety interface: “How does the device distinguish between open-load, short-to-GND and short-to-battery faults, and how are these reported to my safety MCU or PLC?”
• Multi-axis and lifetime behaviour: “Do you have application notes or test data for multi-axis robots where several brake coils share the same 24 V bus, including thermal behaviour of the clamp and EMC performance over lifetime?”

By keeping the BOM fields and RFQ questions aligned with the technical work I did in the earlier sections, I make it much easier to compare vendor options, document design intent and avoid surprises late in the project when the actual brake hardware shows up on the bench.

FAQs: Harmonic-Drive Brake Planning & Selection

When I plan harmonic-drive brakes for robot joints, I keep coming back to the same practical questions about drivers, waveforms, de-mag, diagnostics, safety hooks and BOM fields. This FAQ is my personal checklist: each answer is short enough to reuse in reviews and RFQs, but concrete enough to guide real design and sourcing decisions.