How to cycle three or more pumps and fans
Cycling motors on and off could be a way to meet demand; minimize starts, stops, and run time; and equalize run time between motors using a scheme.
Many systems have parallel motors that perform the same function, and should cycle on and off based on demand. Goals for these systems usually include:
- Keep up with demand
- Minimize the number of motors running to keep up with demand
- Minimize the number of starts and stops
- Keep the run time and number of starts roughly equal between all the motors in a group
- Allow operators to prioritize motors
- Fail-over appropriately
- Keep the logic as simple as possible.
What is the best way to accomplish these goals? For two motors, a simple alternating or lead/lag logic will work fine. But things can rapidly get more complicated with three or more.
Conditions required to declare a motor available to start/stop automatically
A fundamental component in the logic for these systems is determining if each motor is available to start automatically ("in program"), if it is available to stop automatically, or neither. There should be "available to auto-start" and "available to auto-stop" bits in your controller for each motor. Conditions required to declare a motor available to start automatically might include:
- Motor is not commanded to run
- In software auto/prog-mode
- Physical hand/off/auto (HOA) switch in auto
- Not out of service or red-tagged
- Not faulted
- Motor overload and overtemp contacts OK
- Start permissives all made
- Run interlocks all made
Conditions required to declare a motor available to stop automatically might include:
- Motor is commanded to run
- In software auto/prog-mode
- Physical HOA switch in auto
There should also be bits for "any motor available to auto-start" and "any motor available to auto-stop."
Accumulate time available
Using the available bits above, each motor should have a "time available to auto-start" and "time available to auto-stop" register. The motor that has been off the longest (while available to auto-start) will have the highest "time available to auto-start." The motor that has been running the longest (while available to auto-stop) will have the highest "time available to auto-stop." These registers are in addition to—and must be separate and independent from—the typical run-time and starts accumulators that every motor should have.
Triggering changes in demand
When logic indicates more demand than the currently running number of motors can handle, this should trigger a one-shot to auto-start another motor, followed by an "auto-restart delay"—a period of time in which no additional motors will be auto-started, but would not prevent manual starts. That time might be 10 seconds or 30 minutes depending on the nature of the system.
When the one-shot "motor start needed" is raised, the system should start the motor with the largest "time available to auto-start." Depending on the kind of programming, this action may also need to include an unlatching of the "motor start needed" bit to prevent multiple available motors from starting on the same trigger event.
Likewise, when demand falls to the point that a "motor stop needed" occurs, the system should stop the motor with the largest "time available to auto-stop", and then wait a period of time before auto-stopping any other motors.
This scheme will minimize starts and stops for each motor, and even out run time while meeting system demand and better controlling the process. For example, many systems have a collection of level float switches in a sump. A high level shuts off all pumps, a low level demands one pump to start, and a low-low level demands two or more pumps to start.
But in the scheme I describe here, the low-low float is not needed for control, although it might be desirable for independent alarming. When the level drops below the low-level float, it starts a pump. If it’s still below the low-level float when the restart time expires, it starts another pump. If multiple pumps are running when it reaches the high level, it will only stop one at a time. So if your demand is at 1½ pumps’ worth of flow, this scheme will keep the level between low and high, always running one or two pumps, and alternating through all available pumps to even out run time.
Now that we’ve covered the basics, let’s discuss some options and other potential optimizations.
What should trigger starts and stops?
If the motors are at constant speed and there is no modulating valve, it’s simple: trigger a motor start when a process variable (PV) goes too far one way, and a stop when it goes too far the other way. This could be generated from floats, other switches, or adjustable settings compared to a measurement from a transmitter. Most systems benefit from a short debounce timer so that the condition must remain for 2 to 10 seconds before it will cause a motor to start or stop.
You may also want high-high and low-low triggers, which would start or stop all available motors; however, I’ve found properly tuned systems (with well-placed trigger points and properly adjusted restart delays) generally do not need those.
Trigger starts and stops from a proportional-integral-derivative (PID) loop
When a system involves a PID loop (controlling motor speed, modulating valves and/or dampers), things get more complicated. The operator should set a single setpoint that the loop will attempt to hold. In this case, using start/stop trigger points based on the PID’s PV is undesirable because that means the PID loop has already lost control—and has been out of control for some time. Instead, trigger starts and stops based on the output of the loop.
For example, you might trigger a start if the output gets to 80% demand to a valve, or 55 Hz demand to motor speeds. Then, configure an auto-stop well above zero—perhaps 20% demand to a valve or 40 Hz to motor speeds. Special care must be taken with motor speeds to make sure the auto-stop output limit is high enough that the pumps are still at a significant flow rate.
Some pumps might not move any liquid at all even at 50 Hz if pumping against significant back-pressure. In such situations, if a flow meter is available, you can trigger auto-pump-stops from multiple causes: either PID loop output low or per-pump flow too low will initiate an auto-stop.
Tip: If you’re having trouble with your loop tuning working well with a certain number of motors running, but then it doesn’t do well with a different number running, use adaptive gain control to make the loop more responsive with fewer motors running, and less responsive with more. See my blog posts on basic loop tuning, advance PID loop methods, and controlling multiple PVs with a single output for more details.
The most important tip for variable speed pumps
Never baseload variable speed pumps. Some systems base-load some equipment, running at a constant rate, and let other parallel equipment swing to meet demand. Variable speed pumps moving liquids should never be handled this way—all pumps supplying liquid to the same header from the same source must run the same speed. If they don’t, one pump might end up spinning but not moving any fluid, and it could burn up in a matter of minutes.
Other variable speed tips
Even if the "never baseload" conditions above are not all applicable (for example, variable-speed fans moving air instead of pumps moving liquid), it’s usually still desirable to configure just one PID loop with a single output (or multiple loops for multiple PVs resulting in a single output), and run all the motors at the same speed.
Variable frequency drives (VFDs) should be configured to appropriately ramp. That way, the output can always be sent to all motor speed references without having to do extra configuration in the controller.
For VFDs for pumps discharging into a high pressure header—typically through a check valve—the VFD should be configured to ramp down, not coast down. "Coast down" means the pump will de-energize immediately when told to stop. If pumping through a check valve into a pressurized header, the back pressure will slam the check valve shut and cause severe water-hammer. With "ramp down," when the VFD is told to stop, it will continue running while it decelerates the motor below the point where any liquid is being pumped (gently closing the check valve), and then stop, thus avoiding or minimizing water hammer. This is not important for variable speed motors moving gasses or liquids into low-pressure headers.
Dual speed fans
Many cooling towers have multiple dual-speed fans. In this case, a fan could be available to auto-start if stopped or running slow, and available to auto-stop if running either fast or slow. If the fan is triggered to "start" when it is running slow, it shifts to run fast instead. If triggered to "stop" when running fast, it switches to run slow. Note that a fan running slow is then available to auto-start and auto-stop at the same time.
In these systems I usually find operators are happy to let the system take care of itself without intervention once they see how it works. However, if motor prioritization is required, it is easily accomplished.
The operator should be allowed to pick a priority for each motor. This might take the form of clicking "lead," "lag," and "lag-lag" buttons, or setting a number. The configuration could perform two levels of selection—first determining which available motors are of the highest priority, then tie-breaking by the time available scheme above. That can get really complicated.
A simpler scheme is to multiply the priority number (internally manipulated so a higher priority is a larger number) by a large constant and add that to the time available. So, a "lead" motor might internally be assigned a priority number of 3, a "lag" 2, and "lag-lag" 1. To the hours available accumulator, you would then add 30000 if the motor is lead, 20000 if lag, or 10000 if lag-lag. The system then just picks the highest number. This insures the highest priority motor will be the one to start, with the time available acting only as a tie-breaker, if a priority tie exists. Do the reverse on stopping: add a larger number for lower priority motors so that the lag-lag motors stop first, then lags, then leads.
This could also work for many more than three motors. If there are 50 motors, you can allow priorities of 1-100 for ultimate flexibility, and this scheme works well.
Many systems of this nature require no special logic to handle failing over. If a motor fails, let it fail, and wait until the demand logic calls for another motor to start one. However, some systems may perform better by immediately starting another motor when one fails. In that case, include a "failed while running" bit from each motor in the start trigger logic. I typically use only the failed-while-running indicator. The Failure-to-start bit could also be used, but that often means the demand condition is still in place and another start will be requested soon anyway, or that the start was requested manually, in which case the operator doing the requesting is best suited to decide what to do about the failure, rather than programmed automation.
Using total run time instead
Sometimes there is a strong desire to keep total run times equal. You can use total run times instead of the available-time scheme described above. However, if a motor is out of service for a while, it will be run exclusively while the other motors stand idle until that motor catches up. This is usually undesirable. That can be avoided either by using the scheme described above, or making it easy for operators to reset all motor run times in the group, so that they can reset them any time a motor comes back into service; then the system will keep total run times even from that point forward.
Multiple motors can be cycled on and off to meet demand; minimize starts, stops, and run time; and equalize run time between motors using a scheme that accumulates time available to auto-start and auto-stop. Systems associated with a PID loop should trigger starts and stops based on the PID output and possibly other PV, not trip points based on the PID’s PV. Operator prioritization can also be implemented, but is probably not necessary.
Chris Hardy is an electrical engineer out of Georgia Tech. At Cross Company Integrated Systems Group since 1994, Chris has process control experience with boilers, alternative energy, water/waste water, chemicals, pharmaceuticals, security, textiles and automotive. Chris also programs controllers/HMIs and writes custom windows applications for communication, data collection, display, trending and reporting.
Cross Company Integrated Systems Group is a CSIA member as of 3/5/2015
-Edited by Anisa Samarxhiu, digital project manager, CFE Media, firstname.lastname@example.org