A feedback servo loop only acts once an error appears; the axis has to fall behind its target before the loop pushes it to catch up. That means an axis moving at speed always lags its command by a small amount called following error. Velocity feedforward is a way to shrink that lag dramatically. Instead of waiting for the error, the controller predicts the speed the axis needs and injects it directly, so the loop starts from almost the right answer. This guide explains how velocity and acceleration feedforward work, why they cut following error without raising loop gain, and how motion feedforward differs from the feedforward used in process control.
Velocity Feedforward in one line: Velocity feedforward is a servo tuning term that injects the commanded velocity of a move directly into the loop's output, ahead of the feedback correction, so the axis is already being driven at the right speed instead of relying on error to build up that drive. Because it supplies most of the needed command in advance, it sharply reduces following error during constant-speed motion without raising the loop gains, and acceleration feedforward extends the same idea to the accelerating and decelerating parts of a move.
A plain position loop works entirely by feedback: it measures how far the axis is from where it should be and produces a speed command proportional to that gap. This has an unavoidable consequence during a move. To make the axis travel at a steady speed, the loop needs a steady speed command, and the only way a proportional position loop can produce that steady command is to maintain a steady position error to generate it. So a moving axis necessarily runs behind its commanded position by an amount that grows with speed, and that persistent lag is the following error.
Velocity feedforward breaks that dependence. The controller already knows the commanded velocity at every instant, because it generated the motion profile, so rather than making the feedback loop manufacture the speed command out of error, it simply adds the known commanded velocity straight to the loop's output. Now the axis is being driven at close to the right speed from the outset, and the feedback loop only has to correct the small remaining difference. The large position error that used to be needed just to keep the axis moving disappears, and following error during constant-speed motion drops toward zero.
The elegant part is that this improvement costs nothing in stability. Following error could also be reduced by cranking up the position loop gain, but higher gain brings noise, resonance, and the risk of instability. Feedforward reduces the error by supplying the command from knowledge of the trajectory rather than by amplifying the feedback, so it does not touch the loop's stability margins. The feedback loop keeps its comfortable, well-tuned gains while the feedforward path carries the bulk of the command.
Velocity feedforward handles the constant-speed portions of a move, but a move also has phases where the axis is speeding up and slowing down, and during those phases the axis needs extra torque to accelerate its inertia. Acceleration feedforward addresses this by injecting a command proportional to the commanded acceleration, supplying the torque the mass needs to change speed before the feedback loop has to react to the lag. With both velocity and acceleration feedforward active, following error is attacked throughout the whole move, not just its steady middle, and the axis tracks the entire trajectory closely.
Feedforward is only as good as the numbers behind it. Velocity feedforward is usually applied as a gain that scales the commanded velocity into the loop's units, and set correctly it can be close to one hundred percent, meaning the full commanded speed is fed forward. Acceleration feedforward depends on knowing the system's inertia, since the torque needed to accelerate depends on how much mass is being moved. If the feedforward is set too low, some following error remains; if it is set too high, the axis can lead its command and overshoot. Tuning it well means finding the values that drive following error to near zero without introducing lead or overshoot.
Because feedforward relies on the commanded trajectory being smooth and differentiable, it pairs naturally with well-shaped motion profiles. A jerky command with sudden changes in acceleration produces sudden feedforward demands that the mechanics may not follow cleanly, whereas a smooth profile gives smooth feedforward and clean tracking. This is one reason feedforward, smooth trajectory generation, and jerk limiting are usually configured together, each supporting the others so the axis follows its intended path with minimal error and minimal disturbance.
The word feedforward also appears in process control, and although the underlying philosophy is the same, the two uses are quite distinct. In process control, feedforward means measuring a known disturbance, such as a change in feed rate or inlet temperature, and adjusting the controller output in anticipation before that disturbance affects the controlled variable. It is about pre-empting an external upset the controller can see coming. Motion feedforward, by contrast, is about pre-empting the loop's own inherent lag by injecting the commanded velocity and acceleration of the planned move.
The distinction is worth holding onto because the signals involved are different in kind. Process feedforward is driven by a measured external disturbance and is added to the feedback of a slow, continuous process loop to reject that disturbance. Motion feedforward is driven by the internally generated motion command itself and is added to a fast positioning loop to reduce tracking error against a known, planned trajectory. One anticipates the outside world, the other anticipates the machine's own commanded path, and mixing up the two leads to confusion about what a feedforward term is actually compensating for.
In both worlds, the benefit of feedforward is tighter tracking, and both are visible to an operations team through cloud SCADA in the form of the errors that remain. For a positioning machine, following error and settling performance can be reported to a platform such as Merobix, and a rising following error on a duty that used to track cleanly is a useful health signal that a mechanism is loading up or drifting out of tune. For a process loop, the residual deviation despite feedforward is likewise something a monitoring system can trend. In each case the supervisory layer does not compute the feedforward itself, but it gives a team a way to watch, across many remote assets, whether the machines and loops are still tracking their commands as well as they should.
No, and that is its main advantage. Velocity feedforward adds the known commanded velocity to the loop output rather than amplifying the feedback error, so it reduces following error without changing the feedback loop's gains or its stability margins. Raising the position loop gain would also cut following error but at the cost of noise, resonance, and reduced stability, whereas feedforward achieves the reduction from knowledge of the trajectory instead.
Velocity feedforward injects the commanded speed, reducing following error during the constant-speed part of a move. Acceleration feedforward injects a command proportional to commanded acceleration, supplying the extra torque needed to accelerate the load's inertia during the speeding-up and slowing-down phases. Used together they reduce tracking error across the whole move rather than just its steady middle, and acceleration feedforward requires a reasonable estimate of system inertia to set correctly.
Yes. If the feedforward gain is set too high, the feedforward path drives the axis harder than the trajectory actually requires, so the axis can lead its command and overshoot at the ends of moves instead of lagging. The goal is to set it so following error drops to near zero during the move without the axis leading its target, which usually means a velocity feedforward close to but not exceeding the level that fully accounts for the commanded speed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.