SKW EnergyOS
EC fans6 min read

How fast does an EC fan follow a setpoint? A step test, second by second

Fifteen minutes of deliberate setpoint changes on a live EC fan — 1,316 to 1,199, 1,000, 799, 599, 299 and back — sampled roughly every second. What the rotor did, how long it took, and what that means for control loops.

Most of the day this fan sits at one speed. For fifteen minutes on 22 October we stepped its setpoint up and down while logging every second or so, to see how a 2 kW EC fan actually responds to a command.

24 hours of actual rpm and setpoint rpm from one EC fan, steady at about 1,315 rpm overnight with a step test at the end
The whole day. Steady at ~1,315 rpm through the night; the shaded band is the step test.
Fifteen-minute step test: setpoint rpm toggled between 1,316 and lower values while actual rpm follows with a lag
15:42–15:57 IST. Dashed: setpoint. Solid: what the rotor did. Each dot is a sample.

What happened

The setpoint was switched from 1,316 to a lower value and back roughly every forty seconds — first 1,199, then 1,000, 799, 599 and finally 299 — with each low setpoint held for one to forty seconds. The fan never reached the lower setpoints in the short holds: with 1,199 commanded, it had dropped to about 1,040 before the command returned to 1,316; with 799 commanded it got to 1,023, then 908, as the holds lengthened. When the setpoint sat at 299 for a single second the rotor was still at 1,260 — a 2 kW impeller has real inertia.

The clearest number: at 15:55:02 the command dropped from 1,316 to 599; at 15:55:20 the fan read 639 rpm. About 680 rpm of deceleration in 18 seconds — roughly 40 rpm per second coasting down with the drive's own ramp limit, since an EC drive typically does not brake hard. Acceleration back up was comparable: from 910 rpm at 15:56:02 to 1,313 at 15:56:47, about 45 seconds for 400 rpm, so roughly 10 rpm/s on the way up — the drive ramps gently to limit inrush current.

Why it matters for control

  • A fan is not a valve. Commands take tens of seconds to land. A controller that writes a new rpm every few seconds and expects the fan to be there is fighting its own actuator.
  • Ramp rates are asymmetric. Coast-down was ~4× faster than ramp-up on this drive. A static-pressure loop should expect a slower response when it asks for more air than when it asks for less.
  • Hold the command. Our own loop writes a setpoint and waits for the measured state to settle before judging the result — the ≤10 s live-state validation is about the sensor, but the fan itself needs longer.
  • Faulted and the bus: none of the step changes triggered a fault, even the 1,316 → 299 step. The drive's ramp limit protected the bus. The three faults of the day came from the mains, not the commands.

A note on sampling

Overnight the logger sampled every five minutes, which is fine for a fan that doesn't move. During the test it sampled every second or so, which is what you need to see the ramp. Log at the rate of the thing you want to see.