Jump to content

Thoughts on Big Reactors Automation


pruby
 Share

Recommended Posts

I've been thinking a lot about getting the most out of Big Reactors with a passive reactor, and have seen a few automated controller scripts, but also not much discussion about what makes an automated controller good or bad.

My standards for a good controller:
1. First and foremost, ensures power is available on demand.
  * Gauges demand and responds by generating enough power to supply it.
  * Responds to rapid changes in power demand from the network.
2. Generates as much power as possible at or near peak efficiency.
  * Is aware of its peak performance value for the control rods, and attempts to run at this level.
  * Takes account of startup and shut down costs.
  * May be aware of heat levels, and actively seek optimal heat.

Some controller models, from most to least difficult to implement:

Simple threshold on/off controller, implemented with simple redstone. This controller enables the reactor when % power crosses a threshold (e.g. 90%) and turns it off when the power crosses that threshold again. Control rod level is not varied.
* Reactor may turn on/off frequently, losing efficiency as it heats up and cools down.
* A fixed control rod level allows running at peak efficiency or having maximum possible output available, not both. Control rods cannot be varied to match output.

Spread thresholds on/off controller, implemented with more complex redstone. This controller again controls only an on/off switch and not the control rods. However, it activates when the power store goes below one threshold (e.g. 50%), then continues until it reaches another higher threshold (e.g. 95%).
* This reduces rapid turning on and off, gives the reactor a better chance to reach and run at an efficient rate.
* The fixed control rod still must be set to peak efficiency, or maximum power (0% insertion) or somewhere in between. Cannot achieve both full availability of maximum power and efficiency.

Control rod matches battery % controller, implemented with Rednet or ComputerCraft: This leaves the reactor in an "on" state continuously, but matches the control rod insertion to the battery state. When the battery is low, the control rod insertion is low and generation high. When the battery % is high, the control rod insertion is high and generation low.
* For any power demand within the reactor's output range, this will match the demand from the network.
* The efficiency the reactor runs at depends on the rate of demand from the network. We achieve optimum efficiency only when the network demands the amount of power produced at optimum efficiency.
* At low demand, reactor may be set to very high control rod insertion (e.g. 95%). Even reactors designed to operate efficiently over a broad range of control %s (balanced rods/moderation/cooling) tend to lose fuel efficiency rapidly when operating over 80%. Since fuel consumption is low at this time, people may not care, but this is a lost potential.

Combined on/off thresholds, control rod matching battery % controller: Both a threshold on/off controller and a control rod balancer could be installed at once. This can turn the generator off in the inefficient >80% control rod range, allowing power to drain until we hit a more efficient level.
* For low power demand, below that produced at the reactor's optimum efficiency, this will turn on and off to produce power at that optimum level, then use it more slowly.
* For high power demand, in excess of the reactor's optimum efficiency, this uses the control rods.

Specific heat targetting controllers?

I intend to experiment with this as a set of controller rules to try to combine the best attributes of the above:

* We turn on when the battery hits 50%.
* We turn off when the battery hits 95%.
* Above 50%, the control rod % is fixed at the optimum level.
* At or below 10%, we operate at 0% control rod insertion.
* Between 10% and 50%, the control rod % scales evenly from 0% to our optimum.

This model ensures that the reactor runs only at its optimum level when demand is below the energy output at that optimum. It generates at least 45% of its battery power each time it turns on, reducing the heat up and cool down inefficiencies. It is capable, however, of supplying the maximum available power on demand at the cost of efficiency.

I intend to test this design this evening for a 6 circuit Programmable Rednet Controller (no expansion cards) to implement those rules.

Less or equal: I0 = INPUT battery % , I1 = constant 50 -> Variable 0
Greater or equal: I0 = INPUT battery % , I1 = constant 95 -> Variable 1
S/R latch: R = Variable 1, S = Variable 0 -> Variable 2
Scale: I = Battery %, IMin = 10, IMax = 50, OMin = 0, OMax = [OPTIMUM] -> Variable 3
Mux (4 input): I0 = constant 100, I1 = NULL, I2 = [OPTIMUM], I3 = Variable 3, S0 = Variable 0, S1 = Variable 2 -> Variable 4
Maximum (2 input): I0 = Variable 4, I1 = constant 0 -> OUTPUT control rod %

I also plan to test a "wasted RF" meter which tracks the efficiency of reactors in actual use.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...