This is the I2C reactor design I'm currently using in my FTB Infinity world. I found the design on the I2C forums. It has an efficiency of 9.34, and when built in an electric (non-pressurized) reactor, it has no chance of overheating. However, because it uses both quad and dual cells for fuel, many would shy away from it because it is much harder to automate. You can't just stick an ME Import Bus on it to suck out the spent rods and an Export Bus to inject fresh ones. You have to maintain the rod pattern and composition. The challenge of making something like this work, however, is what I find fun, and it really isn't all that hard to automate if you have a MineFactory Reloaded Rednet Controller.
This is my first version of the design. Hidden behind the door to the right is the lever that turns it on and off, an ME Fluid Interface providing the cool coolant and reabsorbing the hot through the Ender IO ender fluid conduit, and three fluid level emitters. The reactor is in the room below.
Here's how it works. A Buildcraft Golden AND gate is on the side of the reactor (on a reactor hatch), and is set up to output a redstone signal when both depleted dual and quad cells are detected in the adjacent inventory. Also on the side of the reactor are Ender IO item conduits controlled by Ender IO insulated redstone conduit, plus insulated redstone conduit to control the reactor. When the AND gate goes high, its redstone signal is carried on the blue channel of the conduit to the controller, resetting the counter and releasing the ProjectRed timer. As the timer ticks, each tick increments the counter, and when the output of the counter equals an equal gate, that gate goes high, executing a step in the refueling process. So, the timer resets and equals zero, which sends a signal to remove the spent quad cells from the reactor via a filtered Ender IO item conduit. The timer ticks 2 seconds later, incrementing the counter to one, which sends a signal to remove fresh quad cells from a cache and insert them in the reactor, which fills the space previously occupied by the spent cells. This continues with removing the spent dual cells and inserting fresh dual cells at equals 2 and 3, respectively. Finally, at equals 4, a signal is sent to the timer to stop it spinning, and a 3 input AND gate that controls the reactor receives a high. The other two inputs to that AND gate come from a lever and an ME fluid level sensor that stays high as long as there is more than 32 buckets of coolant available.
This system worked beautifully, but it used a lot of channels on the insulated redstone conduit, which limited the number of reactors that could be controlled on a single line. Thus began work on version 2 of the reactor controller and refueler logic system.
In this version, the levers that turn on and off the reactors instead feed into the controllers on the right, freeing up the bottom channels for reactor control, sensing, and refueling. Now, I could easily compact the control of 3 reactors into a single controller, but this arrangement looks more visually interesting and the separation keeps things manageable and easier to track. The rightmost controller controls reactor 1, and the center reactor 2. The leftmost controller is all programmed and ready to go, but I've yet to get that reactor ready. Also, the caches and the waste rod chest have been replaced with ME interfaces.
The major improvements of version 2 over version 1 are that it uses fewer rednet channels per reactor controlled, completes a refueling cycle almost 4 seconds faster, and uses Reactor Control 2 sensors to monitor reactor temperature instead of ME Fluid level sensors to measure available coolant levels. The basic idea is the same. When the reactor needs to be refueled, the counter is reset by a Golden AND gate, and steps are executed via equals gates reading the counter output. However, instead of removing the cells in step 1 and loading new ones in step 2 using two separate redstone channels for each, this design performs the remove and reload at the same time using the same redstone channel. The AND gate and delay setup creates a small amount of separation to prevent a delayed redstone update from adding a quad cell to an empty dual slot. It isn't perfect. In my world, the reactor will run for a split second when the fresh quad cells are inserted, but that does not appear to impact the next reload cycle.
Now, I'm sure some of you are going to take a look at this and say to yourself "I could program a ComputerCraft computer to do the same thing in about 30 minutes." Thing is, I'm an electrical engineer. I have some coding experience, but my mind works best with gates and boolean logic systems. This is fun for me.
I already have a few ideas for version 3, like condensing the 3 lines for reactor on/off, pull/insert quads, and pull/insert duals into just 2 lines, and passing back information into the control room to show the reactors as on, off, overheated, and reloading.
Why don't we see more stuff like this? Rednet Controllers are fun!
