XyFreak

@Chrisszzyy sorry for not noticing the part where you statet you already recalibrated. I guess I was too focused at thinking what MIGHT help and not double checking.

I noticed that your output poly has a max of 9453 mB/t while the reactor I built from your image has 6521 mB/t . Also the calculated optimum is set to 0.01 (wrong) while it has a proper value for me.

Is there a server I can reproduce your issues directly on?

I'm a bit at a loss here but I also noticed something else with extreme reactors yesterday:

@ZeroNoRyouki I'll ping you as well since you might want to know what's going on here.

When I first start up my minecraft and load a single player world for the first time, the APIs related to querying the hot fluid state are broken. Both the old and the new ones. The reactor I built from @Chrisszzyys description has a steam tank holding 31400 mB. While this is reported correctly, the current amount of hot fluid is not. The API maxes out at 6250ish mB for that reactor. I'm not 100% sure of whether it just caps out or actually scales but it might do both. The APIs behave normally as soon as I reload the world.

Restarting minecraft causes this issue to appear again. All active reactors are affected. Even newly built ones.

If this also happens on a server then this might already be the issue (since you can't reload the world without restarting the server - in which case the issue comes up again).

The ER version I use is 0.4.5.49 and zerocore 0.1.2.2

The issue CAN be confirmed using BRGC as well as it will display the hot fluid tank as not full when it is - in fact - completely full.

@Moobien please excuse me if i ask stupid questions or anything. Your reactor looks fine (size wise) so I'm wondering if there might be an issue with fluid transfer. The reactor is definitely hitting a ceiling before it even gets a chance to take its first measurment - it wouldn't error out otherwise.

@Chrisszzyy

Thanks, I just built your reactor in my test world and it worked flawlessy.

Here's what I think happened: You kicked off everything at once, as you should be able to. This caused the turbines to speed up and the reactor to start calibrating at the same time. Then your turbines went overspeed and got shut down, suddenly causing the reactor to overproduce steam causing calibration to terminate. During the last phase something went wrong when calculating the output curve. I can only suggest you rerun the reactor calibration, assuring the turbines won't suddenly fail.

Can you post your br_control.cfg as well? The generated config should look similar to what I here so we can test whether or not my theory is plausible.

        ["d69713ac-bbb2-4ed1-bda5-6e2b11017210"] = {
                    outputOpt = 0.21747975557943,
                  rodLevelMin = 0,
            outputReversePoly = {coefs={0,0.00015333991938894}},
                   outputPoly = {coefs={0,6521.4590172277}},
        }

@Moobien

You have to let the reactor cool down first. You can easily do that by having it pump out steam (e.g. into your turbine). Also make sure you have enough water.

Sounds like you are running an old OpenComputers version - this bug came up before and has since been fixed i believe.

1 -> The reason the program has issues with your turbines is that it assumes that it has exactly the correct amount of blades. The formular is pretty simple: total steam = #blades * 25mb/t. Since Your turbine has 72 blades that results in a total of 1800 mb/t, which is too much for your setup and your turbines will go overspeed.

3 -> 350 should be more than fine... if it was over 700 i knew where the problem is but that... seems odd. Something propably went wrong with the calibration. My guess right now would be that it can't output enough steam and thus the program can't collect enough samples to approximate the reactors behaviour. The red load bar supports that thought.
Can you post a construction plan of the reactor so I can have a look at it myself ( http://br.sidoh.org )?

The entire program is supposed to be fully automated without any/a lot additional user interaction. To make this work, a lot of flexibility had to be sacrificed.

Regarding the multimonitor issues. The GUI is designed to only run on one monitor, yes. If you have multiple screens / GPUs installed, it'll bind one of the secondary monitors to any of the secondary GPUs and display the program on there, freeing up the main screen. I've never had it complain about a GPU not being present tho o_O.

Running it more than one time is going to give you trouble for sure. I should propably look into preventing it to even try...

EDIT:

About the calibration issue - looking at the current output %, your reactor should've been able to output enough steam to your turbines. Can you speed down the turbines and remove the config file, then reboot the computer? That'll redo everything... if it still fails then .. uh... i need to test the reactor in my own world and plot some curves to figure out what's going on.

@Chrisszzyy first of all, thanks for your feedback.

-> 1)

Can you go into detail please?

Each rotor blade in a turbine consumes 25 mB/t per blade that's attached to the rotor. Unless things have changed significantly, anything more than #blades * 25 mB/t is wasted. The controller should NEVER give your turbine more steam than that. This is mentioned in the instructions. And to be honest.... the method of calibrating turbines is REALLY straight forward. I'm guessing #3 actually the root of your troubles. If your turbines CAN go overspeed (aka you have too many blades) then BRGC is going to run into a brick wall but it'll also tell you that this happened (the turbine ERRORs out).

-> 2)

The CLI was something I hacked together to help out in some instances but was never meant to be actually used by the general public. It can help debugging stuff tho, which is the primary goal. It also helped getting BRGC up and running on computercraft without the GUI a WHILE back as an experiment

-> 3)

The reason the program falls short to produce the required amount of steam is propably because of the reactors core temperature (just a guess). The red bar also indicates that the reactor is running hot. I do agree that I should propably remove the temperature limitation.... If you want to test that out: reactor_active.lua around line 68, assign 0 to pTemperatureLimit instead of the formular that's there. I should propably remove that myself - the limit code IS quite old and is known to cause problems with inefficient setups. (It's also ugly and the code around that needs to be cleaned up >_>).

Out of curiosity: How hot is your reactor running?

Lastly please allow me to comment on your first sentence.

19 hours ago, Chrisszzyy said:

I've been trying this mod over the past few days and have run into so many problems, it has been unbelievable.

I've been working on this since BR for 1.7 got released and Improved it ever since. I released it to the general public because a friend of mine used it on his server and ppl really wanted it (by the time the only real alternative was dw20s script iirc and that one sucked... and could only control one turbine/reactor combo so...yeah). I've been improving it ever since. Trust me - if there's a problem I run into, it's gone in a matter of hours. Same if you actually tell me how to reproduce the issue myself.

This also means that I do not understand the unbelievable part and yes I'm a bit butthurt by this. I do sincerely appologize if using my program has cost you a lot of time. That was never my intention - this program is supposed to just run and go. Anything else is not acceptable.

That being said - if it's so unbelievable I would love to hear all about the troubles you had setting everything up. You can PM me anytime or join my discord or teamspeak if you think straight up talking about it would be faster. You don't need to worry about meeting a pissed XyFreak btw - I'm always open and thankful for suggestions. I'm happy to hear you out off-record. If you want voicechat, tell me and I'll pm you the details.

Ok guys i need more information if you want me to help you.

• What's your issue? (expected vs actual behavior)
• What version of OC / ER are you using? (actual mod versions pls)
• Is your reactor active / passive?
• What's your reactors layout? => http://br.sidoh.org
• What does running `brgcctrl service reactor runOnce` do?
• Are there error messages popping up when the GUI is closed / when you run brgcctrl?
• Is the grid controller enabled?
• What does running `brgcctrl service service runOnce` do?
• Are there external energy components connected? If so which and how many?
• Can you screenshot anything that might be useful? (e.g. actual reactor / turbine GUI)

Obviously PWM isn't supposed to overproduce power at all, but since ppl have been reporting it works for them there has either been a change in some API I'm not aware of or there is a configuration (read setup) that doesn't work.

I need to be able to reproduce those things in order to debug them.

@dangerspookycanyon

Is "LOAD" working out for you? Or is the energy generation just getting stuck there?

@Kyuubi it's something i'd like to fix tho...

@Ocelot_ it takes a WHILE depending on how your reactor is built. You can use the GUI to track the rod insertion level to figure out how far it is - it's going to hit 100% eventually and finish shortly after.

Can you send me a screenshot of the reactors actual gui right after it errors out?

1 minute ago, MARTIKRISO said:

@XyFreak It hasnt overheated.

 

Is it going into ERROR state after calibration? That's the only other thing that can fail.

@aliax

Exit the gui and please do a `brgcctrl service reactor runOnce` when the reactor(s) are supposed to shut down? Are there any errors popping up? Please repeat with service `grid` if you're using the grid controller (you propably are).

@MARTIKRISO

Your reactor "overheats" (temp >= 1500) and is flagged as faulty as a result.

12 hours ago, HiggyHLyoung said:

roughly how long will it take the reactor to reach max RF/T ?

That's a difficult question but I hope this graph will explain it a bit for you:

The blue line is the default config and the red "line" is the max rf/t config.

As you can see the power output of the default config will continue to increase until the thermal limit is exceeded and then shut down shortly after.

The max rf/t ones power output will increase at first until 2000000 rf/t is reached and then starts oscillating. The resolution of the graph isn't high enough so you see that red block there. The average energy output is somewhere in the lower third of that thingy (propably 1/3 * max + 2/3 * min). After reaching a certain temperature it'll quickly shut down here as well.

EDIT:

Here's the same graph with dots only:

On 6/8/2018 at 3:29 PM, selli69 said:

Hi XyFreak!

First of all, thank you for this really good piece of software.

My question: Is there a possibility to cap the "100%" value for the grid capacitor to a lower level? Backround is, I have a massive solar array I want to combine with the reactors/turbines to a main power line. By the moment I inject the solar power to the capacitor bank the brgc is monitoring. The problem is now, that the turbines/reactors try to charge the capacitors during night time to 100%. It would be better when the reactors/turbines charge only to 50% because during daytime i have  overproduction from the solars i dont want to waste (when capacitors are full).

Is there a way to alter the code or is there a possibility to add an configuration value? Or should I simply wire my power grid just in another way?

 

Thanks forward!

You're looking for lines 46 and 47 in `/usr/lib/brgc/grid_controller.lua` 

On 5/27/2018 at 1:30 AM, Moobien said:

A suggestion then, perhaps something in the gui to run a recalibration?

I'm running out of space there

4 minutes ago, ZeroNoRyouki said:

@XyFreak I've got a question on your usage of the setControlRodsLevels method. Are you re-using the table you pass in after calling the method?

I'm investigating a crash (https://github.com/ZeroNoRyouki/BigReactors/issues/178) that look like a race condition between a LUA thread (running your code?) and the Server thread running the code of setControlRodsLevels.

No, every call gets a new table that is created from scratch. The code constructing the table is in reactor_base.lua lines 425 - 467 if you want to take a look at it.

8 hours ago, Moobien said:

was just wondering if there is a way to force recalibration for reactors and turbines that have been modified, as an example changing the reactor internals or turbine induction coil materials

Pls check out brgcctrl calibrate

brgcctrl calibrate <address here>

Alternatively you can always remove the configuration file to reset everything.

EDIT:

brgcctrl accepts partial addresses (e.g. the first three letters)

Well after you extracted the files you can just proceed as you normally would. Keep in mind that the archives are meant to be extracted to the root of your computers filesystem.

There is a sanity check in there but if the computer looses control of the flux gates / reactor there is nothing that can be done.

For e.g. if the connection to the reactor is lost, it tries to set the output fluxgate to 0 and keeps the input at the last known to be good value.

As long as the reactor is still connected and the input flux gate (control over output is lost) It'll keep the containment stable.

There's also code that shuts down the reactor but that only happens once the reactor is over 99% saturation. The reason for that is that we don't know if shutting down the reactor will cause a brownout and subsequently cause the containment to fail.

The issue here is that we lose control over both flux gates and can't do anything. The reactor is never gonna go to 99% saturation and we're screwed. You CAN just replace the check at line 252 with a true to have the failsafe always shut down the reactor if something happens tho.

Hmm ic. The addresses should definitely NOT change after a server reboot.

I had the same issue when using EnderIO OC conduits. Those conduits are bugged as hell and are counted for one component each the first tick after server reboot, which causes your computer to crash. I "fixed" the issue by reducing the number of conduits used and using a server with a lot of component cards.

TL;DR Don't use EnderIO conduits and build the computer in the same chunk as the reactor

Hey @Chaoschaot234

My libGUI should only redraw stuff that actually HAS to be redrawn - except when a redraw is forced which should only happen on resolution changes. I'll look into it. Are you sure the static stuff is blinking?

You can set up the gui start yourself by ... umm... i think editing /home/.profile or something - there're posts here on the forum that explain how i think.

At the present you can not monitor multiple reactors. The GUI doesn't support it - it's a flaw i know about and i actually have a modified version that is extremely wonky that CAN do it xD. Maybe I'll cook up something for that...

For the config file it doesn't actually matter whether you coma-separate stuff or use semicolons. How does the GUI fail? You need to restart the reactor service after you changed the configuration file. Safest way is to reboot the computer.

If you're not doing crazy breeder shenanigans the reactor will survive a computer reboot without any issues. Infact.... your reactor is gonna be safe if the computer crashes between 30%ish and 80%ish fuel conversion and doesn't come back on until it leaves that range - you're going to lose RF/t tho.

Older versions of ER have racing conditions in the OC API that can and will straight up crash your server.

Sorry I have no idea. I already offered my assistance but I think zero wants to do it without help

Hi @MarkusPriska

Your turbines propably have more coil blocks in them than they should have. Please double check your turbine design.

As for the freezes, that's most likely a deadlock in extreme reactors. Afaik @ZeroNoRyouki is already looking into it. I don't know if the issues has been fixed. For startest, please try upgrading to the latest version of ER. If you already are on the latest version, then I'm afraid there is no fix just yet

You are running an old version of OpenComputers. You'll need to update the mod and then reinstall OpenOS

Umm... what is "brgc"? The error you're seeing is because that file is either empty or invalid (not sure which it is). However the installer shouldn't create a "brgc" file anywhere....