Jump to content

A workaround for the power shutoff bug that plagues switching battery setups


Recommended Posts

On 9/24/2019 at 5:33 PM, biopon said:

You can also do this by setting the left battery sliders to 0/0 (or 100/100, depending on which state the system is stuck in), and then resetting them to your original config, presumably 100/10. If you're willing to do this the hydro sensor is unnecessary. 

Wow, and here I thought I was the only one who really knew about that, nice. I actually known(and used it) since automation first game out. Although in this case, I normally just slide the setting all the way left or right then use the above/below buttons as on/off.

Think of it like the manual switch, but you control it instead of the dupes.

Link to comment
Share on other sites

Maybe so, but the manual way is much faster to set up and is much better in spots were full automation would be too unreliable, in terms of triggers and all that stuff. It's also nice to attach one to an auto system as an emergency shut off when something goes wrong and/or said system's own emergency shut offs somehow fail.

Link to comment
Share on other sites

 

44 minutes ago, Bluefoxfire said:

It's also nice to attach one to an auto system as an emergency shut off when something goes wrong and/or said system's own emergency shut offs somehow fail.

This build flips the shutoffs in case one of the two batteries deplete. This is in case the shutoffs do fail both on the charging side or the load side.

Hide contents

image.thumb.png.99e4a36c0b771b48bdfb94dd33947136.png

image.thumb.png.013c4c80969b900152bca852b51e5314.png

image.thumb.png.83d678069dd05e0b3e50f9ea2e9f85b6.png

 

Just do this if you want an automated recovery system in case you are not generating enough power. It will activate again when it reaches the high threshold. the far right battery is set to 0/100

Spoiler

image.thumb.png.a776231473e010a5742dac67cf517ba9.png

This is still somewhat automated, so here is a manual one instead.

Spoiler

image.thumb.png.525c807cb5ffa5fcd0a2b22a397d6004.png

Because the shutoff bug only happens on a green signal, this breaker will never break, pun intended.

Link to comment
Share on other sites

3 minutes ago, BLACKBERREST3 said:

I'm having a hard time understanding why my build can fail

Imagine that your main battery finished charging, and it's switching back to "normal" state where it will supply power to the consumers. The bug hits and the shutoff that connects your main battery to the consumers fails to engage. The main battery at this point is disconnected from everything - from the consumers due to the bug, and the generators due to, well, the shutoff that's working properly. Your consumers are without power but your main battery doesn't lose charge other than the natural decay. It will only initiate a switch when its charge level hits the low config setting, which will take a while.

Link to comment
Share on other sites

When the main battery no longer supplies to the consumers and the third battery on the right, the third battery will start to drain and will send an automation signal to the NOT-AND and then to the XOR to send a 1-tick green pulse to reset all of the shutoffs. The 

11 minutes ago, biopon said:

"normal"

state is red on the main battery because it is charged, so when the green pulse hits it will reset the shutoffs which is how you fix the bug.

You might be thinking of my old build which did have that problem, but I have posted the new one several times.

Spoiler
27 minutes ago, BLACKBERREST3 said:

image.thumb.png.99e4a36c0b771b48bdfb94dd33947136.png

image.thumb.png.013c4c80969b900152bca852b51e5314.png

image.thumb.png.83d678069dd05e0b3e50f9ea2e9f85b6.png

 

 

Link to comment
Share on other sites

1 minute ago, BLACKBERREST3 said:

don't even get me started on aquatuner bypasses

 

:) Not to veer this topic way off course but what exactly is the problem? I mean I am aware of the issue but it goes away if you use a reservoir like a normal person does. :D Not only will it smooth out temperatures, and make piping changes very easy by providing a drain, but measuring at its output is objectively the best place for absolutely fine coolant temperature control. Just use one, and plumb your bypass any way it's convenient. 

Link to comment
Share on other sites

33 minutes ago, biopon said:

Not only will it smooth out temperatures, and make piping changes very easy by providing a drain, but measuring at its output is objectively the best place for absolutely fine coolant temperature control.

You are right, it is easier. It is not necessarily a problem however. It's that everyone was saying to use the reservoir when it is not even necessary in some cases. The same thing can be accomplished by only using bridges. It was also tough to get constructive criticism because everyone keeps posting their builds with valves and reservoirs which both overheat btw. There is a method to my madness. I also wanted to find the cheapest method available for micro builds. There is nothing wrong with using a reservoir, but I only need it if I need accurate temps. I haven't thought of a crazy use case yet, but the concept is there. maybe using a hot liquid as a coolant and heatsink, idk yet.

Spoiler

ya got me started :D

 

Link to comment
Share on other sites

20190928232236_1.thumb.jpg.a5d119dc5d15566d5b8a1dfca801ab91.jpg

I think this will de-bug power shutoffs with very minimal downtime, if at all.  I take the original automation signals that bug the power shutoffs and send them to 2 additional shutoffs.  This means they'll bug out when the other ones do.  They're wired up so the liquid shutoff always gets power from one of them, unless the bug occurs and sticks a shutoff closed when it should be open.  As long as the liquid shutoff has power, the pipe element sensor sends a green signal.  When the liquid shutoff loses power (due to the bug), water routes through the second bridge and the pipe element sensor has no water, so it then sends a red signal.  This signal change is almost instantaneous.  The automation signal from the pipe element sensor leads to two power shutoffs at the battery.  They're set up in a way to not impose function normally, but when the bug happens they cut the power to the consumers first and then open the power to the main line.  This will force the battery to charge and then make a red signal instead of green when it’s full enough.  The signal flop will fix the power shutoffs, which will instantly kick back on the liquid shutoff, which allow the setup to return to normal function.

Or, if the bug occurs when the smart battery is sending a red signal, the liquid shutoff’s power shutoffs will still block its power, and then the pipe element sensor sends a green signal to override it via the top left NOT gate.

I've messed with it in sandbox and it seems to function perfectly, but I didn't save/reload until the bug was invoked and make sure it actually restored function after the bug has occurred.  This assumes the bug occurs only with green signals.  I’ve seen some screenshots since I made the video which suggests that may not always be the case, but as I said in the video, I haven’t been able to reproduce a red signal bug in order to test it.

All gates are NOT gates and the signal switch is just to send a green signal to the shutoff, it could be a hydro sensor or whatever you want.  You could also use this for manually cutting power to your consumers if that’s something you want to do I guess.  Liquid shutoffs require power to run, but don’t actually draw power, so they’re ideal to hook into the main power line.

To prime the water loop, don’t construct the outer bridge, and then use the green part of a bridge on the liquid pipe sensor to fill the system while the liquid shutoff is on.  Finally, disconnect the filling bridge and build the right bridge.

Oh, also this is meant to be a demonstration of the concept; it shouldn't be considered an optimized layout or exact blueprint.

20190928232214_1.thumb.jpg.86f66e151bd64b01058448636608ff89.jpg20190928232222_1.thumb.jpg.6391c791d6760a0c50d646d2dc165986.jpg20190928232229_1.thumb.jpg.b39db783274a3ecab8def109b07aa5b4.jpg

Link to comment
Share on other sites

well, my post disappeared, here is a quick version of it. Snappiness = How fast the system can take effect

2 hours ago, biopon said:

but sir, that setup ended up being HUGE. 

Biopon's build sacrifices power for space and snappiness

My build sacrifices space for power and snappiness

The reason I did not consider the water clock in my final build was because it was not fast enough. The only speedy detectors I know of are the bin and the battery.  @Gamers Handbook's build looks like it could be condensed...a lot.

Link to comment
Share on other sites

@biopon@BLACKBERREST3

Yes, the build I showed can be condensed.  As stated, it is not an exact blueprint, but a proof of concept.  I prefer to showcase ideas in a more spacious and exploded layout so it is easier to follow and understand.  Once someone understands, they can recreate it in their base, taking into account their own personal size constraints.

Also, every automation wire I've observed that's had more than one power shutoff attached to it (without any automation gates between them) has always triggered every power shutoff on that line to bug together.

Link to comment
Share on other sites

3 hours ago, Gamers Handbook said:

Once someone understands, they can recreate it in their base, taking into account their own personal size constraints.

Agreed

3 hours ago, Gamers Handbook said:

Also, every automation wire I've observed that's had more than one power shutoff attached to it (without any automation gates between them) has always triggered every power shutoff on that line to bug together.

If you have the same number of gates between the wire and shutoffs, I believe the game calculates "ticks" the same way so they will both end up switching/pulsing at the same time anyway. I haven't practiced too much with 1-tick delays yet, but there could potentially be a way to take advantage of this in another battery switching build. The reason it did not work in my original build was because the load side could see the gen side for 1 tick which had the potential to overload the wires. biopon and nakomaru pointed this out to me. That is why I sync them with another gate now.

Link to comment
Share on other sites

Someone had commented on my bug video suggesting 2 NOT gates as a work around instead of 3, but it was for this very tick/delay reasoning that it didn't work (it allowed for overload damage for a split second).  The tick and delay stuff is a bit like magic to me still, so that's why my design here just straight up took the same signal.

Link to comment
Share on other sites

2 hours ago, Gamers Handbook said:

The tick and delay stuff is a bit like magic to me

If you want to add more to this thread, be my guest. It is magic as far as I'm concerned.

Spoiler

 

Uploading a vid that shows the snappiness between all three builds. @biopon @Gamers Handbook You guys might want to see this, stand by.

The results are that mine and biopon's build are identical. Handbook, your build is slightly slower, but still faster than my original clock build I think.

 

Did the shutoff just overload the wires? I thought it didn't consume power :shock:  It doesn't

I'd like to add that I don't think drain has to do with the speed of the smart battery. It seems to be a hard limit, probably from the timing of the automation wires themselves. So to explain another way, drawing 1kw vs 50kw won't change how fast the battery switches its automation signal.

Link to comment
Share on other sites

Nice testing!  That makes sense since my method is also using pipes.  You did have an extra water bubble or 2 in there (it shouldn't use the outside bridge unless the shutoff is closed), but idk if that would have sped it up any or not.

Most likely you were hot wired to the grid for a second and it chose to overload there?

In my experience when a battery decides it's time to send a signal it appears to be sent at the same speed every time.  Is that what you were getting at?

Link to comment
Share on other sites

33 minutes ago, Gamers Handbook said:

You did have an extra water bubble or 2 in there

I just tried removing 1 bubble from it, same results. 2 bubbles, it broke and kept alternating red/green with no change in speed. I don't know what I did wrong when setting it up :(

33 minutes ago, Gamers Handbook said:

Most likely you were hot wired to the grid for a second and it chose to overload there?

I just noticed I had 1 light too many on the system. I think that is what overloaded it.

33 minutes ago, Gamers Handbook said:

In my experience when a battery decides it's time to send a signal it appears to be sent at the same speed every time.  Is that what you were getting at?

Actually, I was referring to that and when it changes from 100 to 99 to send the signal. I didn't know if there were any extra mechanics in play or not like power draw. If you do not have anything consuming on the line, then the battery will fail to activate, but this does not matter as much because the consumers won't be without power anyways. What makes biopon's build unique is that it detects when there is no power on the line with impunity. This could be useful for future builds. You will have to sacrifice 60 watts though, but it is the only building that acts as a power on/off sensor with no downtime. The battery is more of a power difference sensor that can act with the same speed, but it cannot detect when power has been shutoff if nothing consumes from it. Apart from that, the battery has bias in that it loses power naturally unless it is constantly supplied by a transformer or generator. This natural loss will eventually activate the 99 signal.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...