Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal

Ghan

Members
  • Content Count

    6
  • Joined

  • Last visited

  • Days Won

    4

Posts posted by Ghan

  1. 7 hours ago, Arcanox said:

    I'm experimenting around in creative mode with this because I'd like to eventually run it on my server, but I can't get the turbine control working. When I start the computer, it starts spinning up the turbine (KICKOFF mode), but once it reaches the CALIBRATING stage, it doesn't seem to be adjusting the steam flow rate at all, so it keeps spinning up until it hits the ERROR state. The Target RPM is displayed as "0" and the steam flow rate stays at 600 after it reaches CALIBRATING stage, never decreasing to stabilize the RPM. I'm guessing I'm doing something wrong with setup, but I have no idea what.

    I suspect your turbine is built incorrectly in that case. It sounds like you have too many turbine blades to support the coils you're using. IIRC, the program will basically push the turbine to the floor and run it as fast as it can during the calibration. It only will decrease the steam flow rate once it has calibrated against the maximum energy production possible. If the calibration causes it to go overspeed, then the program stops and errors out, as you see. So you should either reduce the number of turbine blades to bring it more in line with the coil(s) you're using, or add more coils to slow down the rotation.

  2. So I feel like the algorithm doesn't do well when you have draconic crafting going on. Example is when I hook up my draconic crafting using the energy crystals and pull power from a mid-tier draconic orb or similar storage connected to the grid algorithm. Crafting awakened draconium will pull 2 million RF/t for a few seconds, then drop back to the previous passive drain from my power network. The algorithm responds to this by spinning everything up to 100% for a very short time, then dropping back down as the energy drain quickly slows back to normal.

    This isn't directly a problem with draconic itself, but it's a good example of a very brief but huge power spike. The way that the algorithm will let power storage drop to very low levels means that unless I manually hit the Charge option, I'll probably run out of power when trying to do a few awakened draconium craft operations. I haven't tested around too extensively, but it appears that the algorithm doesn't track usage history for long enough to calculate the weighted power usage rate.

    I'd have to sit down and play with some numbers a bit, but maybe some suggestion could go like this (and forgive me if something like this is already going on and I'm missing something):

    1. We can measure the power usage in just straight RF over a given time period (say 5 minutes for example)

    2. We know the maximum input rate that can be generated by the brgc network, and therefore can calculate the amount of RF that can be produced in the same time period as in #1.

    3a. If the difference in the above numbers is large (amount used over 5 minutes is way more than can be generated in 5 minutes), then the algorithm should make larger adjustments to power generation. (How much? No clue. Needs testing.)

    3b. The algorithm could probably easily keep track of a "maximum" of the #1 value. In other words - it keeps a number containing the maximum amount of RF ever used in a 5 minute period. Then, it will always keep that amount of power + x% in the grid, rather than working purely off of the % of total storage available in the grid. Could maybe subtract #2 from this value.

     

    To me, 3a seems like much more of a "I'm going to invent numbers out of thin air" kind of system than 3b does. However in either case, I think various time periods should be tested. Maybe 5, 15, 30 minutes or something like that. In the case of 3b, the maximum should probably be tracked over the life of the program in a persistent way, though there is the potential for outliers. Maybe compare this maximum to the total power storage of the grid? If the entire grid was drained very quickly for some intense operation like an expensive RFTools dimension, maybe it doesn't help to track that value. Maybe just throw out values that are > 80% of total grid storage?

     

    Just some random thoughts. Let me know what you think.

  3. @XyFreak

    I have found out a few things, but I think I'm more confused now than I was. When I first checked this evening, the system was producing about 20k RF/t for a power demand of 21k RF/t - Grid = DECREASING CHARGE, so no issue there, that's what I expect to see. However, the reactor was doing so with a temp around 1050C, which seems to be much hotter than it should be running it. Also, I noticed that lo and behold, my tank was out of water (water generation wasn't keeping up). So I've gone ahead and added 4 Ender IO Reservoirs connected to the water line. Tried the portable tanks, but they don't seem to be able to extract that fast, and I overall needed more water generation, not just storage.

    Ran a calibration on the reactor with the extra water production and it kept up as the reactor ramped up to 800 mB/T, then 1600 mB/T, then 2000 or so. However, right as it was finishing calibration (and I heard the computer sound of writing a file change), all the water drained for a few seconds and had to catch back up. I think it shut off some of the turbines because the algorithm told it that it was producing excess power, causing the water production to drop. At the same time, the reactor temp went up to 1000C (was below 200C during the calibration) and now stays there even though I've done this loop through a couple times now. Here is the steady state (20.7 kRF/T out of 21.9 kRF/T):

     

    Ghan-18-07-17_19:23:31.png

     

    I've also noticed that just running "brgcctrl calibrate <id>" doesn't seem to work. Sometimes when I try this, the reactor will just immediately go to ERROR on the GUI screen. Then I have to shut down the brgcctrl services, restart the reactor, and then restart the services or just reboot the computer to run through calibration again. Other times, the reactor will just sit there with all rods inserted at 100% producing 0 steam. It doesn't seem to budge from this position once stuck.

     

    For the record, here's the list of assets the program is managing. Turbines are 2 x 20 blade, 2 x 40 blade, and 1 x 80 blade:

    Ghan-18-07-17_19:34:51.png

     

    Kind of scratching my head on what the issue would be here. It appears to be running the reactor hot due to an overproduction of steam at the steady state, but why would it be doing this? Could this be caused because I didn't start with all 5 turbines and instead added a couple after the program was initially running? Should I try wiping out the config and starting over?

    I can PM you my server address if you want to come take a look yourself. Let me know.

     

    Thanks!

  4. No, I just have the one reactor powering all 5 turbines. They are all interconnected to the same fluiducts. I'll try switching around the water supply and then recalibrating the reactor to see how it behaves.

  5. 18 minutes ago, XyFreak said:

    Hi @Ghan,

    to answer your last question: This doesn't seem normal at all.

    Not being able to provide the reactor with enough water will indeed throw off reactor calibration.

    To sufficiently analyze your problem I'd at least need to see the reactor (A http://br.sidoh.org blueprint should do).

    It's just a simple 5x5. Should be this:

    http://br.sidoh.org/#reactor-design?length=5&width=5&height=5&activelyCooled=false&controlRodInsertion=0&layout=6CXCX3CX3CXCX6C

    I just have one input and one output for steam/water. I'm pulling water in via a simple Ender IO tank being filled by Refined Storage - this might be a bottleneck. The fluiduct is directly connected to the tank, but I don't know if that means it can pull as fast as it wants (I never see the tank or the fluiduct empty).

  6. Hi XyFreak,

    I'm having an intermittent issue that I think I ran into before on a previous world, but this one is newer and up to date with the modpack (Direwolf20 1.10).

    I have an active reactor providing steam to a handful of turbines (5). The issue is that the program won't kick the reactor steam production up enough to power the turbines enough to keep up with power demand. I have a draconic orb attached - had the program charge the energy storage to full, then left it overnight slowly discharging. I came back to a completely empty orb with power generation only about half of what is needed. I tried calibrating the reactor a few times via cli and it appears to have worked on the third attempt after a computer reboot (currently monitoring it) but the previous two attempts did not. What it would do while calibrating is stick all the control rods at some low amount of power (like 80-90% inserted) and then sit there in the CALIBRATING state for 5-10 minutes before clearing it and just leaving the reactor sit there producing 0.5-1.5 B/t of steam (not enough). Additionally, I would see turbines in the "SLOW SPINUP" mode slowly losing speed instead of gaining due to lack of steam.

    The only thing I've noticed that stood out to me was that right after starting reactor calibration, the water supply seemed to be insufficient, but it soon caught up to the demand (long before the calibration finished) - could this have thrown the program off in some way? Am I missing something simple here? Using super-laminar fluiduct to move water and steam around, so no bottlenecks there. Let me know if you want any other details.

     

    P.S. Watching it for a few minutes - it appears to have settled down at a sufficient generation rate, but now I see that the reactor temp is higher than I'd like - it's holding steady around 995 C producing 2 B/t of steam and burning around 450 mB/t of yellorium. Is that normal?

     

    Thanks!

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.