Water Backup System - Overall Design Strategy
Re: Water Backup System - Overall Design Strategy
Hamish,
What about my query regarding having activity at the intermediate levels?
What about my query regarding having activity at the intermediate levels?
Terry
Re: Water Backup System - Overall Design Strategy
I think you might still want to vary the reading interval between 60 and 30 - if they overflow just after the reading, pumping and overflowing for 60 seconds is potentially quite a lot of water wasted. Otherwise, seems good to me, for the backup logic.
Hamish
Re: Water Backup System - Overall Design Strategy
Thinking some more about this, it's not the depth of water in the Wendy Butts as they fill that is the worry; it's the depth of water in the upstream butts. The problem is that the current strategy that I've been coding is similar to the strategy adopted by Sump Pi when monitoring the depth of water in the Wendy Butts. While there is a significant amount (> 300 mm) of water in the Sump, the water is pumped until the high Float Switch pops in the Wendy Butts. In the case of the Sump control algorithm, the variable reading rates are important because we don't want to run the Main Circulation Pump or the Butts Pump when the Sump is dry. We are less concerned about the Wendy Butts overflowing.
The question now is; should we be any more concerned about the upstream butts overflowing? If we are, then the levels in each butts group will need to be monitored, rather than the float switches. This would add significantly to the number of lines of code.
I believe that we should monitor the depths of water in the Wendy Butts while pumping water upstream, to protect the Water backup Pump. I personally don't think we should add complexity to the software just to prevent overflows.
What's the consensus?
BTW. I've decided to fill the upstream butts groups individually rather than all at once, as in my original strategy. It gives more scope for retaining water at the top of the system should a problem occur downstream and it means we don't have to worry too much about pump capacity.
Terry
Re: Water Backup System - Overall Design Strategy
Found the pump spec. sheet and the order that confirms which model was purchased.
So we have a PondPro Rapid 8000 which does the following:
Power consumption - 75W
Max Head - 4.5m
Flow output - 8000l/hr (133.3l/min)
All in all it should have no problem moving water to the up-stream butts, although the length of pipe and the various fittings (particularly 90 degree bends) will impact the flow rate we will actually see.
By the way it's the same model of pump as we have currently installed feeding the Wendy Butts.
Terry - will the control I/O for the pump's SSR be open collector.
I'd like to drive the SSR off 12V, and in the box in which I will house it incorporate a manual 3 position switch (On-Off-Auto) and a led to indicate when the SSR is switched on.
Penri
So we have a PondPro Rapid 8000 which does the following:
Power consumption - 75W
Max Head - 4.5m
Flow output - 8000l/hr (133.3l/min)
All in all it should have no problem moving water to the up-stream butts, although the length of pipe and the various fittings (particularly 90 degree bends) will impact the flow rate we will actually see.
By the way it's the same model of pump as we have currently installed feeding the Wendy Butts.
Terry - will the control I/O for the pump's SSR be open collector.
I'd like to drive the SSR off 12V, and in the box in which I will house it incorporate a manual 3 position switch (On-Off-Auto) and a led to indicate when the SSR is switched on.
Penri
Re: Water Backup System - Overall Design Strategy
Penri,
We will now only be pumping to one butts group at a time as per my earlier comment.
The drive for the SSR from the Wendy SAC will be identical to the Sump SAC:
Since you only need one channel, we would need to agree whether you were going to use Pin 6 or 8 on TB1. You can get your 12 V from Pins 5 and 7, as you can see.
We will now only be pumping to one butts group at a time as per my earlier comment.
The drive for the SSR from the Wendy SAC will be identical to the Sump SAC:
Since you only need one channel, we would need to agree whether you were going to use Pin 6 or 8 on TB1. You can get your 12 V from Pins 5 and 7, as you can see.
Terry
Re: Water Backup System - Overall Design Strategy
This is incorrect. As you can see at: https://gitlab.com/wmtprojectsteam/rive ... ollogic.py, the interval is reduced to 30 seconds while we are pumping to the butts. I remember making this change to avoid overflows back in the day. We found through testing that 30 seconds was enough to catch it before it overflowed. Of course, if the float switch isn't set up identically on the others, this situation might be different.TerryJC wrote: ↑25/05/2022, 15:54 Thinking some more about this, it's not the depth of water in the Wendy Butts as they fill that is the worry; it's the depth of water in the upstream butts. The problem is that the current strategy that I've been coding is similar to the strategy adopted by Sump Pi when monitoring the depth of water in the Wendy Butts. While there is a significant amount (> 300 mm) of water in the Sump, the water is pumped until the high Float Switch pops in the Wendy Butts. In the case of the Sump control algorithm, the variable reading rates are important because we don't want to run the Main Circulation Pump or the Butts Pump when the Sump is dry. We are less concerned about the Wendy Butts overflowing.
I don't understand the logic here, why is using the float switches not good enough?
Agreed.
Okay.TerryJC wrote: ↑25/05/2022, 15:54 What's the consensus?
BTW. I've decided to fill the upstream butts groups individually rather than all at once, as in my original strategy. It gives more scope for retaining water at the top of the system should a problem occur downstream and it means we don't have to worry too much about pump capacity.
Hamish
Re: Water Backup System - Overall Design Strategy
I don't remember that, but I can see that is what you are doing now.hamishmb wrote: ↑25/05/2022, 17:30 This is incorrect. As you can see at: https://gitlab.com/wmtprojectsteam/rive ... ollogic.py, the interval is reduced to 30 seconds while we are pumping to the butts. I remember making this change to avoid overflows back in the day. We found through testing that 30 seconds was enough to catch it before it overflowed. Of course, if the float switch isn't set up identically on the others, this situation might be different.
I'm not saying that it's not good enough. What I was trying to say is that if we don't monitor the levels, then there is no warning that a particular butts group is about to pop the high float switch. Hence the need to set the reading rate to a low value to avoid overflowing.
The big difference between the operation going on between the Sump and the Wendy Butts during normal operation is that during the day we are trying to maintain the level of water in the Sump somewhere between two set levels (300 mm and 600 mm). For the backup solutions, we are doing something completely different; we are trying to empty the bog garden, river and sump completely and fill the butts with the water from the sump. This means that we will spend all the time pumping until either the butts are full or the sump is empty. We will only stop pumping when either of those conditions are met so we are likely to overflow any of the butts groups in the system with very little warning if we are entirely reliant on the high float switches. This means that there is little scope for varying the reading interval during backup operations; we will have to use 30 seconds while pumping and something else when we are not.
Assuming we don't want to add the complexity of monitoring butts levels rather than float switches, then we could get clever and do something slightly different. Assuming that the pump is powerful enough to fill all butts groups simultaneously and none of the float switches are popped, we could pump with a relatively low reading rate (say 2 minutes). When the first float switch pops, we close the associated Gate Valve and increase the reading rate (to say 1.5 minutes) and so on until we are filling the last butts group at a reading rate of 30 s.
What do you think? Have I got it wrong?
Terry
Re: Water Backup System - Overall Design Strategy
Okay, I understand now. That sounds like a good approach I think, but maybe we'll have to try it and see how quickly it can pump on-site to see whether overflowing quickly is much of a risk?
Hamish
Re: Water Backup System - Overall Design Strategy
Hamish,
From Penri's spec, the head should be more than adequate; I doubt that the top of any of the Butts Groups are more than 2.5 metres above the pump. Assuming no losses (which Penri has pointed out there will be) at ~ 133 l/min and ignoring the head of water already in the butts, it would fill one butt in around 2 minutes and a complete butts group in about 10 minutes. So again ignoring losses, etc, a completely empty set of butts would fill in 40 minutes
Of course there certainly are losses and (presumably) the flow rate will reduce as each group fills owing to the head of water in the butts opposing the head of water from the pump. On the other hand the water level will increase rapidly as the water gets to the top of the butts owing to the curved shape of the barrel. The fact that there are five barrels per butts group will mitigate this a bit though.
Taking all of the above into account, I think we can see that we should be able to:
- Pump to all of the butts at once.
- Be reasonably confident that we will be able to stop before overflowing if we reduce the reading rate to a lower value as each group fills.
- I think it is more likely that the Wendy Butts will empty long before any upstream butts group is full (unless they start out full of course). This is because the water will be removed from the Wendy Butts Group at 133 l/ min and all other things being equal, it will empty in around 10 minutes.
- The Sump Water Backup routine must therefore be poised to replenish the Wendy Butts as soon as possible, so a low reading rate will be required there as well.
Terry