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

Big Reactors Grid Control

Recommended Posts

@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.

Link to post
Share on other sites
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. :(

Link to post
Share on other sites

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

Link to post
Share on other sites
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

Link to post
Share on other sites

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

Link to post
Share on other sites
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.

Link to post
Share on other sites

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

 

Link to post
Share on other sites

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 by payonel
Link to post
Share on other sites
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. 

Link to post
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.
Note: Your post will require moderator approval before it will be visible.

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.

Loading...


×
×
  • Create New...

Important Information

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