I don't care about biters, but sometimes one has to move some power poles, causing a temporal outages while the construction work lasts, or accidentially disconnects the last line ;). So rephrase: Will it just overstock (which would be my guess from the pictures)? Because some designs need to be manually(*gasp*) fixed after power failures.disentius wrote: ↑Sun Oct 14, 2018 9:59 am not tested. it's a counter: it will break:)
Modded version uses Optera's inventory scanner. That one will probably survive, i will test it
I never play with biters anymore, and overpowerproducing is my default.
Every (vanilla) kovarex which uses combinators to reduce U235 loading will break in case of power loss. Solution: dont use counter.
You can remove all counters from my setup, and it will work. Takes a lot longer to get output, but if possible power loss is part of your play style, essential.
Self adjusting Kovarex based on demand
-
eradicator
- Smart Inserter
- Posts: 5207
- Joined: Tue Jul 12, 2016 9:03 am
- Contact:
Re: Self adjusting Kovarex based on demand
Author of: Belt Planner, Hand Crank Generator, Screenshot Maker, /sudo and more.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.
Re: Self adjusting Kovarex based on demand
Ok my take:
1 tile wider than disentius but no combinators what mean it should be power loss resistant and also its u238 loss resistant.
After test it seems like u-238 need to be placed only on right side of belt (it goes from up to down so on picture it will be on left side). Easy to solve with some chests inserters and wire.
Edit - Ok i make on left side chest and inserters so no problems anymore, blueprint updated but not picture.
I also make it lock resistant if u-235 overproduce itself
1 u235 for 12 ssec if inserters stack at least 11
1 tile wider than disentius but no combinators what mean it should be power loss resistant and also its u238 loss resistant.
blueprint
And yes its need 40 x u235 to start and its need to be done by hand. It will filter this one u235 produced from internal load/unload 235 system. Maybe it can be adjusted somehow i will check it out.After test it seems like u-238 need to be placed only on right side of belt (it goes from up to down so on picture it will be on left side). Easy to solve with some chests inserters and wire.
Edit - Ok i make on left side chest and inserters so no problems anymore, blueprint updated but not picture.
I also make it lock resistant if u-235 overproduce itself
1 u235 for 12 ssec if inserters stack at least 11
- Attachments
-
- kovarex.png (481.7 KiB) Viewed 7558 times
Re: Self adjusting Kovarex based on demand
Thanks for catching my sloppyness colonel:)
- Ill review/repair my blueprint asap.
And yes: mine is a late game design, for use with - at least- stack inserter bonus 6.
Should be no problem: for kovarex research all science packs except space science are needed, stack inserter bonus 6 needs 4: red, green, blue, purple.
counter-based limiting will work with any stack bonus you can set to a divider of 40, e.g. 2 4 5 8 or 10.
- Ill review/repair my blueprint asap.
And yes: mine is a late game design, for use with - at least- stack inserter bonus 6.
Should be no problem: for kovarex research all science packs except space science are needed, stack inserter bonus 6 needs 4: red, green, blue, purple.
counter-based limiting will work with any stack bonus you can set to a divider of 40, e.g. 2 4 5 8 or 10.
-
ColonelSandersLite
- Fast Inserter
- Posts: 208
- Joined: Tue Apr 24, 2018 5:42 am
- Contact:
Re: Self adjusting Kovarex based on demand
eradicator wrote: ↑Mon Oct 15, 2018 10:21 amI don't care about biters, but sometimes one has to move some power poles, causing a temporal outages while the construction work lasts, or accidentially disconnects the last linedisentius wrote: ↑Sun Oct 14, 2018 9:59 am not tested. it's a counter: it will break:)
Modded version uses Optera's inventory scanner. That one will probably survive, i will test it
I never play with biters anymore, and overpowerproducing is my default.
Every (vanilla) kovarex which uses combinators to reduce U235 loading will break in case of power loss. Solution: dont use counter.
You can remove all counters from my setup, and it will work. Takes a lot longer to get output, but if possible power loss is part of your play style, essential.. So rephrase: Will it just overstock (which would be my guess from the pictures)? Because some designs need to be manually(*gasp*) fixed after power failures.
As I said, a counter doesn't break on a power cut, only a low power situation. What *can* break is when everything requiring power stops functioning while everything that doesn't require power (belts) just keeps going.
In Disentius's design, what can happen is:
Inserter is taking 235 out of the centrifuge and puts some on the belt.
After two (or more) pieces of 235 go on the belt but before the next inserter picks any up, The power is cut.
The 235 keeps going down the belt past the inserter that puts the 235 back in the centrifuge.
Power comes back on.
This leaves the centrifuge without enough 235 to keep going. If there is not enough room for the uranium refining to produce more 235, this will jam that centrifuge, until the uranium refining can produce more.
Both my design and the tweaks I made to Disentius's design prevent this problem. If you want to examine behavior closely, in the demo of my design, it actually automatically cuts power when production backs up, as it does in my actual factory. This causes no issues.
Re: Self adjusting Kovarex based on demand
Well. All the above gave me some design goals:
- Modular
- Fully beaconed
- Filling evenly
- Not affected by low power
-EDIT: and not affected by power loss (total)
- No maintenance required
So, NO combinators. Belt-belt, and belt-inserter logic seems unaffected by low power though.
I came up with this concept:
Inputs: bottom-right. (top belt: U235)
Outputs: Bottom-left. Excess U238 gets routed through. Use backpressure on output U235 to stop/throttle the production.
Side effect: Stop the input of U238, and it spews out most of its hoarded U235.
It takes about 40 minutes factorio time to fill all the centrifuges, but once filled. production startsreally fairly quick.
Can be scaled to anything you want: 1:1 to whatever (well... a lot anyway). this one is 5:5 because i like a neat substation grid.
Test and shoot, please:)
- Modular
- Fully beaconed
- Filling evenly
- Not affected by low power
-EDIT: and not affected by power loss (total)
- No maintenance required
So, NO combinators. Belt-belt, and belt-inserter logic seems unaffected by low power though.
I came up with this concept:
Inputs: bottom-right. (top belt: U235)
Outputs: Bottom-left. Excess U238 gets routed through. Use backpressure on output U235 to stop/throttle the production.
Side effect: Stop the input of U238, and it spews out most of its hoarded U235.
It takes about 40 minutes factorio time to fill all the centrifuges, but once filled. production starts
Can be scaled to anything you want: 1:1 to whatever (well... a lot anyway). this one is 5:5 because i like a neat substation grid.
Test and shoot, please:)
- No-combinator Kovarex.PNG (3.08 MiB) Viewed 7477 times
Re: Self adjusting Kovarex based on demand
I prefer having count perfect amounts of u235 in a kovarex centrifuge, so I use a combinator to count 40 u235 for priming.
During normal operation the belts and fast inserter feeding u235 and combinator can be deconstructed.
During normal operation the belts and fast inserter feeding u235 and combinator can be deconstructed.
- centrifuges only fill to the required 40 u235
- only 1 excess u235 per cycle leaves the internal centrifuge cycle
- fully beaconed
- modular in width and length
modules longer than 5 centrifuges may require splitters or even blue belt output so priming won't backlog centrifuge outputs - self priming
- priming setup can safely be removed
- 2018-10-25-11-37-50-5299086.png (2.64 MiB) Viewed 7430 times
My Mods: mods.factorio.com
Re: Self adjusting Kovarex based on demand
I agree with count perfect. Nice build!
ColonelSandersLite and eradicator pointed out that anything with combinators breaks down in a less than 100% power situation, requiring a power switch contraption checking for power fluctuations, or make a no combinator one.
I wondered if that could be done fully beaconed, above is my result.
ColonelSandersLite and eradicator pointed out that anything with combinators breaks down in a less than 100% power situation, requiring a power switch contraption checking for power fluctuations, or make a no combinator one.
I wondered if that could be done fully beaconed, above is my result.
Re: Self adjusting Kovarex based on demand
The combinator is only used for priming. After that's done it will work through brownouts and blackouts as far as I've observed. The whole priming feed including the combinator can even be deconstructed to save ups.
In my opinion if you run this insane production for u235 while having brownout problems you have your priorities wrong.
In my opinion if you run this insane production for u235 while having brownout problems you have your priorities wrong.
My Mods: mods.factorio.com
Re: Self adjusting Kovarex based on demand
This thread got me to finally spiff up my own Kovarex Inception rig to use chests not belts for reload, it now gets 647 ticks/cycle vs the 768 ticks for belts, so it takes minutes less to get from your 40th U-235 to youir 120th. Also it's more compact because I have a fetish for that. I'm happy enough with the setup and overall efficiency, plug in your ore-processing output belt, sink the unused U-238 into ammo production or however you like, and walk away, that I've immodestly named it The Lazy Bastard's Kovarex Inception Blueprint:
Everything inside the beacon box is tilable/zigzaggable, everything outside the beacon box that isn't blue is test/demo rigging, the blue stuff is source/sink and the usual belt ballet.
Designs for use after there's enough to make reloading delays best dealt with by buffering an extra 40 U-235/centrifuge are a different beast altogether, I don't use enough to make permanent speed beaconing worth considering for my bases.
- snap@T13607492=1520x2480+231.75-145,z2.jpg (271.89 KiB) Viewed 7387 times
Everything inside the beacon box is tilable/zigzaggable, everything outside the beacon box that isn't blue is test/demo rigging, the blue stuff is source/sink and the usual belt ballet.
Designs for use after there's enough to make reloading delays best dealt with by buffering an extra 40 U-235/centrifuge are a different beast altogether, I don't use enough to make permanent speed beaconing worth considering for my bases.
Re: Self adjusting Kovarex based on demand
I'm not sure if I understand the intention of this thread correctly,
adjusting your production to demand seems trivial using circuits and a logistics network,
like, only make more if there is less than x total in the system.
Or did I miss something?
Also, I'd always recommend circular enrichment setups for their simplicity and efficiency, like ... one I did here a long time ago...^^
adjusting your production to demand seems trivial using circuits and a logistics network,
like, only make more if there is less than x total in the system.
Or did I miss something?
Also, I'd always recommend circular enrichment setups for their simplicity and efficiency, like ... one I did here a long time ago...^^
Re: Self adjusting Kovarex based on demand
@quyxkh: oooYesss!
This is the one. (except alignment on a substation grid, which is kind of my fetish atm:)
Thanks!
This is the one. (except alignment on a substation grid, which is kind of my fetish atm:)
Thanks!
Re: Self adjusting Kovarex based on demand
Just words to express my appreciation for the encouragement seemed a bit weak, so I figured I'd see if I could find further squishification for you. I'm a little surprised to report success:
- snap@T16342218=2224x1232+283.25-115.25,z2.jpg (215.08 KiB) Viewed 7300 times
Thanks for the encouragement.
Re: Self adjusting Kovarex based on demand
I think that if you need more than one centrifuge with beacons then you really don't need count perfect operations. So have a single centrifuge design with combinators for count perfect startup. And another design for a beaconed array.
Also you want the centrifuges to run non-stop and that means pre-loading them for the next cycle. Which of the combinator setups does that?
Also you want the centrifuges to run non-stop and that means pre-loading them for the next cycle. Which of the combinator setups does that?
-
zOldBulldog
- Smart Inserter
- Posts: 1161
- Joined: Sat Mar 17, 2018 1:20 pm
- Contact:
Re: Self adjusting Kovarex based on demand
The discussion on the thread has been so interesting that I largely pulled back and just read while I let the concepts mature. I even postponed building my "optimal Kovarex setup" because the concepts keep evolving.mrvn wrote: ↑Mon Oct 29, 2018 10:29 am I think that if you need more than one centrifuge with beacons then you really don't need count perfect operations. So have a single centrifuge design with combinators for count perfect startup. And another design for a beaconed array.
Also you want the centrifuges to run non-stop and that means pre-loading them for the next cycle. Which of the combinator setups does that?
But thoughts similar to those you mentioned in this post have been rolling in the back of my mind. For example:
- in the first stage (getting the first 40 u235) for the first centrifuge you clearly want to send all u235 to the same centrifuge.
- once you achieve the first 40 for one centrifuge the next goal is to keep only 40 on each centrifuge and send the excess to the next one so that it can reach 40 itself and move on to the next.
- once all of them reached 40, priorities change and count perfection and combinator become irrelevant.
Your thought of one combinator setup for count perfect startup and one for a large beaconed array sounds right.
The only uncertainty that remains in my mind is... One or more than one centrifuge for that startup, since we need to fill N centrifuges with 40 each??
Re: Self adjusting Kovarex based on demand
Maybe you missed "Designs for use after there's enough to make reloading delays best dealt with by buffering an extra 40 U-235/centrifuge are a different beast altogether."?
The way I see it, speed-beaconed designs are for reducing the wait for full production, the time between when your 40th '235 arrives and your line's up and running. How fast can your favorite un-combinatored setup take you there?
Of course, the guys who want to light off atom bombs without counting the cost probably see it a bit differently.
Eight E1'd centrifuges in a ring around an E1 beacon has been much more than just "enough" for me and really tests the reload-delay assertion, I just realized I never bothered with more than the startup 8×40 and I get >7/min, that would feed almost 30GW. The ring-reload stunt cuts the reload delay down under a second, so buffering would get a whopping 1.5% improvement. Yay for count-perfect designs!
... and, seriously, some people just like goosing designs for maximum performance by various metrics. I do it for fun. I know I like efficiency way too much. I suspect just about everybody but me snorts at the idea of E1'd centrifuges, let alone E1-beaconed centrifuges. Tell the truth, I snort a little at the idea. It's amusing. Thing is, that design's the cheapest to build and most efficient to run by every metric I can find, its worst downside is a cost of (gasp!) 42 extra active entities for the map, total. Is making slicker designs not part of the fun? For me it's almost all the fun, I spend much more time in lab maps than my real ones these days.
edit: but, to answer your question:
all of them. Change one constant, run down the line once and walk away. they now buffer 80 per centrifuge.Also you want the centrifuges to run non-stop and that means pre-loading them for the next cycle. Which of the combinator setups does that?
Re: Self adjusting Kovarex based on demand
What I'm saying is that at the start you don't have an extra 40 U-235 to run even a second centrifuge or to buffer. So you want count perfect operations so every U-235 you can take out of the loop you get out of the loop. That's so you can produce your second set of 40 U-235. By all means beacon the hell out of it if you can spare the beacons at that time of the game.
Once you have 80 U-235 you can duplicate the setup to run 2 centrifuges to double your bootstrap speed if you want.
But after bootstrapping doing a double recipe buffer is more efficient, even if it's just 1.5% more efficient. So I guess the ideal setup would be something that starts off with count perfect 40 U-235 per centrifuge. Then once all centrifuges have 40 U-235 slowly increase that centrifuge by centrifuge to 80 U-235 per centrifuge so all centrifuges in the array are constantly running.
Once you have 80 U-235 you can duplicate the setup to run 2 centrifuges to double your bootstrap speed if you want.
But after bootstrapping doing a double recipe buffer is more efficient, even if it's just 1.5% more efficient. So I guess the ideal setup would be something that starts off with count perfect 40 U-235 per centrifuge. Then once all centrifuges have 40 U-235 slowly increase that centrifuge by centrifuge to 80 U-235 per centrifuge so all centrifuges in the array are constantly running.
Re: Self adjusting Kovarex based on demand
I'm with q on this one.
I regard the "priming" stage as getting all centrifuges filled, either with 80 or 40 U235, choose your preference.
This is possible with both optera's and quixkh's designs. after that, its simply enable or disable the production for immediate full production.
(and also spending most of my time with interesting design challenges)
I regard the "priming" stage as getting all centrifuges filled, either with 80 or 40 U235, choose your preference.
This is possible with both optera's and quixkh's designs. after that, its simply enable or disable the production for immediate full production.
(and also spending most of my time with interesting design challenges)
Re: Self adjusting Kovarex based on demand
I found the idle times in my count perfect design annoying too.mrvn wrote: ↑Mon Oct 29, 2018 1:20 pm What I'm saying is that at the start you don't have an extra 40 U-235 to run even a second centrifuge or to buffer. So you want count perfect operations so every U-235 you can take out of the loop you get out of the loop. That's so you can produce your second set of 40 U-235. By all means beacon the hell out of it if you can spare the beacons at that time of the game.
Once you have 80 U-235 you can duplicate the setup to run 2 centrifuges to double your bootstrap speed if you want.
But after bootstrapping doing a double recipe buffer is more efficient, even if it's just 1.5% more efficient. So I guess the ideal setup would be something that starts off with count perfect 40 U-235 per centrifuge. Then once all centrifuges have 40 U-235 slowly increase that centrifuge by centrifuge to 80 U-235 per centrifuge so all centrifuges in the array are constantly running.
But the fix is simple, change the inserter to u235 <= 80, input to u235 < 400 and output to u235 >= 400.
This can be done at any time, fill to 40 first then up to 80 later when there's more u235.
Originally I was running 24 centrifuges with efficiency modules. This topic made me rethink that approach.
I now run 9 fully beaconed centrifuges cycling 80 u235 each, which saves 240 u235 from cycling, while also producing way more than I'd need unless I get really trigger happy with nukes so most of the time it's input starved and powered down to save ups and power.
My Mods: mods.factorio.com
Re: Self adjusting Kovarex based on demand
Rseding91 says: no power switch is not a good ups saver, as i understand it. forcing idle is much better.
Is this still true?
Is this still true?
viewtopic.php?f=6&t=40107&hilit=ups#p237875by Rseding91 » 19 Jan 2017 19:55
"Powering down" things is one of the worse ways you can stop a factory. Simply not giving it any resources to consume/use is the ideal way.
The problem is: "powering down" an entity means the normal update logic on the entity can't run because there's no power to do things like "move the inserter arm". The entity has no update notification when power is restored so it can't disable itself.
Adding such a notification would be a gigantic waste of CPU time because 99% + of the time the entity has power or will have power next tick.
Re: Self adjusting Kovarex based on demand
We should test if starving input so entities enter disabled state and then powering them off allows them to remain in disabled state.disentius wrote: ↑Tue Oct 30, 2018 2:01 pm Rseding91 says: no power switch is not a good ups saver, as i understand it. forcing idle is much better.
Is this still true?
viewtopic.php?f=6&t=40107&hilit=ups#p237875by Rseding91 » 19 Jan 2017 19:55
"Powering down" things is one of the worse ways you can stop a factory. Simply not giving it any resources to consume/use is the ideal way.
The problem is: "powering down" an entity means the normal update logic on the entity can't run because there's no power to do things like "move the inserter arm". The entity has no update notification when power is restored so it can't disable itself.
Adding such a notification would be a gigantic waste of CPU time because 99% + of the time the entity has power or will have power next tick.
That way we could save up and power.
My Mods: mods.factorio.com