Frequency Regulated Pumps
Some time ago I got to work, with a cousin of mine, on a very interesting project. For me, being a software engineer, this was a majestic encounter with the hardware world that had enlightening effects on me. My cousin has a strong background in hardware, so together we had an amazing time learning from each other and building a great system. We’ve built a frequency regulated pump system to deliver constant pressure to its customers with switch-off trigger when no water was needed.
Do you know that feeling when you take a shower and the water constantly oscillates between burning hot and chilling cold. It usually does that in regular cycles of strong jump to hot and slow decay to cold, as depicted in the diagram below.
What is the reason for such a behavior? In most cases it is caused by the on-off regulation of one of the water sources (either cold or hot). So let’s dig deeper in what that means by building a on-off regulated pump system to deliver our hot water.
We start by connecting the pump to the electric motor. We turn on the motor and realize we have huge amounts of hot water pumped at us, completely overshadowing the cold water, burning us completely. OK, so let’s try to fix this problem. We can use the on-off regulation to solve the problem, that is, we can turn the motor on and off to balance the amount of water being pumped. However to avoid burning the motor with high frequency on-off switches we need to add a tank with pressure chamber (balloon of gas inside) to decrease the frequency of the on-off switching. To ensure water not flowing back from the tank through the pump a check valve is used as can be seen in the diagram.
This system then operates by measuring the pressure in the tank and turning the motor on, if the pressure is below a certain value, and turning it off, if the pressure is above a certain value.
So the question is, can we do better than the system depicted above? That is, can we avoid such a big variation in pressure without burning the motor with too frequent on and off switching. The answer is the frequency regulation.
Water pumps have an interesting property that output pressure is proportional to the speed of the motor rotation. This property can be utilized to achieve wanted pressure by varying the speed of the motor depending on the current consumption of water.
Now the big open question is, how do we know at which speed to run the motor? Luckily control systems have a lot of research on this topic, and using the PID regulation (wikipedia) was an easy task. You may ask how did we know about PID regulation?! First was, partly from the literature and some classes on control systems, but more importantly the frequency regulator we had at hand had a built-in support for PID regulation.
So here is the pseudo algorithm to determine the speed of the motor based on the PID principles:
Let MIN_MOTOR_SPEED = 25Hz
Let MAX_MOTOR_SPEED = 50Hz
Let DESIRD_PRESSURE = 2Bar
Let total_error = 0;
Let previous_error = 0;
Every X milli seconds (e.g., 100 ms):
Let current_error = DESIRD_PRESSURE - current pressure
total_error = total_error + current_error
diff_error = previous_error - current_error
Let motor_speed = (Alpha * current_error +
Beta * total_error +
Gama * diff_error)
Let actual_motor_speed = min(
previous_error = current_error
So what lies in the heart of this algorithm? The basic principle is the fact that we compute three types of errors: Proportional (current_error), Integral (total_error) and Differential (diff_error) between the desired water pressure and the actual water pressure. We then combine these errors with Alpha, Beta and Gamma constants to get to a speed at which motor should rotate.
The Alpha, Beta and Gamma constants are tweaked for each individual system and they mainly have the influence on how fast the system will react to the change in water consumption. The faster the reaction, the higher probability of increasing/decreasing the speed too fast and making an overshooting error. The slower the reaction, well the system will get slower to the required pressure. Here are some examples of the pace of a reaction to the consumption change.
Last thing to bear in mind is the physical limitations of a motor. We need to cap the rotation speed of the motor between MIN_MOTOR_SPEED and MAX_MOTOR_SPEED.
No Outflow Detection
We’ve gone a long road already. Our pumps are working perfectly tuned to the current water consumption, giving us exact required pressure. But, we have missed one boundary condition, what happens when there is no water outflow, e.g., all taps are closed.
Given our current setup, we would not be able to distinguish this state and we would end up tuning a motor to a certain speed that would keep the pressure in the water chamber at the required level although there is no outflow of the motor. This is a waste of resources and we would like to avoid it.
First, and the simplest solution that comes to mind, is to turn off the motor if the speed goes under a certain predefined threshold. However, with this approach, we will introduce an on-off regulation pattern at low levels of water outflow. Furthermore tuning this threshold is not easy as too low of a threshold and we might end up wasting resources for unnecessary spinning, while too high of a threshold and we are back at the square one with the on-off regulation. In addition, the required pressure level can change over time, or the pump can lose some of its efficiency over time, resulting in a need for threshold update over time.
Oscillating Required Pressure
After a long time of trial and error we were able to finally solve the problem. Although the task was to maintain the constant pressure level, the solution was to oscillate the required output pressure around the nominal required pressure. E.g., if we require 2bar pressure we can oscillate between 2.1bar and 1.9bar and this can’t be easily felt on the end consumer side. In case there is no outflow of water when we achieve higher level pressure, 2.1bar in the example, we will maintain it due to the check valve in place. When we drop the required pressure to 1.9bar we can see that actual pressure is not dropping and this cans serve as a signals that there is no water outflow, see diagram below.
The simplest way of implementing this oscillation is to use hysteresis function (wikipedia) which computes required pressure based on the current pressure and its previous state. Pseudo algorithm is as follows:
Let MIN_DESIRED_PRESSURE = 1.9Bar
Let MAX_DESIRED_PRESSURE = 2.1Bar
Let desired_pressure = MAX_DESIRED_PRESSURE
Every X milli seconds (e.g., 100 ms):
if (current_pressure >= MAX_DESIRED_PRESSURE and
desired_pressure == MAX_DESIRED_PRESSURE):
desired_pressure = MIN_DESIRED_PRESSURE
if (current_pressure <= MIN_DESIRED_PRESSURE and
desired_pressure == MIN_DESIRED_PRESSURE)”
desired_pressure = MAX_DESIRED_PRESSURE
As we see the desired pressure starts at the upper bound and stays there until current pressure achieves it, then it is set to the lower bound and stays there until current pressure gets to that value.
Given this oscillations, if the state of the desired pressure is at the lower bound and current pressure is not approaching it for a while, we can safely turn the motor off as there is no outflow of water. The moment someone turns the tap on, the current pressure will drop to the lower bound and we need to restart the motor.
Although not a rocket science, this project was instrumental in my understanding of hardware and how couple of simple concepts can work together to deliver a smoothly functioning system. On the other hand, it was eye opening how simple requirement of ‘deliver water at a given pressure, without constantly turning motor on and off’ can result in a significant engineering effort and deep thought about the problem. All in all, this was an amazing project and I’m honored to have been part of it.