need help with CASUC advanced design

  • Greetings IC engineers


    I was working on a CASUC reactor for some days. However I am encountering some problems associated with redstone engines by extraction pipe. Basically the reactor is designed to support 6 (I have some plans on boosting it to 8 or 10 later on) buckets/tick flow in and out of chamber. As far as I know 6-bucket flow is supposed to be more than enough to keep at least 28 :Uranium Cell: cold (isn't it?) it doesn't seem to be a sufficient measure for some reason. You can easily see empty buckets removed not fast enough. Redstone engines are kept out of sync, but they are always on 'blue' temperature. If I heat them up on constant signal and then switch to pulse they cool down quickly, in other words I can't accumulate any heat on them. What am I doing wrong? How do you achieve better bucket flow with 4 buckets/tick than me with 6?


    My project is based on Irontygre's ingenious design, which is based on everyone else's design, so it is pretty much inspired by all CASUCs here. Compared to his design I improved flow rate, safety, introduced further compression, removed some bucket leaks and made it largely invulnerable to reloging. Due to mass request I received some time, my reactor is not dependent on RP and does not involve lag-intensive redstone engine powering towers. Main objective I wanted to achieve with it is dirt-house-compatible size while still being a monster CASUC. I think it would be worth being posted here, if not the issue with cooling.


    I can't move any forward without your expertise.

  • Interesting! If I understand correctly, the main issue is that the redstone engine desynchronizer isn't working correctly? May I ask what addons and/or circuitry you're using for the task?

  • Interesting! If I understand correctly, the main issue is that the redstone engine desynchronizer isn't working correctly? May I ask what addons and/or circuitry you're using for the task?

    Desynchronizer is working properly, mine is a little messy setup as tick periods between different engine pulses are not perfectly equal, but that should not be an issue. I left your extraction setup unchanged so far. 2 x three redstone engines on opposite sides and it can't even provide sufficient cooling for 21 fuel cells, which you could hardly consider an improvement :S
    What I meant is while looking inside the reactor I can see empty buckets stacking up, not being extracted fast enough to make space for full ones, therefore temperature rises. I can hardly come up with any idea why such deficit takes place, other than engines working on blue temperature. Are they meant to keep red/green state?
    I am certain this is not bucket deficit, since I made it so your design works at full efficiency with 28 buckets circulating (seriously) while being able to accommodate around 250. The problem lies in extraction.
    If you and anyone else will be unable to reveal the flaw I will have to upload the world for you guys to see, but I'd hate to do that since uploading not working reactor sounds like shameful practice :/


    EDIT: Ah yes, for this design I used: IC2, BC, Zeldo's AP, Pigalot's Bucket Filler, Energy converter addon, Thermometer addon.
    The desynchronizer is a little complex pulser with period of 8 ticks (it takes 8 ticks for same redstone wire to flash again) with cascade piston autoreset. I just planned for working desync, so its messy enough for different phases to be active for different periods of time + 2 out of 3 (wires/engines) are always active at a given time (you would have to see that, I myself am not perfectly sure how it's working). Can it screw up engines somehow?

  • At 8 ticks your desynchronizer pulses are hitting much to quickly. You'll note that in my setup I have my RP2 sequencer set to 2.6 seconds per pulse, which means each engine actually gets a desynchronization every 10.4 seconds. Much faster than about 9 seconds per desynch pulse and the engines lose core temperature.


    And to answer your other question ... yes my design requres the redstone engines to be running bright red (maroon red is bad, because all engines automatically synch when they get that hot).

  • You've done all that, and you haven't yet tried RedPower2 tubes

    There are people who find large number of mods involved a huge negative point, as it reduces compatibility (my smp already stopped working in half of development of this reactor, but that's different story). Also, everything in RP can be made via traditional redstone circuits and what is more important RP is told to have some bugs with more advanced circuits and not to be compatible with software like MCEdit. Am I wrong?
    Also Eloraam's imperialistic ambitions aren't doing very good publicity for RP as well.

    At 8 ticks your desynchronizer pulses are hitting much to quickly. You'll note that in my setup I have my RP2 sequencer set to 2.6 seconds per pulse, which means each engine actually gets a desynchronization every 10.4 seconds. Much faster than about 9 seconds per desynch pulse and the engines lose core temperature.


    And to answer your other question ... yes my design requres the redstone engines to be running bright red (maroon red is bad, because all engines automatically synch when they get that hot).

    So what you are saying is that BC has some code that makes engines cool down if supplied with high frequency redstone signal?
    I should be able to reproduce that in traditional circuitry, but I don't perfectly understand your approach. Are you running it like this: an engine is fed with positive signal for 7.8 seconds after what it gets 2.6 seconds of negative signal. Isn't 2.6 seconds too long? Won't it affect extracting efficiency?
    Why do you have 4 phases? 10.4 / 2.6 = 4
    Shouldn't it go like: 2 engines on, 1 off and they cycle? Gives you 3 * 2.6 = 7.8
    And how do you know it's not cooling your engines? What if they go blue after 4 hours for example?
    Is it optimal or just first working try? Can't you desync them with something like that: 1 negative tick per 100 ticks (10 seconds)?


    In fact we don't even need to desync the engines, just like you said we only need to prevent them from going into red-flashing state. Just initially they need to be placed out of sync (will reloging break desync?). Did anyone specify conditions for this? The rarest possible anti-tick, 1 tick per 20 positive ticks, 100 ticks, 1000 ticks?


    I sort of realised the flaw of my build, it's just the flasher which has desynchronisation as its side effect. I need an engine cooling signal.


    If what I understood from what you said is correct then it should be technically possible to create up to 24 bucket/tick circulation system with your design, which you can actually trade for 12 bucket/tick + regaining the 5th chamber. Just imagine the efficiency, this sounds fantastic (900eu/t zomg?).

  • So what you are saying is that BC has some code that makes engines cool down if supplied with high frequency redstone signal?


    Well, there's no need for special code for the high frequency case, but yes ... redstone engines tend to stay cold if driven with a high frequency signal.


    Ok, so the reason I use a sequencer is so that when a desynchronization pulse is sent, it is sent at different times to each of up to four engines working any given extraction pipe. The way my circuitry is set up, they receive a negative pulse of length 1 tick every 10.4 seconds (So effectively a signal that is on for 207 ticks, and off for 1 tick). I know this does not cool down after several hours for many reasons. One, I've conducted overnight tests on the system to see if it is stable. Two, the engines actually heat up to a bright red equilibrium from start.


    I don't know for certain if it's optimal, but I'm pretty sure it's darn close. The engines stay desynchronized, and operate at about as high a temperature they can before I run into synchronization issues. I was unable to get 4 redstone engines to operate at an extraction rate of 12 buckets / second, and I don't think it's even theoretically possible to get them past 4 buckets / second. But if you can do it, I'd be very interested to see how you managed it ... and with your permission integrate it into a Rev. C.


    Also, I will note that the engines DO need to be desynchronized. Even blue state engines that are perfectly synched will not extract buckets properly.

  • Alright, I understand the concept now. Thank you sensei.


    But: you are applying one negative tick per 10.4 sec (104 ticks? wiki says 1 tick = 0.1 sec, no?) to keep them desynchronized, because BC notices one-tick delay on an engine and ejects another bucket? Or is it because you are just preventing overheating?
    What exactly I mean by the above; in the situation when the engines are placed under constant signal completely synchronised and then you turn sequencer on and it sends first 3 negative ticks (20.9 sec passes). Will it make them desynchronised? Or do you need to pick the engines up and then place them again under signal with sequencer on?


    I had an idea about high volume bucket flow based on what my friend showed me some time ago. Engines in series <]<]<] keep the desynchronisation and I am nearly sure the power gets transmitted instantly through previous engines without waiting for their pulses. If this is correct you can power extraction pipe with up to 104 redstone engines (104 ticks?). I am not very familiar with BC so I don't know if heat generation works similarly in this situation. It might require more frequent negative ticks or something.


    About your design: somewhat more than a week ago I explored it and then recreated from nothing to be sure about detailed mechanisms. Changes I introduced weren't really much about getting rid of RP, but rather about some other concepts. Although I am perfectly sure my first recreation of your design was working exactly in the same way as yours I might be wrong. Due to either of reasons there were flaws. Big ones - the ones you would call lethal to reactor. Bucket leaks in numerous places: bucket fillers' inlets, reactor inlets (double leak, still working on second one since buckets are getting shot in crazy surrealistic way) + infrequent leak by random buffer chest. Aside from that I got an impression your design supports only 4 bucket/tick flow instead of desired 6, because of presence of only 4 chests (1 chest = 1 redstone engine = 1 bucket/tick at inlet, you got 4 chests). There were other issues. If you like to design cooperatively, I am looking forward to discussing them with you, as I am aware I might have misdiagnosed some.


    I welcome posting my reactor as continuation to your reactor design, but it would be appropriate to make a new 'co-design' thread, as many things changed and reactor is likely to have different specs and different list of mods involved (Btw, do you insist on RP? I would prefer not to use it unless absolutely necessary and unavoidable).

  • Quote

    But: you are applying one negative tick per 10.4 sec (104 ticks? wiki says 1 tick = 0.1 sec, no?) to keep them desynchronized, because BC notices one-tick delay on an engine and ejects another bucket? Or is it because you are just preventing overheating?

    I'll go ahead and field this one, the reason for the desynchronization pulse is to do just that, keep the redstone engines out of sync with each other. If the engines sync up then it doesn't matter how many engines you have hooked up to a wooden pipe as they'll all hit at the same time and only extract 1 item (instead of a number of items extracted = the number of engines connected to the pipe).


    This was the problem I had when I tried bucket reactors w/ buildcraft. I haven't tried a desynchronization circuit myself, but it seems like it would work.

  • AkhkharuXul is absolutely correct. The pulses are for desynchronization and not to prevent engine overheat. Actually, loss of heat from the desynchronization pulses is an unfortunate and unwanted side-effect, which is why I tuned my system to send out pulses as infrequently as possible. Having all the engines hooked up to the same pulse generator is useless, since while they may not overheat in that situation, they stay synchronized (hence the use of an RP2 sequencer).


    As for chaining engines together ... I found that in my experiments chaining does not increase bucket extraction rate. Please, if you could, have your friend give you or upload a world file where this phenomenon is observable. Of course, there's the other issue that driving a redstone engine with another 140 engines behind it is going to cause a bunch of your engines to explode anyway.


    To answer your question about adding more than four inflow pumps. The reason there's only four is because even a nearly full 5 chamber reactor with 40 Uranium cells only outputs 1740 heat / second. There's no need for more than four inflow pumps since each can supply about 500 heat / second in cooling.


    On the bucket loss subject ... BuildCraft is 'leaky' compared to RP2 pneumatics. You absolutely MUST use Obsidian vacuum pipes to recover leaks and losses. The vacuum design is going to be dependent on each individual configuration. If you don't use the reference design *exactly*, then the vacuum recovery system will have to be redesigned from the ground up to match whatever design modifications you make.


    Due to the circuit complexity involved in making the sequencer work, my friend and I who are going to use this reactor in our SMP server are not going to be removing RP2 logic from our mod stack (There's simply no room in our base to install the redstone circuitry required to replicate the circuits we have built using RP2 logic). However, I'd be more than happy to give you periodic tips and pointers on how to get your own design off the ground and working without RP2 alltogether. I'm a strong believer in more options and competing designs!

  • Actually, having all engines hooked up to the same pulse generator would work just as well as having 3 delayed signals. You would just need to place them in different order. First - circuitry being online and then engines. Since it isn't possible for you to place all 3 engines during one tick (can you click that fast? xD ), they are going to be innitialy desynchronised and pulse should prevent them from going into flashy red mode when they all synchronise. The question is whether reloging will force engines into synchronisation in such setup and it probably will. Therefore this cannot be realisticly applied, so your exact answers are likely to be optimal solutions. And this is what I meant in my question.


    A person who showed me chained engines didn't obviously do that on reactor, since reactors used to be just uranium-refining boxes before. He no longer runs technological mods but I should be able to recover the world.


    About bucket leaks, they should be prevented without use of obsidian pipes, since they add many additional pipe-branches, need to be powered and take much space. More flexible and bucket efficient solution would be to install loops or bouncers or any other item flow containing units. Have you tried that Irontygre? A loop taking 2 more blocks than straight pipe patched leak by the inlet of bucket filler pretty well.

  • Actually, having all engines hooked up to the same pulse generator would work just as well as having 3 delayed signals. You would just need to place them in different order. First - circuitry being online and then engines. Since it isn't possible for you to place all 3 engines during one tick (can you click that fast? xD ), they are going to be innitialy desynchronised and pulse should prevent them from going into flashy red mode when they all synchronise. The question is whether reloging will force engines into synchronisation in such setup and it probably will. Therefore this cannot be realisticly applied, so your exact answers are likely to be optimal solutions. And this is what I meant in my question.

    I'm not sure if reloading can sync them up, but I know the last time I played with a BC reactor, I had 6 redstone engines connected to 2 separate advanced wooden pipes and was only getting 2 buckets / sec (cos they all synced up). but then upon reloading one of the engines on one side got slightly out of sync so one side would pull 1 bucket / sec and the other bucket would pull 2 buckets / sec. It's stayed that way ever since though... [and obviously by sec I mean "however often redstone engines preform work when they're fluctuating between orange/red"]


    I think the BC engines are too finicky to run without some sort of desync circuit.

  • I'm not sure if reloading can sync them up, but I know the last time I played with a BC reactor, I had 6 redstone engines connected to 2 separate advanced wooden pipes and was only getting 2 buckets / sec (cos they all synced up). but then upon reloading one of the engines on one side got slightly out of sync so one side would pull 1 bucket / sec and the other bucket would pull 2 buckets / sec. It's stayed that way ever since though... [and obviously by sec I mean "however often redstone engines preform work when they're fluctuating between orange/red"]


    I think the BC engines are too finicky to run without some sort of desync circuit.

    I perfectly agree with you.


    Do you people know detailed mechanics of RP integrated circuits (sequencers, etc.), are they like repeaters - subjects to getting 'stuck' after reloging? And how do you expect your reactors to get implemented by random mortal if RP is not pasted properly by world editing software (or is it already?).

  • I don't think you can effectively /edit/ the data, but I do think it's possible to store and load in the same orientation.

  • I perfectly agree with you.


    Do you people know detailed mechanics of RP integrated circuits (sequencers, etc.), are they like repeaters - subjects to getting 'stuck' after reloging? And how do you expect your reactors to get implemented by random mortal if RP is not pasted properly by world editing software (or is it already?).

    If you're talking about vanilla repeaters then no, they don't get stuck. Timers and sequencers are far better then vanilla circuits in lots of ways :)


    There supposedly are some issues with redpower 2 and servers where things will stop working (but I'm not sure exactly which things get broken, might just be machines).


    As far as loading schematics, I'm pretty sure they work as long as the circuitry isn't active (rapidly changing state) when the schematic is taken. [Though I could be wrong on this, and I'm not sure how it works with sequencers, I'm not a big fan of MCEdit so I try to use it as little as possible.]

  • Just a little note unless you use detector pipes (Additional Pipes addon for BC) or RP2's tubes.
    You should use combustion engines for extraction even though it may seem wasteful. Stone engines are difficult to maintain and redstone engines (while they should be doing exactly one rev per second) aren't doing one rev per second.
    Alternatively there's the BC->IC2 crossover addon that introduces electric engines, though they will waste some EU's (my current setup uses a pretty constant 50 EU/t)


    But that isn't the reason i posted though... Detector pipes! Here's how you make one with just BC!
    Place a wooden pressure plate and a dead end pipe so that any buckets fall onto the pressure plate. When the plate is activated use an obsidian pipe and a redstone engine to suck the buckets into the cooling system and send them on their way.
    Use the same signal to activate your extraction engines. They desync on every coolant batch! (Hence another reason why you should be using petrol engines as they are faster than 1 second per revolution)
    Alternatively, make your detector system only desync your redstone engines every 10 or Xth coolant batch using a counter. (That is a bunch of T-Flip Flops)


    Note that you have to set up several detector lanes because the pressure plates stay on for longer than 1 second. Switching between the different lanes is done with an iron pipe and some redstone and an XOR gate.

  • If you're talking about vanilla repeaters then no, they don't get stuck. Timers and sequencers are far better then vanilla circuits in lots of ways :)


    There supposedly are some issues with redpower 2 and servers where things will stop working (but I'm not sure exactly which things get broken, might just be machines).


    As far as loading schematics, I'm pretty sure they work as long as the circuitry isn't active (rapidly changing state) when the schematic is taken. [Though I could be wrong on this, and I'm not sure how it works with sequencers, I'm not a big fan of MCEdit so I try to use it as little as possible.]

    Too many unknowns in this stuff. I don't feel like experimenting with compatibility, it is something completely different than experimenting with design.

    I have a power converter addon due to necessity of not having redstone engine towers, so I might as well use those electric engines and this truly sounds promising. How do they present themselves? How frequently are they ticking? Do they sync or something like that?


    Detection element sounds nice on its own in some other situation, but it has no application in CASUC since it defeats 2 major objectives. It would be truly huge without RP, also very frequent negative ticks from detector unit will just cool the engines down completely (this is the issue I had, see OP) or if you create some circuitry to adjust the desynchronisation to be appropriate it would be even bigger due to flip flops on every (!) detector unit and even more bigger because of need to make negative pulses shorter and redirect buckets to different detectors. I don't have an idea how would I even start doing this, but I could reasonably expect my design to triple its volume (= useless).
    Combustion engines require additional piping from water pumps and fuel supply, which kind of defeats the simplicity aspects (uranium cell -> energy). Also, you are probably overpaying a lot for bucket extraction since combustion engines extract stacks of items and you cannot extract stack of buckets, so fuel consumption is inadequate to its purpose.

  • I have a power converter addon due to necessity of not having redstone engine towers, so I might as well use those electric engines and this truly sounds promising. How do they present themselves? How frequently are they ticking? Do they sync or something like that?


    Detection element sounds nice on its own in some other situation, but it has no application in CASUC since it defeats 2 major objectives. It would be truly huge without RP, also very frequent negative ticks from detector unit will just cool the engines down completely (this is the issue I had, see OP) or if you create some circuitry to adjust the desynchronisation to be appropriate it would be even bigger due to flip flops on every (!) detector unit and even more bigger because of need to make negative pulses shorter and redirect buckets to different detectors. I don't have an idea how would I even start doing this, but I could reasonably expect my design to triple its volume (= useless).
    Combustion engines require additional piping from water pumps and fuel supply, which kind of defeats the simplicity aspects (uranium cell -> energy). Also, you are probably overpaying a lot for bucket extraction since combustion engines extract stacks of items and you cannot extract stack of buckets, so fuel consumption is inadequate to its purpose.

    Well, redstone engines might be enough for a CASUC if you feel confident in your design but like i said earlier. A redstone engine will not cycle exactly once per second no matter what you do. Especially if you sync them.
    The BC->IC² crossover mod i am using introduces electric engines of 4 different flavors.


    • Small - Equal to a stone engine and doesn't require cooling. Draws ~2.5 EU/t per engine.
    • Medium - Equal to a combustion engine and requires cooling if it is to be run constantly. However, since it's full cycle is < 1 second you stop it for a brief period every cycle and that is adequate cooling as far as i can tell, but i have yet to let them do this for more than an hour. Draws ~12.5 EU/t per engine.
    • Large - Equal to 5 combustion engines. Very fast cycle speed (i think twice per second or something like that, need to check source) and needs cooling even if you cycle them. Draws ~75 EU/t per engine!
    • Industrial - Err... Supposedly equal to 5 Large electric engines (25 combustion) and cycles OMGWTF fast (as fast as they possibly can probably) and draws OMGWTF amounts of EU/t. To run these you need a DEDICATED pump per engine and gold waterproof pipes. You also probably need a CASUC reactor to feed it with power on it's own. BUT, a single one of these would be enough to pump > 4 buckets/s into/out of a reactor.

    EDIT: Oh btw, electric engines doesn't explode when they overheat. Either they slow down or they draw more power. I haven't tested to see the effects of overheating.


    I use medium sized engines (4 of them currently) and I am looking at adding another 4 because i am in the process of designing a 5 chamber CASUC, which would allow me to reach the magical 960 EU/t reactor. Something not even ICE based cooling systems can manage! This would net me a 860 EU/t reactor after the cooling system drain and that's 40 EU/t more than a redstone powered 4 chamber that is in perfect sync. Not to mention that is still 15 EU/t better than an ICE based 5 chamber CASUC... I won the internets?
    Well, since i am still in the design phase i can't honestly say i will reach my goal but in theory i will be able to. It's just a lot of testing to be done.
    And this is BEFORE i take advantage of the other addon i have installed named "Additional Pipes" which adds an advanced wooden transport pipe that can be configured to only extract an item of your choice. In this case empty buckets.
    This means i can safely FLOOD the reactor with buckets (and have an obsidian collector underneath for overflow) and possibly reduce my engine count to 6 instead of 8 which would gain me another 25 effective EU/t after the cooling systems running costs.
    These are wonderful times indeed. ;)
    Anyways, back to designing the ultimate CASUC.


    EDIT #2: I apparently had the numbers wrong on power consumption on Large electric engines. It's 75 EU/t not 90 EU/t per engine.
    EDIT #3: And i now know what the effects of overheating is. More power consumption!
    EDIT #4: And they slow down...


    EDIT #5: Ok, just for the sake of it. I timed a Large engine and it does a rev every .4 seconds. I think it's safe to assume the medium does one rev every .8 seconds.

  • Oh, I assumed you were using Power Converters addon. I think it's more popular and it is in Irontygre's design on which I based my own. This addon has slightly different approach to this basic aspect: it has 3 different BC->IC power converters (low, medium, high voltage ones) and the addon you are using has 3 (or more, doesn't matter) electric engines, so IC->BC converters. Aside from that I guess each of the addons we are using has converters in both ways. Looks like authors' opinion varies about which mod is more important ;)



    @everyone else
    I think I did it.
    5 chamber CASUC with 8 buckets-per-redstone-engine-tick flow with no RP involved. When I'll have time I will conduct some longer testing for bucket leaks and flow inefficiences. When finished, I guess you could call it the ultimate reactor :D
    I didn't calculate it, but 8 might not be enough to cool down this monster, but I already have an idea on how to relatively easily upgrade it to 10 bpret (bpret - sounds nice, doesn't it?).

  • *snip*
    I didn't calculate it, but 8 might not be enough to cool down this monster, but I already have an idea on how to relatively easily upgrade it to 10 bpret (bpret - sounds nice, doesn't it?).


    4 buckets/s in 4 slots on the reactor is enough to cool the remaining slots full of uranium cells. Heat generated by a full 5 chamber minus the 4 slots for buckets is 1,920 and 4 buckets is 2,000 cooling at > 4,000 heat in hull. That gives you a max of 6,000 heat. But it IS VERY important that you do not miss a single beat in the reactor at those figures or it will go pop in 6 seconds...


    EDIT: Oh and i hit a snag with my electric engines design... They feed off the power the reactor makes and goes pop due to overvoltage. Lucky me a had a security system set up to stop the reactor but i did press the PANIC button several times as well. ;)


    So now it's back to the drawing board and try to make something happen with that other addon instead or use the unreliable redstone engines or bulky stone engines... Since combustion engines cannot be stopped and started as easily (in the future release of BC)