Distributing more than 20kw, revisited.

[Gus Smedstad]

I'm getting circuit overloads on my 20kw backbone in my current colony.

I've dealt with this before. The standard answer is battery-based switching "transformers." The last time I built a set of those, they proved unreliable. The circuit shutoffs would get stuck open or closed, and stop responding to automation signals.

Here's the design I used before:

The logic is sound; there's a single control point (battery #1), which ensures that of a shutoff switch pair, top row or bottom row, one and only one shutoff is enabled at all times. The extraneous OR gates are there just to insert a delay so the shutoffs activate in the same tick.

I'm assuming the shutoff switches haven't been fixed. If anyone can shed some light on how to avoid the bug, I'd like to know.

In the meantime, I wonder if there isn't a solution involving the standard power lines and transformers. I feel like there should be, but I'm not really aware of one that maintains a unified power structure. The obvious one is not to have a unified power system. To break the power system for the colony in two, and create separate power systems for each half. Each with its own hierarchy of power sources, solar / hydrogen / natural gas / petroleum. With the various steam turbines just attaching to whatever power system is nearest, I guess.

I'm not really fond of that idea.

[Xuhybrid]

Can you avoid the issue by using a battery on the transformer output to disable the transformer?

[Gus Smedstad]

10 minutes ago, Xuhybrid said:

Can you avoid the issue by using a battery on the transformer output to disable the transformer?

I'm not entirely sure what you're suggesting. I've got 56 large transformers. It sounds like you're saying add 56 batteries, one to the client side of each transformer, and control each transformer based on the battery on the other side.

I don't think that'd help. Was that what you meant, or something else?

[Xuhybrid]

That's correct. It probably wouldn't if you're using that many large transformers. The idea was to separate your power source with transformers instead of a power shutoff. Not practical but the practical solution is to just have separate power grids.

[mathmanican]

1 hour ago, Gus Smedstad said:

If anyone can shed some light on how to avoid the bug, I'd like to know.

Here is the most recent discussion.

 

This post includes a mechanical fix if the problem continues to plague you.

 

[Gus Smedstad]

4 hours ago, mathmanican said:

This post includes a mechanical fix if the problem continues to plague you.

You may see that I participated in that thread. I’m skeptical of the proposed solution for a variety of reasons; for one thing, sometimes the switch fails by leaving one of the shutoffs permanently on, so instead of getting a power loss, you get circuit overloads. The fix assumes you can detect the fault through power loss, and that pulsing the shutoffs with on/off signals will get them to start responding to automation signals again.

I may implement battery switches anyway, and see if I can learn anything about their failure state once they do inevitably fail. It’s not something you can easily test in debug, though, since it’s an unpredictable intermittent fault.

[Lilalaunekuh]

3 hours ago, Gus Smedstad said:

I may implement battery switches anyway, and see if I can learn anything about their failure state once they do inevitably fail. It’s not something you can easily test in debug, though, since it’s an unpredictable intermittent fault.

I stopped using battery switching cause I like to run my base unsupervised for a prolonged period of time.

=> I wasn´t able to find a reliable way to prevent problems.

[Mullematsch]

Can confirm this design never got stuck for me (save included): 

hovel2 .sav

[Lilalaunekuh]

2 minutes ago, Mullematsch said:

Can confirm this design never got stuck for me (save included): 

Looks like the one I used.

I used more than 20 switiching battery setups and let them run for a night.

=> 1-2 Switches got stuck in an arbitrary position.

 

[Not sure why it stops working, but if you let your base run for long enough the bug may catch up with you aswell.]

[Mullematsch]

2 minutes ago, Lilalaunekuh said:

Looks like the one I used.

I used more than 20 switiching battery setups and let them run for a night.

=> 1-2 Switches got stuck in an arbitrary position.

 

[Not sure why it stops working, but if you let your base run for long enough the bug may catch up with you aswell.]

I only used the linked design a couple times for mainline -> heavy wire.

For mainline to conductive wire, I used this which only ever got stuck when loading the world for me, never while playing: 

[Gus Smedstad]

1 hour ago, Mullematsch said:

I only used the linked design a couple times for mainline -> heavy wire.

For mainline to conductive wire, I used this which only ever got stuck when loading the world for me, never while playing: 

 

Given that the design in the GIF is functionally identical to the design I used, which DID get stuck regularly, and that it’s logically identical to the one you used that did get stuck, the only difference being extra gates for delay purposes, it’s reasonable to assume that the only reason you didn’t experience the GIF version sticking is that you didn’t build as many, and got somewhat lucky.

Incidentally, that second OR gate in the GIF design does absolutely nothing.

As I said earlier, the problem with these battery switches isn’t the automation. It’s the shutoffs, which stop responding to automation for no known reason, and not in an easily reproducible way.

2 hours ago, Lilalaunekuh said:

I stopped using battery switching cause I like to run my base unsupervised for a prolonged periods of time.

So do you just break your power network up into independent groups, or what?

The only transformer-based solution I’ve come up with seems like a huge PITA. Namely, break power generation up into X groups, each of which cannot generate more than 20kw, and consumer grids into Y groups, each of which is unlikely to consume more than 20kw, and make X * Y connections between the two, each with 5 large transformers.

This gets rapidly out of control because heavi-watt lines don’t have bridges, and have no way of crossing over each other. The minimum configuration is 2 generator groups and 2 consumer groups, which means 4 sets of heavi-watt wire and 4 sets of transformers making the connections.

[Mullematsch]

15 minutes ago, Gus Smedstad said:

Given that the design in the GIF is functionally identical to the design I used, which DID get stuck regularly, and that it’s logically identical to the one you used that did get stuck, the only difference being extra gates for delay purposes, it’s reasonable to assume that the only reason you didn’t experience the GIF version sticking is that you didn’t build as many, and got somewhat lucky.

Incidentally, that second OR gate in the GIF design does absolutely nothing.

As I said earlier, the problem with these battery switches isn’t the automation. It’s the shutoffs, which stop responding to automation for no known reason, and not in an easily reproducible way.

Interesting. I always thought its about the automation and not related to lag or something similar. Maybe you can load up my linked save and check if it also gets stuck for you. Its 50 dups, 1500 cycles and I always play in super speed. I would have imagined if its lag related, that I would have had issues with it but it never got stuck for me. 

[Gus Smedstad]

“I always play at super speed” may have something to do with it. I never play at anything other than normal speed.

[Lilalaunekuh]

54 minutes ago, Gus Smedstad said:

3 hours ago, Lilalaunekuh said:

I stopped using battery switching cause I like to run my base unsupervised for a prolonged periods of time.

So do you just break your power network up into independent groups, or what?

I build a "standart" centralized power plant, but I have more than one backbone heavy watt wire.

=> I use the generator fuel for load balancing instead of the produced electrical energy.

[My current base uses 2 heavy watt wires:

• One for everything close to space. [Bunker doors, gantries, rocket fuel production, cooling ...]
• One for the rest of my base^^

My base design features 3 tile width corridors, so this would limit my power plant to 3 circuits without further refinement, but right now I don´t need more than 40kw^^]

 

 

[TLW]

16 hours ago, Gus Smedstad said:

the only difference being extra gates for delay purposes,

This is the key.

Most simpler smart battery designs have an asymmetrical delay, which causes occasional issues.

You need to make sure that the gate delays on the noninverted and inverted sides are the same (e.g. with a 'dummy' and gate).

[Gus Smedstad]

15 minutes ago, TLW said:

This is the key.

Actually, no, it's not. Sure, I'm aware of the importance of the delay to make sure the shutoffs switch in pairs, with no delay where either there's a direct path between both circuits, or the batteries are completely isolated for a tick, depending on how it's wired. But neither of those situations are the root cause of the lockup, where the shutoffs simply stop responding to automation. Circuits with delay gates (such as the one I used) still suffer from this bug.

[Gus Smedstad]

OK, @TLW, since you marked my response as "confusing," let me lay it out for you in detail.

The problem is not the automation circuitry. Examine the circuit in my original post. There's a single control point, one of the smart batteries. That battery always puts out "true" (green) or "false" (red) on the automation circuit. That in turn controls the four shutoffs. Each of those receives either a red (off, disabled) or green (on, enabled) signal. Since those are connected in pairs, and in each pair one is controlled through a NOT gate, and one through an OR gate with a single input, it's trivially true that in each pair, one shutoff should always be ON and one OFF. Since the delay in both cases is the same, timing is not an issue.

However, in practice, that's not what happens. Occasionally one shutoff switch turns ON or OFF, and stays that way, regardless of the signal from the wire. This is the known bug. In fact, Mathmanican has posted a save game demonstrating the stuck switch.

THE key thing about that bug report is the shutoff switch shows "Inactive" even though it's "enabled by automation." That should never, ever happen, no matter what the automation circuit is.

Logically, the delaying OR gate is irrelevant. If the game was working correctly and there was no bug, and you build a circuit with a delaying gate for the primary path, it only changes one thing: it's possible, for one tick, for both shutoffs to be ON or both to be OFF, due to the delay in the NOT gate. This is undesirable but it has no effect on automation. It does mean the smart battery providing the input signal can be either connected to both circuits or neither, but that does not affect the automation logic. At most, it might cause the smart battery to switch states a little faster as it's connected to more power, but that's it.

We don't know the exact internal mechanics of the bug. There's a widespread belief that a delay gate makes the bug happen less often, even though from a purely logical point, it's irrelevant. That may even be true due to some internal timing issues; as Mathmanican points out, there's a discrepancy in the order of text in the tooltip for the shutoff exhibiting the bug, and that discrepancy strongly hints that some sort of check occurred in a different order than normal.

Regardless, I and other players who have used these switches for long periods of time have seen the bug appear even with proper delays.

[cpy]

With latest update you can do 50kW now! Yeah baby!

[Gamers Handbook]

I believe I've figured out what causes the power shutoff bug and how to fix it.  I have a new bug report open, and a short video that shows my findings as well as a simple solution for the smart battery switching/flipping builds.

 

[biopon]

On 9/18/2019 at 8:35 PM, Gamers Handbook said:

I believe I've figured out what causes the power shutoff bug and how to fix it.  I have a new bug report open, and a short video that shows my findings as well as a simple solution for the smart battery switching/flipping builds.

Hey, thanks for the detailed video. Great detective work!

I think I have a "better" solution. Nothing's perfect though... This one needs a bit of space.

The idea is to detect and fix the bug as it happens with a minor power overhead and no delay. An inevitable effect of a "inactive, enabled" shutoff is that the batteries run down and don't get to recharge. When this happens, the smart storage container (that's set to store 1kg of whatever) will stop sending the otherwise always-on green signal, which is caught by my janky edge detector, and the output of this edge detector is xor-ed with the output of the battery before the latter would go to the shutoffs. So this provides the signal flip that the shutoff needs.

I've tested this as far as the edge detector and xor-ed signal working, but I couldn't get the bug to come up so I don't know if the 1-frame flipped signal is enough for the shutoffs to recover.

I only wish this wasn't so damn big.

Anyway, maybe someone can improve on this.

Power view, if not clear what's going on:

[Gamers Handbook]

Your post spurred me to take a shot at resetting the signal faster than a clock sensor too.  I approached it from a different perspective, and posted my design in your other thread.  Also if anyone wants a simpler solution, clocks set to just after the game is autosaved should (I think) work well if you only load your gave via autosaves.