Water Backup System - Overall Design Strategy

[TerryJC]

I have raised this Topic because there are little threads of discussion about this solution in a number of places which are somewhat disconnected. The answer to this - create yet another Topic

What I intend for this Topic is to allow us to flesh out the overall approach to this solution so that the actual development details can then be filled out in the appropriate places. These Topics are where discussion has already taken place:

1. The idea was introduced when we found that we were losing water; see System Status entry at viewtopic.php?p=5799#p5799. We shouldn't discuss this problem there anymore.
2. A new Topic was created specifically to cover the software at viewtopic.php?t=322. This should be used for detailed software queries and comments.
3. A new Topic for the hardware design was created and an updated overall system diagram was posted here viewtopic.php?p=5909#p5909. This should be used to cover any hardware queries and comments.

So the current overall Water Backup Strategy will be that at 1600 each afternoon, both the Sump Pi and the Wendy Butts Pi will suspend normal operation and go into the backup mode. Specifically:

• Sump Pi will monitor the water levels in both the Sump and the Wendy Butts and pump water from the Sump if the Wendy Butts have capacity. Once the Sump has pumped away nearly all of the water, the Main Circulation Pump will be stopped, which will allow the many litres of water in the bog garden and the river to cascade down and replenish the Sump. This will continue until there is no water left in the river or the Wendy Butts are full.
• Wendy Pi will monitor the water levels in the Wendy Butts and the upstream Butts and pump water from the Wendy Butts to the Lady Hanham and / or Stage Butts if they have capacity. To do this, the upstream Gate Valves must be opened and the Bypass Valve must be closed.

One thing that only occurred to me while I was writing the new code is that although the Sump Water Backup routine can be relied upon to 'just get on with the job', the Wendy Butts routine must be much more aware of the situation elsewhere (or vice versa). The WendyPi will have full control over the Bypass Valve, but the Sump Pi normally opens and closes the Wendy Gate Valve (V4). Similarly V12 will be controlled by the Stage Pi and valves V1 to V3 by Lady Hanham Pi. As far as control of V4 is concerned, Sump Pi will already have closed it, but the other Pis will potentially try to oppose the Wendy Butts Water Backup Routine by closing their prospective valves unless a holistic approach is adopted.

My thought is that all SAC Pis should have a Water Backup Routine called at 1600 UTC. The Lady Hanham Pi and Stage Pi should then do nothing until 0700 UTC, thus relinquishing all control of their respective Valves to the Wendy Butts Pi.

Can I have your thoughts on this approach?

[PatrickW]

You would get much of the required functionality for free if the standard logic were in a finished state. The upstream butts groups stop transferring water downstream if the Wendy Butts are close to being full, to avoid an overflow in the event of the Sump suddenly wanting to pump water into the Wendy Butts. However, they will flow water downstream up until that point, so you could still get water flowing into the Wendy Butts from both directions up until that point.

The elephant in the room, though, is that the upstream logic is unfinished and doesn't currently do any pumping at all, so a solution which bypasses that logic at certain times of day may be a good option for now.

The potential for a conflict of control over the flow direction upstream of the Wendy Butts was something I ran into when starting to develop the Lady Hanham SAC logic, because, while there is a defined priority order for the butts groups to fill/empty themselves, they need a way to say "OK, I'm done controlling the flow direction for now; who's next?" and also to say "Hey, I want to take control now and I have higher priority than you, so budge over."

The arrangement I settled upon was to register a "control token" in the database. By "gentleman's agreement", only the holder of the token will control the flow direction. The logic for each butts group registers in the database its interest in claiming the token. Each butts group can then see who else wants the token and thereby determine whether it can take the token, or whether it should cede control to a higher-priority butts group waiting in the wings. (I'm brushing over some of the implementation details, but that's the basic idea.)

If the token system were fully implemented, it would eliminate the need for a special Water Backup Routine at Lady Hanham SAC and Stage SAC, since the logic at both sites could automatically cede control over the flow direction to the Wendy Butts if the Wendy Butts took the token and were defined to have the top priority to take the token.

However, this does not mean that you cannot start out with a time-based Water Backup Routine and switch to tokens later on.

In short, I can't immediately see an issue with taking with the proposed approach. (I also like the new arrangement of pump and bypass valve.)

[PatrickW]

I would suggest defining the times of day for the switchover somewhere in the main config, to avoid having to update all the routines separately in the event of a change to the desired time of day for the backup mode to operate.

[TerryJC]

Patrick,

Thanks for that insight. I was aware that you had taken a different approach for the Lady Hanham and Stage logic, but hadn't taken to much notice of it, since the LH system wasn't implemented and I don't believe that the Stage system is fully working yet.

I like the idea of the token.

[TerryJC]

I would suggest defining the times of day for the switchover somewhere in the main config, to avoid having to update all the routines separately in the event of a change to the desired time of day for the backup mode to operate.

I like that. I'll build it in.

[hamishmb]

I think all the SAC Pis having a water backup routine seems like a sensible and simple way to solve the problem.

I like the idea of a token as well, but I wonder if it would end up becoming quite complex. There's probably a good way of keeping such a thing simple, but I'm not sure what it might be. At any rate, I'm not currently planning on taking on any more work than I have already agreed to, besides doing the occasional code review and merge as needed.

[TerryJC]

I've completed the first draft of the code for the Wendy Butts backup system, ie Wendy Butts to the upstream butts. I intend to commit my changes and push them to GitLab shortly.

However, before I do that, I'd like some guidance on my strategy. The approach is very much based on the one used for the Sump to Wendy Butts code, eg in psuedo code:

Code: Select all

if sump level > 600 mm:
    turn on the butts pump if the wendy butts isn't full
    print/log the actual level.
    set the reading interval to 30 seconds
elif if sump level > 300 or < 600 mm:
    turn on the butts pump if the wendy butts isn't full
    print/log the actual level.   
    set the reading interval to 60 seconds[
else:
    turn off the butts pump
    print/log the actual level.
    set the reading interval to 30 seconds

In the original sumppi code the level is checked at each iteration and has an action applied at 100 mm intervals. The only real difference between the different levels, apart from < 300 mm is the reading interval.

While looking at this, it occurred to me that the above approach could be replaced in the case of the backup solutions with:

Code: Select all

set the reading interval to 60 seconds

if wendy butts level > 300 mm:
    turn on the backup pump if the upstream butts aren't full
    print/log the actual level.
else:
    turn off the butts pump
    print/log the actual level.

Also. The code for the upstream backup is complicated by the fact that every butts group has it's associated Gate Valve, eg V1, V2 and V3 for Lady Hanham butts and V12 for Stage butts. I started out trying to come up with a strategy to fill each butts group individually, starting at the top, and gradually close the associated Gate Valve when that Butts group was full. In psuedo code:

Code: Select all

open all Lady Hanham Gate Valves
pump until G1 is full
close V1 Gate Valve
pump until G2 is full
close V2 Gate Valve
pump until G3 is full
close V3 Gate Valve
open V12 Gate Valve
pump until G6 is full
close V6 Gate Valve

What I have done currently is to simply open all four Gate Valves and pump until all four high float switches pop. This should work providing there isn't a huge difference in the levels at the two sites and there is sufficient headroom in the butts to allow a bit extra before the barrel starts overflowing. If this isn't the case, then we could start losing water when one butts groups starts overflowing because one of the other float switches never pops.

Any thoughts on this before I finish my code?

[Penri]

I'd assumed, with no particular basis for it, that we would be filling one Butts group (5 barrels) at a time. I need to find the spec. sheet of the pump to see what it says about the pump's capabilities, probably not much as it's an off the shelf pump for garden ponds. We will have to try it in situ and see what happens.
I can simulate various load conditions by manually opening the gate valves and then opening or shutting the ball valves to bring difference combination off butts into play.
Before doing that I need to plumb in the pump and by-pass valve, which won't be until next week at the earliest.

[hamishmb]

I think your current approach should be fine for the Hanham butts, but I see no reason not to implement something a bit different:

Code: Select all

if (any of G1, G2, G3 is not full):
    open the hanham gate valve for each group that isn't full
    start pumping
if (G1 is full):
    close V1
if (G2 is full):
    close V2
if (G3 is full):
    close V3
if (G1 is full and G2 is full and G3 is full):
    close all valves and stop pumping.

This approach should fill them all regardless of which is highest. Obviously this code ignores the stage butts, though. I'm not sure what the planned approach for those is right now.

Am I right in saying the head pressure won't be any higher if we're pumping to all 3 groups at once, as they are all at roughly the same elevation anyway?

NB: Please make a merge request when you've finished it so it stays on my radar.

[TerryJC]

Hamish,

I realise I can test the float switches on each butts Group and respond as you suggested, but that adds a lot of complexity to the code. My question was related to whether or not it was worth doing all that if the butts probably won't overflow anyway.

I think that the answer to the question; 'when any butts group is full, are any other butts groups overflowing?' would allow us to decide. Plus the capability of the pump of course.