MK-II-5-CARUC EA Breeder: 305eu/T eff 4.48

    MK-II-5-CARUC EA Breeder: 305eu/T eff 4.48


    http://www.talonfiremage.pwp.b…=1j1010101120101021e01r13


    Due to Constantly Applied Reusable Use Coolant, this reactor /actually/ is stable (4000 to 4500 +/-500) when the cooling system is functioning properly. No cooldown time is necessary. the reactor planner is trying to cool it down to 3000c instead of 4000c.


    I currently have this running on my SMP server; it uses 3 filters for the reactor complex. 1 filter for the sideload buffer of buckets for the pneumatic tube delays (My initial design has a /lot/ of room for optimization), 3 chests (2 for the sideload), dual deployer (to fill the buckets)/filter combos a filter to feed the reactor and a filter for pulling empty buckets that end up in the wrong place back out of the main buffer.


    In short: it uses 2 deployers and 6 filters. Everything is timed off of a single redpower timer with 0.2 pulse timing.


    The only problem I actually have with the current design is that buckets get kicked out in to the same space that the pneumatic tube feeds them in. I'm currently considering additional filters to suck them back in to the loop.

    What about picture of set-up?
    With overflow i solved problem easily with BC, just check my design, buckets constantly poping out of reactor, but not a single one lost.

    Here's the version that blew up because the buckets weren't getting around fast enough; I've revised the cooling loops further since then, but still want to make major changes.





    This is a close up of the changes I made since the first run; it restores a feature I took out because the filters got contaminated. I no longer care if they suck up a bucket to self-config. Instead they add in instant retry/spamming.



    I've since added filters symmetrically on the sides of the incoming pipe about where I was standing when I took this shot.


    This is an overhead shot I took when Q-boot jumping.


    So you posting about half finished design of breeder?
    Still not bad, but is it very stable?
    Also you may would want to post in other threads.
    Your reactor aren't the only one.
    Do you have working bucket return system if they overflowed?

    Bucket return is what's covered in picture 2, and stage 2 of overflow return is covered in the third picture. (filenames 1 and 2 respectively; start counting at 0.)


    The reactor is only able to throw the buckets out of the face with the pipe, so the two filters cover the buckets that collect at the bottom of the containment area and on top of the pipe.


    Stage 2 collection nabs the buckets it manages to fling in to the cube of pipe that goes through the vessel wall. That's the two filters outside.


    Ejected buckets are sent /immediately/ back to the reactor thanks to the smart pipes of RP2 (it's the shortest valid destination).

    Sounds like a good idea then. But what if reactor don't have slot open for bucket, where then buckets go from filters which picking up buckets?

    It endlessly cycles. This is the alpha version of my design. JUST enough to test it to make sure the concept works. Zero built in safety features of any kind; sub-optimal component placement. It's also to teach me about the various quirks of actually building it.


    Now I know what I want to do with it. Next comes optimizing the layout of the parts, and then switching from a completely open control loop to a closed loop (counting out-coming buckets and making decisions). However doing that would tune the design to a specific configuration.


    If I did tune it, I'd probably sacrifice a little short term efficiency and go for this:
    http://www.talonfiremage.pwp.b…=1i1010101120101021e01r19


    It has an /exact/ excess heat of 2 buckets per second. This means I can get it up to whatever temperature I like and then breed there with stability. However I'd want to use a completely dedicated timer for the insertion and constantly keep everything else ready. One-mis-fire and that system /would/ blow. I don't think I'd do that until the 'empty row rejection' issue is solved one way or another. Of course that might also change the design I consider 'optimal'.

    Slightly modified the design of both the reactor enclosure and the inner layout to achieve a net heat excess of 1000/second. (which is /exactly/ two buckets)
    http://www.talonfiremage.pwp.b…=171110101120101021e01r19


    335 eU/t
    4.35 Eff
    Bloody dangerous when the user is pressing buttons; stable otherwise. Breeding at 9000-11900C (maximum temp before bad things happen); fails cooler when isotope cells recharge and no longer uranium pulse.


    Edit:
    I forgot to mention: uses two clocks (0.2 and 0.5; bucket fill / bucket inject respectively), and one AND gate; there are also a large number of glass panels doing things like keeping wires from joining and water from flowing out.



    I also modified my layout to include a uranium tick hold switch; an incoming bucket hold switch (I've blown my self up twice when it was a pressure plate; is there a zero-stickiness button between minecraft and RP2?); an incoming bucket maximum rate switch (more later), and a bucket-prestage clock hold switch.


    As you can see there's also an overflow loop back to the side chest, and a pre-fill loop for anything you want tossed in just as the reactor starts (it's filter is empty); this can be used for lava buckets as well as water-buckets (if you wanted to disable the incoming, but send through a fixed number in to an overheated reactor that was otherwise uranium paused).



    With the above explanation, here's the set of pictures.