Tuning pump and fan speed loops

Read the drive first

Acceleration and deceleration ramps limit how fast the drive will follow a speed command. If those ramps are longer than the process dynamics, the drive is the dominant lag and the controller is tuning around it.

Minimum speed matters too. A loop whose demand falls below the configured minimum saturates against it and winds up, exactly like an output limit. A loop that only hunts at low throughput is often bouncing off this.

Both are frequently left at commissioning defaults. Both should be deliberate choices the control engineer knows about.

Where the real dynamics come from

Once the drive is out of the way, a speed loop is usually fast and well-behaved. The remaining dynamics come from load inertia, which sets how quickly the motor can actually change speed, and from the process the pump or fan is feeding.

Speed feedback derived from pulse counting is quantised, and at low speed that quantisation looks like noise. It is another reason derivative action rarely belongs on this loop type.

Questions that come up

Should I control flow directly or cascade onto speed?

Both are used. Direct flow control with the drive as the final element is simpler and common. A flow-onto-speed cascade is worth it when the drive or the motor has its own dynamics worth isolating, or when speed itself is constrained and you want the limit handled in one place.

Related