Switching battery issues

[nakomaru]

The production side is dead simple (purple = main line)

For grids with multiple power production stations:

Spoiler

On 11/27/2020 at 11:21 AM, nakomaru said:

Transformer drain order is done in the order that the transformers are built, with the oldest drained first. So if you build two big power stations then you can build like 6 transformers on your solar power station then 6 transformers on your nat gas station, and if you charge your batteries in small increments most of the power will be drained from your solar station first.

More transformers and smaller increments is better. The reason is because you can charge your entire battery in one frame with enough transformers in your solar station, which means the lower priority transformers in your nat gas station aren't used.

Here's how you can pull off power: 

[psusi]

On 12/19/2020 at 3:32 AM, nakomaru said:

The production side is dead simple (purple = main line)

It gets even simpler.  You don't need that heavy watt wire and 4kw transformers even.  You just need a pair of regular transformers and smart batteries for the automation and the generators themselves just go on the main normal wire trunk:

https://forums.kleientertainment.com/forums/topic/112270-a-new-take-on-battery-switching-regular-wire-power-grids/

 

[nakomaru]

I can't possibly imagine how you think that's simpler. Or a better use of space, materials, heat, and so on.

[psusi]

1 hour ago, nakomaru said:

I can't possibly imagine how you think that's simpler. Or a better use of space, materials, heat, and so on.

Because heavy watt wire and transformers add complexity and cost compared to NOT needing those things?

 

[nakomaru]

Yeah I can see how using 40 tiles of space, two transformers and a battery switch for every 2kW of production is simpler and more efficient than just like 3-6 transformers with no automation covering your whole base.

[psusi]

17 hours ago, nakomaru said:

Yeah I can see how using 40 tiles of space, two transformers and a battery switch for every 2kW of production

It isn't for every 2kw of production; it is for every automation signal you want to control generators.  I normally only have two or three of them: one at the SPOM control the hydrogen generators, maybe one for some coal generators, and one for petrol.  In your picture there you have 4kw of production from 5 NG generators.  The only difference I'm suggesting is getting rid of the heavy watt wire, 3 of the transformers, and downgrading the remaining two to 1kw.  You still control the 5 generators from the automation output of one of the pair of smart batteries just like you currently are.

[nakomaru]

I'll pass. No need to downgrade instantaneous mainline capacity of 12kW to 2kW. The difference in space/capacity wasted - for no gain - only gets more pronounced with bigger examples than those.

[psusi]

3 hours ago, nakomaru said:

I'll pass. No need to downgrade instantaneous mainline capacity of 12kW to 2kW. The difference in space/capacity wasted - for no gain - only gets more pronounced with bigger examples than those.

You're not listening.  The main line capacity isn't limited to 2kw.  The 2kw is only the limit of how fast your local battery can transfer to other batteries on the grid.  You can easily have 20kw worth of generators and 16kw peak loads on the grid with just the two basic transformers.

In your case, you have 16 kW of excess transformer capacity over the output of the generators, meaning that yes, you can zap charge a single battery flipper on a load circuit very quickly.  If you like to use single battery flippers on the load circuits, then I guess that high burst capacity can be a good thing, but I just stick with double battery flippers on the loads so they don't get interrupted ( even for a short period while being zap charged ) and there's no need for a really fast transfer from the first batteries to the others.  I only need the primary batteries to decide when to turn on the generators and that's it.

[bjp]

@nakomaru It's been a while since I looked at the flipper stuff. I hadn't seen the timer setup, that's neat.  Do you find you have to tune the timer settings for heavy loads at all or is it always the same? 1/1?  Also, is there a way to 'turn off' the flipping if nothing is drawing power?  That's one aspect I liked of using the battery signal.

 

 

...

Quote

The main line capacity isn't limited to 2kw.  The 2kw is only the limit of how fast your local battery can transfer to other batteries on the grid.

 

This effectively limits how fast you can charge your consumer side batteries, which limits their sustained draw.  Worse, that 2kw is divided among your consumers, so if you have a lot of consumer side flippers, they will drain much faster than your producer side batteries, so your generators might not turn on in time to prevent brown outs.  It's pretty easy to cause brown outs in testing with really high loads, especially since I sometimes setup a heavy-watt wire consumer to feed multiple transformers (so I don't have to build a bunch of flippers in one spot).  These heavy consumers can draw a lot more than 2kw by themselves.

My testing setup:

Spoiler

• 

 

 

[nakomaru]

1 hour ago, bjp said:

Do you find you have to tune the timer settings for heavy loads at all or is it always the same? 1/1?

I would recommend 1/1 in general or up to 5/5 for 20kJ batteries & 2kW consumers if you want to decrease the racket they make. If you need more than 20kW, use jumbo batteries or double up on smarts.

1 hour ago, bjp said:

is there a way to 'turn off' the flipping if nothing is drawing power?

I think I have solved this bug for all personality types now.

[bjp]

Ah nice, I always forget the voltage sensor exists.  I ended up just AND-ing the timer with the battery outputs:

 

[nakomaru]

Unfortunately that is not a complete solution.

Look at what happens just after being fully charged when all four power shutoffs bug.

Consumers lose power. Neither battery demands energy so the timer is unable to recover the shutoffs.

You must wait for the battery to naturally drain to trigger a green signal. The best setting for this would be red% green / 99% green. For some reason smart batteries are bad at math and think that 99% means 19,900J (it should be 19,800J). But the result is you will need to wait for up to 100J to drain from runoff which takes 150 seconds, or 300 seconds if they fix smart battery math. During which time your consumers will have no power. Maybe this is okay for most of your applications but unacceptable for some.

On the other hand, the wattage sensor solution instantaneously detects when both power shutoffs have entered a bugged state, and forces a panic regardless of the battery's state via XOR.

Here's the best I could do on making it smaller. (consumers on left side - swap battery/bridges for reverse)

Spoiler

[bjp]

Oh right, I didn't even think about that case.  The few times I've noticed is because I had a drained battery that wasn't recharging.

 

In that case then you really can't have a state where you 'never switch', right?  You will always need some minimum time interval to send a flip to account for the bug even if you have zero draw for a long time.   My dreams of a quiet base crushed...

 

If that's the case, then there's really no need for the wattage sensor plus extra drain, right?  Just use a timer.  If you use the old school timers (automation only), they are re-settable, so you can make it only trigger after N seconds without a change in state: (the counters are positive edge detectors (from Saturnus automation post)).

 

EDIT2: Ok I think I fixed it by just putting an xor to pulse when the state hasn't changed in a while:

 

 

EDIT: the (previous) below fails when the battery is drained

Spoiler

[Saturnus]

I'm not really following why this is a big issue anymore.

To make an effective reset you just have to make sure you have a consumer on the line that is always active and a watt sensor. If watt drops to zero then reset.

Alternatively, if you really want to avoid black outs you can add a smart battery on the consumer side that activates at lower than the switching batteries. That acts as the reset.

[nakomaru]

1 hour ago, bjp said:

In that case then you really can't have a state where you 'never switch', right?  You will always need some minimum time interval to send a flip to account for the bug even if you have zero draw for a long time.   My dreams of a quiet base crushed...

 If that's the case, then there's really no need for the wattage sensor plus extra drain, right?

Have a look at my wattage solution again. It waits quietly when full and only triggers a panic only when the shutoffs are bugged. It should recover within 1 second if you set the timer to 0.6/0.6, or 1-2 seconds if you set it to 1/1. It also lets you set whatever battery interval you like.

1 hour ago, bjp said:

Just use a timer.

Help me understand, I can't figure out how this solution is better than just a timer. This solution will make a racket at full charge just like a straightforward timer solution. I guess this is if you want to avoid a 5 second interval for noise and are okay for up to like 20 seconds of a blackout?

28 minutes ago, Saturnus said:

you just have to make sure you have a consumer on the line that is always active and a watt sensor

Sadly I overcomplicated it. This is an obvious point in hindsight allowing even more simplification.

Here's a variant that only uses 0.67W if 8W is too much for you. But it also produces 3× the heat.

Spoiler

[Saturnus]

41 minutes ago, nakomaru said:

Here's a variant that only uses 0.67W if 8W is too much for you. But it also produces 3× the heat.

  Reveal hidden contents

You know what. I'm literally kicking myself here. You don't even need a permanent power consumer at all. Just sensing zero power to activate resetting mode will do for most people.

[bjp]

56 minutes ago, Saturnus said:

I'm not really following why this is a big issue anymore.

To make an effective reset you just have to make sure you have a consumer on the line that is always active and a watt sensor. If watt drops to zero then reset.

Alternatively, if you really want to avoid black outs you can add a smart battery on the consumer side that activates at lower than the switching batteries. That acts as the reset.

 

I wouldn't call it a big issue, just an interesting thing to think about.  I was trying to think of a way to work around it (the shutoff bug) without adding extra power draw.  I didn't think about the smart battery as a reset, that's a good one, tho it takes up a decent amount of (non-automation) space.

 

55 minutes ago, nakomaru said:

Have a look at my wattage solution again. It waits quietly when full and only triggers a panic only when the shutoffs are bugged. It should recover within 1 second if you set the timer to 0.6/0.6, or 1-2 seconds if you set it to 1/1. It also lets you set whatever battery interval you like.

 

Help me understand, I can't figure out how this solution is better than just a timer. This solution will make a racket at full charge just like a straightforward timer solution. I guess this is if you want to avoid a 5 second interval for noise and are okay for up to like 20 seconds of a blackout?

Sadly I overcomplicated it. This is an obvious point in hindsight allowing even more simplification.

Here's a variant that only uses 0.67W if 8W is too much for you. But it also produces 3× the heat.

  Reveal hidden contents

Ok I understand the watt sensor solutions better now.  I was originally trying to avoid adding draw to the consumer side, but it is a pretty small amount.

 

The difference my 'timer circuit' and 'just use a timer' is that the timer cannot be reset.  This lets you put the timing circuit on something longer (like 10s) and under normal load the flipper will flip when needed, but when there's no load it will only flip once every 10s.  Since this is only to 'fix' the broken shutoffs on game load, I don't mind 10-20s of delay.

 

The watt sensor or smart battery is probably better (in terms of avoiding needless togglign) if there's room to spend on it.

 

 

14 minutes ago, Saturnus said:

You know what. I'm literally kicking myself here. You don't even need a permanent power consumer at all. Just sensing zero power to activate resetting mode will do for most people.

Oh yea, that seems obvious once you think of it...

It has the same characteristics as my more complicated resetting timer...

 

 

EDIT: Actually it's even better, as it only pulses a "reset" once instead of repeatedly, which is all you need to fix the bug.  My dreams of a quiet base are realized!  Thanks @Saturnus

 

[nakomaru]

I considered a single pulse solution like that, but you could also hit the bug on that pulse.. I guess it's probably good enough?

[Saturnus]

3 minutes ago, nakomaru said:

I considered a single pulse solution like that, but you could also hit the bug on that pulse.. I guess it's probably good enough?

If you're really worried about that then use a buffer gate to make it a slightly longer pulse.

[nakomaru]

Fom my understanding I think this design is bugged and I don't know how to fix it without an oscillator or dedicated consumer.

1 hour ago, bjp said:

1. Batteries are fairly well charged when the load turns off
2. The wattage sensor detects no load and schedules an XOR flip (with no filter in 0.1 seconds, with a filter in 5s, etc)
3. The XOR flips and at the same time we save, triggering the bug
4. All four power shuttoffs are now off, although 2 of them have a green signal
5. Consumers black out. The battery will not trigger the next XOR flip until it crosses its lower threshold

With a dedicated consumer, you *probably* don't need the oscillator, since it will only trip when we are 100% sure it is bugged. You would have to save again at just the wrong time when we try to recover from the first bug.

But also, with a dedicated consumer, the oscillator will be disabled as soon as we recover, so it is only one extra tile consumed and does not cause a racket.

[bjp]

26 minutes ago, nakomaru said:

Fom my understanding I think this design is bugged and I don't know how to fix it without an oscillator.

1. Batteries are fairly well charged when the load turns off
2. The wattage sensor detects no load and schedules an XOR flip (with no filter in 0.1 seconds, with a filter in 5s, etc)
3. The XOR flips and at the same time we save, triggering the bug
4. All four power shuttoffs are now off, although 2 of them have a green signal
5. Consumers black out. The battery will not trigger the next XOR flip until it crosses its lower threshold

With a dedicated consumer, you *probably* don't need the oscillator, since it will only trip when we are 100% sure it is bugged. You would have to save again at just the wrong time when we try to recover from the first bug.

Good point.  That does narrow the window of hitting the bug significantly, though.

 

I believe you can fix it if you put transformer between the batteries and the watt sensor on the consumer side.  If it loads in the bugged state, the transformer must be full (batteries were charged).  As soon as a consumer tries to use power, the energy stored in the transformer will cause the watt sensor to flip.

 

The only way I can see this failing is if your power source has failed, causing your batteries to stop charging, causing your transformer to drain, *AND* you save it at exactly the same time that the watt sensor goes off.  I don't think that will go unnoticed, however...

[nakomaru]

12 hours ago, bjp said:

I believe you can fix it if you put transformer between the batteries and the watt sensor on the consumer side.  If it loads in the bugged state, the transformer must be full (batteries were charged).  As soon as a consumer tries to use power, the energy stored in the transformer will cause the watt sensor to flip.

Great solution using a transformer as a buffer. Your solution is in-line and can only fail in rare circumstances. Not really usable for heavi-watt consumers. Here are pictures of them.

Spoiler

Granted, you are now using more space than a lamp and about the same space as a battery+small transformer, both of which can never fail and work with heavi. Whichever you like I suppose.

I think I'm gonna use this build. Reliable, quiet, and small.

Spoiler

[Nikorasu]

Just curious.. Has the shutoff bug been confirmed to be present in Linux? Cause I've yet to experience it personally, and I haven't been using the timer fix.. And I can't seem to intentionally trigger it to happen either, no matter how many times I try to save right in the middle of the shutoffs switching.. Maybe it has happened to other linux players already, and I'm just very lucky so far.. but it's still something interesting to note, if not.

[TheMule]

14 minutes ago, Nikorasu said:

Just curious.. Has the shutoff bug been confirmed to be present in Linux? Cause I've yet to experience it personally, and I haven't been using the timer fix.. And I can't seem to intentionally trigger it to happen either, no matter how many times I try to save right in the middle of the shutoffs switching.. Maybe it has happened to other linux players already, and I'm just very lucky so far.. but it's still something interesting to note, if not.

Now that I think of it, I play on linux too. @nakomaru sent me a savefile, after loading it I had the switch stuck. It's a bug anyway, since you can clearly see the green signal, the status says activated but it's off power-wise. But I think it's more than I year that I don't see the bug happen. And there was a time in which it was very common, last year (2019). I have an extensive mod list tho, so who knows?

I think something along the line happens:

objects with incoming automation ports register event listeners - the wire acts like a bus. They DO NOT poll for status.

The wire goes green, the event listener is fired on the shutoff. It does 2 things: set the state as active automation wise (and the event is 'processed'), set the power state as connected.

If a save occurs between step  1 and 2, the event results processed and the event listener is not restarted at load. Power state is not coherent with automation state.

That's pure speculation I don't know the details of the code at all. If I'm close, tho, probably it could be fixed by reversing the order, so that marking the event as processed is the last thing to happen. Worst case, at load the event is processed again and the power state is set twice.

[nakomaru]

To reproduce

1. Enable debug mode, state-step through the game (ctrl-F5) until your control/battery/center wire turns from red to green
2. At this moment, your ribbon reader will be still be red (in the next frame it will be green)
3. Save at this moment, then reload