Big Reactors Grid Control

[hron84 1]

@XyFreak Thanks for the response. It would be good if you can check if T3 screens are connected and if not, print out only small summary infos with the two button (charge, ON/OFF) because right now it's a bit messed and also there is no option to exit the program

Also, I wonder how the control stuff works. I expected it to detect if the cell / reactor internal power buffer is charging/decharging and turn on/off reactor automagically as it is needed (or control the production with control rods). However, after the reactor buffer totally charges (it does not handle TE cells correctly right now as they not seems handled in the Grid screeen), it tunes control rods up to 100% and stop taking care about the reactor even if all power is gone from the system.

If nothing any, please consider monitoring computer's own power supply and if it is going low, please enable reactor to produce some power at least for the computer. I know the main purpose of this software is manage a complex, reactor-turbine twisted setup, but this is the only software I found that has a nice display about the system and I'd like to use it to my simple small reactor with 5 rods.

 

EDIT I took a look into the code, and compatible energy storage components can be expanded with "energy_device" - this is how ThermalExpansion cells appear in component list.

[afr33sl4ve 0]

On 1/14/2018 at 5:01 AM, XyFreak said:

Hey guys,

@afr33sl4ve I need some more info on your setup in order to figure out what's going on here.

What do you need from me? Tell me which files you need me to upload, and I'll make it happen. I would love to see this work better for me, and you're asking for my help so you can help me better and I'm not sure how to do that.

I just found where the mod stores the programs in my world folder.

Also, the program is waiting till I get to 0 RF stored, before kicking on the reactor.

[XyFreak 36]

@hron84 I think I'll make it so it hides the "Reactor" and "Turbines" buttons on lower resolutions.. that should do the trick. Thanks for the TE cell thingy.

@afr33sl4ve I need a way to rebuild your reactor in my test world so a schematic would be nice.

[afr33sl4ve 0]

19 minutes ago, XyFreak said:

 

@afr33sl4ve I need a way to rebuild your reactor in my test world so a schematic would be nice.

http://br.sidoh.org/#reactor-design?length=16&width=16&height=46&activelyCooled=false&controlRodInsertion=0&layout=17CXCXCXCXCXCXCX4CXEXEXEXEXEXEX2CXEXEXEXEXEXEX4CXEXEXEXEXEXEX2CXEXEXEXEXEXEX4CXEXEXEXEXEXEX2CXEXEXEXEXEXEX4CXEXEXEXEXEXEX2CXEXEXEXEXEXEX4CXEXEXEXEXEXEX2CXEXEXEXEXEXEX4CXEXEXEXEXEXEX2CXEXEXEXEXEXEX4CXCXCXCXCXCXCX17C

Playing on All The Mods 3, max internal height = 46. Reading from an RFTools Powercell.

[XyFreak 36]

That's going to take a while to build xD

I'll get to it tomorrow

EDIT: BTW - Could it be that you swapped cryotheum and ender around? Cause ender is good on the outside while cryotheum is better inbetween rods afaik

[Gavote 1]

@afr33sl4ve If you did build it this way, seriously consider swapping the two liquids!

 

http://br.sidoh.org/#reactor-design?length=16&width=16&height=46&activelyCooled=false&controlRodInsertion=97&layout=O14EOEXCXCXCXCXCXCXC2ECXCXCXCXCXCXCX2EXCXCXCXCXCXCXC2ECXCXCXCXCXCXCX2EXCXCXCXCXCXCXC2ECXCXCXCXCXCXCX2EXCXCXCXCXCXCXC2ECXCXCXCXCXCXCX2EXCXCXCXCXCXCXC2ECXCXCXCXCXCXCX2EXCXCXCXCXCXCXC2ECXCXCXCXCXCXCX2EXCXCXCXCXCXCXC2ECXCXCXCXCXCXCXEO14EO

[afr33sl4ve 0]

It was a pain filling in the Gelid. Plus, it was my first time messing with the stuff. I'm good.

[Gavote 1]

@afr33sl4ve   That's part of why the gelid works better between the rods! also if you have Immersive Engineering, check out the fluid outlet. It works like the old floodgate, great for deploying fluids.

Edited January 19, 2018 by Gavote

[XyFreak 36]

Actually Additions fluid placers help ;)...

I can't believe I came up with that only just now....things could've been so much easier, lol

[afr33sl4ve 0]

I used the Mekanism fluid pump. But, dang it. I have access to both those mods in ATM3.

[XyFreak 36]

Since you are using mekanism: The next version will have support for mekanisms energy storage thingy btw.

[Gavote 1]

Oooh! Thank you!

[XyFreak 36]

@afr33sl4ve I just tried to build the reactor in your schematics and it tells me it's too large. Can you double-check the dimensions of your schematics? The dimensions you put in there are for the reactor interiour.

So the total size of your reactor schematics is 18x18x48

[XyFreak 36]

Ok here's my verdict: Since the yield bug we discovered in november is STILL not fixed, my guess is that any anomalies you see is because of that!

The controller needs to fetch a bunch of stats from the reactor during the same tick, which is no longer possible due to that bug. This throws off the controller and it can't properly calibrate your reactor.

I'm sorry but there is nothing I can do except saying: Early versions of ER for 1.10 still work. 1.7.10 works as well. Later versions of 1.10, all versions for 1.11 and all versions up to today for 1.12 are not supported.

Don't bug ZeroNoRyouki about this too much. He's a cool guy and tried to help already (go check the previous pages). Instead go bug the OpenComputer guys about this. Here's the issue on GitHub (https://github.com/MightyPirates/OpenComputers/issues/2632).

The least I'd expect is some kind of response. But as you can see: Nothing. Sorry for being grumpy about this but this thing really sucks and the guys in the OC IRC channel are not really helpful either, telling me to "just use more computers!" (instead of fixing the issue), which is obviously not practical for most users.

 

-XyFreak

[afr33sl4ve 0]

2 hours ago, XyFreak said:

@afr33sl4ve I just tried to build the reactor in your schematics and it tells me it's too large. Can you double-check the dimensions of your schematics? The dimensions you put in there are for the reactor interiour.

So the total size of your reactor schematics is 18x18x48

Exterior dimensions are 16x16x48. I wish the simulator would clarify which values I'm editing.

Well, I was a derp. It does clarify that those are the internal dimensions.

http://br.sidoh.org/#reactor-design?length=14&width=14&height=46&activelyCooled=false&controlRodInsertion=0&layout=15CXCXCXCXCXCX4CXEXEXEXEXEX2CXEXEXEXEXEX4CXEXEXEXEXEX2CXEXEXEXEXEX4CXEXEXEXEXEX2CXEXEXEXEXEX4CXEXEXEXEXEX2CXEXEXEXEXEX4CXEXEXEXEXEX2CXEXEXEXEXEX4CXCXCXCXCXCX15C

[ZeroNoRyouki 7]

@XyFreak : I'm not making any promises because I've yet to verify if it's technically feasible, but if you would be able to "fetch a bunch of stats" with a single call, what stats would those be?

[XyFreak 36]

Hi @ZeroNoRyouki

Thanks. Here's a list of things I would query but maybe it'd be a good idea to have a command that includes all non-mod-global-constants. Anyways, here we go:

Active Reactors:

• getHotFluidProducedLastTick
• getHotFluidAmount
• getHotFluidAmountMax
• getFuelTemperature
• getFuelAmount
• getFuelAmountMax
• getFuelConsumedLastTick

Passive Reactors:

• getEnergyProducedLastTick
• getEnergyStored
• getEnergyStoredMax (That's a mod constant right now but this should be included in case you want to change this at some point)
• getFuelTemperature
• getFuelAmount
• getFuelAmountMax
• getFuelConsumedLastTick

Turbines:

• getEnergyProducedLastTick
• getEnergyStored
• getEnergyStoredMax (That's a mod constant right now but this should be included in case you want to change this at some point)
• getRotorSpeed
• getFluidFlowRateMax

In addition to that I also set all fuel rods individually to get finer grained control over the reactor. This is kinda important for everything medium-sized and above (you usually start seeing its effects with 8+ fuel rods and a decent height). So a command that accepts an array of values between 0 and 100 for each rod would be neat. I'd expect this command to fail if:

• The size of the array does not exactly match the number of rods
• Any of the arrays elements is not an integer
• Any of the arrays element integers are outside of range [0, 100]

This is also where I'm currently debating on how to optimize for less API calls.... but that kinda function would solve all my worries here.

 

Having an API like that would at least make smaller setups feasible again (I'm thinking one active reactor with two turbines). For larger setups the individual passive reactor / turbine controllers would no longer get confused but the controller for active turbines might still not be able to keep the steam tanks fill level as smooth as it was able to in previous versions. Same with "LOAD" mode for anything propably.... But I think we can all live with that for the time being

Thanks again for helping out.

-XyFreak

[Seiver 0]

my reactors refuse to calibrate

 

ER - 0.4.5.44

OC - 1.7.1.43

 

[payonel 21]

On 1/20/2018 at 5:32 AM, XyFreak said:

Since the yield bug we discovered in november is STILL not fixed

What yield bug?

[XyFreak 36]

@payonel Please check the post you quoted from ;). On the last two pages of this thread we discussed it in some more detail.

[payonel 21]

I've read the entire post. I've read your review of the system yielding longer than you'd like, but I haven't read about a yield bug.

Read my response to this github ticket: https://github.com/MightyPirates/OpenComputers/issues/2632

Is there something I'm missing?

[Arcanox 0]

31 minutes ago, payonel said:

I've read the entire post. I've read your review of the system yielding longer than you'd like, but I haven't read about a yield bug.

Read my response to this github ticket: https://github.com/MightyPirates/OpenComputers/issues/2632

Is there something I'm missing?

It is certainly a bug, because it was introduced in a recent version of OpenComputers. This has not always been the case. The post here details which versions of OC/ER are affected by the bug.

Not all mods' APIs are affected; certain other mods return nearly instantly from API calls (such as Draconic Evolution) and there can be multiple API calls per tick without slowing down the computer to any noticeable extent. Extreme Reactors is one of the mods affected, however, and when running this program with any number of ER devices attached, the computer is slowed down to the point where typing characters into the shell can take upwards of 5 seconds per character (that is not an exaggeration). I can't possibly see how that could be by-design, especially since it just started happening since a particular version of ER and OC.

[payonel 21]

The list of versions affected show both good and bad for oc 1.6 and 1.7, while ER >= 0.4.5.41 (thus, including 44) is bad in both cases

So from that list alone it seems to be an issue with ER, and not a regression in oc 1.6 -> 1.7

Also, I had not realized the event handling delay with keyboard hits was so intense. Curious, when that is occurring, is the cursor blinking normally? (.5 second blink)

-edit-

It isn't by design to have such a delay in typing. The delay by design is to limit the number of direct api calls you can make within a tick

 

[payonel 21]

As to the delay in the shell, please see my comment in the github ticket

-edit-

I'll post here for  those that don't want to open more tabs:

First of all, if you are sleeping ( os.sleep ) in a service, that is going to block your shell. Use threads instead if you want to sleep without blocking other coroutines http://ocdoc.cil.li/api:thread

Edited January 26, 2018 by payonel

[Arcanox 0]

10 minutes ago, payonel said:

The list of versions affected show both good and bad for oc 1.6 and 1.7, while ER >= 0.4.5.41 (thus, including 44) is bad in both cases

So from that list alone it seems to be an issue with ER, and not a regression in oc 1.6 -> 1.7

Also, I had not realized the event handling delay with keyboard hits was so intense. Curious, when that is occurring, is the cursor blinking normally? (.5 second blink)

-edit-

It isn't by design to have such a delay in typing. The delay by design is to limit the number of direct api calls you can make within a tick

 

I don't believe the cursor blinks at its normal rate; I would have to check after work to be sure, but if I recall correctly, it blinks much slower (it appears to not blink at all because it is so slow).

I didn't figure it was by design to have such a large delay; I can understand only being able to make 20 or 10 or maybe even 5 API calls per tick, but the restriction seems to be effectively "less than one" per tick, judging by the way BRGC runs. I would at least expect BRGC to be able to acquire the energy/steam produced last tick once a tick, and reactor core temperature, and turbine RPM at least once every couple ticks without the computer being slowed down.