Mechatronics
BLDC and Motion Control Firmware
Kyros Engineering develops motor control and motion firmware for BLDC, stepper and servo systems — commutation and current control, HRTIM high-resolution PWM, deadtime tuning, encoder and Hall integration, multi-motor coordination, and the safety interlocks that let a moving machine fail safely.
Scope this with usMotor firmware is where control theory meets a real power stage, and the power stage does not care about the theory. Deadtime that looks fine in simulation causes shoot-through at temperature. A control loop that is stable on the bench oscillates when the load is real.
We work these problems with the motor attached and instrumented — current probe, encoder capture, thermal — because that is the only place the answer lives.
The power stage and the firmware are one system
Splitting the two across vendors is the most common way a motion program stalls. Gate drive, deadtime, current sensing and the control loop have to be designed against each other.
- Deadtime set from measured switching behaviour at temperature, not from a datasheet typical
- Current sense scaling and bandwidth matched to the loop rate that the control actually needs
- HRTIM used where PWM resolution genuinely limits control, and not where it just adds complexity
- Fault response — desaturation, overcurrent, overtemperature — handled in hardware where microseconds matter
- Commutation verified against the encoder rather than assumed from the Hall sequence
Multi-motor coordination
Coordinating several axes on one machine adds a class of problem that single-motor work never surfaces: shared supply sag under simultaneous acceleration, EMI from one drive corrupting another's feedback, and interlock logic that has to be correct in every partial-failure combination, not just the nominal one.
Safety interlocks that hold up
On a machine that moves, the interesting states are the failure states.
- Defined behaviour for encoder loss, phase loss and supply brownout — each decided, each tested
- Watchdog strategy that actually recovers rather than resetting into the same fault
- Safe-state definition agreed with the mechanical and safety owners before firmware is written
- Diagnostics logged so a field failure is reconstructable
When to call
You probably want this if…
Frequently asked
Do you design the drive hardware as well as the firmware?
Yes, and we prefer to when the schedule allows, because gate drive, current sensing and the control loop are one design problem. Where the hardware already exists, we work to it and tell you plainly if something in the power stage is what is limiting the control.
Can you fix a motor design that is audibly rough or running hot?
Usually. Those symptoms narrow the field fast — commutation alignment, deadtime, current loop tuning, or a sensing path with the wrong bandwidth. We instrument the drive and measure rather than tune by ear.
How do you handle functional safety on a moving machine?
We define the safe state with your mechanical and safety owners before writing firmware, then design the failure paths — encoder loss, phase loss, brownout, watchdog recovery — as first-class requirements with test evidence, not as exception handling bolted on at the end.
Motion program stalled between the hardware and the firmware?
We take both sides, which usually means the argument stops and the measurement starts.