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:
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:
Conditions required to declare a motor available to stop automatically might include:
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.