Big Reactors Grid Control

[Vexatos 9]

5 minutes ago, Arcanox said:

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. 

That is possible, but has nothing to do with OC. That would require a change on the side implementing the methods, so ER in this case.

[XyFreak 36]

From what zero told us here I was under the impression that he already is using the api as it's supposed to be used.

@payonel I did not know the github issue gained some steam during the last couple of days. Thanks for bringing that to my attention.

You've been saying that oc is not a realtime system and i agree. if yielding after each component api call is the intended bebaviour i'd like to see that documented somewhere. Also that limit should be enforced for all mods/apis. And if that's really the case then ... let's say I'm going to be sad

[XyFreak 36]

1 hour ago, payonel said:

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

I'm not sleeping in a 'service' thread, I'm using timers

[Vexatos 9]

2 minutes ago, XyFreak said:

From what zero told us here I was under the impression that he already is using the api as it's supposed to be used.

@payonel I did not know the github issue gained some steam during the last couple of days. Thanks for bringing that to my attention.

You've been saying that oc is not a realtime system and i agree. if yielding after each component api call is the intended bebaviour i'd like to see that documented somewhere. Also that limit should be enforced for all mods/apis. And if that's really the case then ... let's say I'm going to be sad

A component call can do either: It depends on what the mod author implementing the method wants. They can set a component call to last the entire tick, or allow multiple executions per tick.

[Tahak 1]

Case solved, message no more needed.

Cheers

[payonel 21]

30 minutes ago, XyFreak said:

if yielding after each component api call is the intended bebaviour i'd like to see that documented somewhere.

Read, "where the call takes at least one server tick"

Here: https://github.com/MightyPirates/OpenComputers/blob/f5c19e9e7e0006d3403c7bf0b44dfb970cee8a2f/src/main/java/li/cil/oc/api/machine/Callback.java#L43-L59

[XyFreak 36]

58 minutes ago, payonel said:

Read, "where the call takes at least one server tick"

Here: https://github.com/MightyPirates/OpenComputers/blob/f5c19e9e7e0006d3403c7bf0b44dfb970cee8a2f/src/main/java/li/cil/oc/api/machine/Callback.java#L43-L59

THANK YOU!

 

@ZeroNoRyouki You know about that one don't you? If that fixes things... I need to run around and apologize to ppl... >_>

[payonel 21]

XyFreak: btw, if your setup docs, "Don't forget to add brgc_reactor, brgc_turbine and brgc_grid to your /etc/rc.cfg if you want to start the controller at boot time:"

You can also ask the user to run `rc brgc_reactor enable` to add it to the configs

 

[XyFreak 36]

Oh yeah, that's a thing by now. I should change that as it's "way" easier

[ZeroNoRyouki 7]

Hi,

I've just posted and updated version of ER on Curse (It's under review right now). All the Callbacks are back to the old-direct-call-we-dont-care-about-threads-because-who-knows way of the original code. You must break and replace all your computer ports to see this in action

Z

[XyFreak 36]

Hmhm,

I hope this "old-direct-call-we-dont-care-about-threads-because-who-knows" doesn't imply: We're not thread-safe

I'll grab it as soon as I can and run it in my test world with some larger setups.

 

On a different note, I'm currently preparing a new release of BRGC. Here's what's in so far (subject to change):

• Support for mekanism induction matrix
• Greatly reduced the number API calls for setting reactor fuel rods
• Fixed a bug where the grid controller would not set the reactors output rate to the optimum but leave it as is when coming out of "HOLDING CHARGE" mode
• Fixed the Grid GUI for very slim screen setups. A 3x1 T3 screen setup looks pretty sexy now!
• The Tabs for "Reactors" and "Turbines" will be omitted if there's not enough space for them. (Only being calculated on GUI startup though)
• T2 Screen setups finally look good. Resolution wise they're close to the T3 screens now. The coloring for some of the grey is off though. Nothing I can change about it - they're limited like that

If you have anything else you'd like to see - now is your chance!

EDIT:

Here's how T2 screens look now

EDIT2:

It's safe to say that T1 screens are not supported (apart from not having touch controls....)

[XyFreak 36]

On 22.1.2018 at 5:36 AM, Seiver said:

my reactors refuse to calibrate

 

ER - 0.4.5.44

OC - 1.7.1.43

Sorry for reacting to your post just now. I just got notified about it and as you can see, a lot was going on.

brgcctrl is already telling you what's wrong: You need to supply the reactors address or at least a partial address (read 3 or more characters of the address). Also the API issues we've been discussing here are propably responsible for your reactor not being (properly) calibrated so please wait a while longer until zeros fix is up on curse.

[Michiyo 28]

Just now, XyFreak said:

Sorry for reacting to your post just now. I just got notified about it and as you can see, a lot was going on.

brgcctrl is already telling you what's wrong: You need to supply the reactors address or at least a partial address (read 3 or more characters of the address). Also the API issues we've been discussing here are propably responsible for your reactor not being (properly) calibrated so please wait a while longer until zeros fix is up on curse.

That's my fault.. I could have sworn I approved this post when it was posted, and it was sitting in my queue as seen.  I noticed it when I went back and read a few pages of the thread.

[XyFreak 36]

Oh so you have to approve posts before they trigger notifications? THAT explains a LOT. Thanks for letting me know

[Michiyo 28]

3 minutes ago, XyFreak said:

Oh so you have to approve posts before they trigger notifications? THAT explains a LOT. Thanks for letting me know

I have to approve posts from members with less than X (Liz edit: that's currently set at 1)  number of posts.  After they reach the minimum their posts don't need approval, and until they are approved they don't show up in the thread at all.

[ZeroNoRyouki 7]

@XyFreak Yes, the code is not thread safe. It never was (until the switch to the non direct calls made it so). But it worked fine since 1.7.10 so this will be probably OK for a stop-gap solution

I have to redesign the whole thing

 

 

[XyFreak 36]

@ZeroNoRyouki gotcha. (fingers crossed)

If you need input/ideas on anything thread-safety related feel free to hit me up with a pm or something.

[Tahak 1]

I can confirm that with newest version (1.10.2) it works fine for now

[XyFreak 36]

Ditto, the 1.10.2 version runs fine with 9 turbines and a reactor. I also noticed that a bug i fixed in brgc makes the active reactor controller run smooth like butter now >_> I'm actually glad I was kinda forced to look at the rod level control code again... ^^"

[Arcanox 0]

8 hours ago, ZeroNoRyouki said:

Hi,

I've just posted and updated version of ER on Curse (It's under review right now). All the Callbacks are back to the old-direct-call-we-dont-care-about-threads-because-who-knows way of the original code. You must break and replace all your computer ports to see this in action

Z

Put this on my server and it works great! My computer is buttery smooth with all three BRGC programs and the GUI running. Thank you so much!

[ZeroNoRyouki 7]

Good!

[XyFreak 36]

It's been a WHILE - but it is finally time...

Big Reactors Grid Control Version 4.2.6 has been released!

Changelogs:

 - Greatly reduced the number of API calls for setting reactor fuel rod levels.
 - Fixed a bug where the reactor controller would miscalculate the fuel rod offsets with sub 1% precision.
 - Fixed a bug where the grid controller would not set the reactors output rate to the optimum but leave it as is when coming out of "HOLDING CHARGE" mode.
 - Partially rewrote calibration code for reactors to remove "magic values".
 - The Tabs for "Reactors" and "Turbines" will be omitted if there's not enough space for them (only calculated on GUI startup).
 - Fixed GUI resolution misbehaving on T2 screen setups. The colors are still off due to colorspace limitations on those screens.
 - Fixed grid UI for very slim screen setups. Try a sexy 3x1 T3 screen setup!
 - Added experimental support for mekanism induction matrix. J -> RF conversion ratios can be set in mekanism config.
   Conversion ratios other than 5:2 (J:RF) will confuse the controller.
   The ratio for the induction matrix can be changed in /usr/lib/brgc/energy_storage_component.lua
 - Added support for thermal expansion energy cells.

In order to upgrade from previous versions, you just need to run the installer again.

If you've used BRGC with any ER version between 0.4.5.40 and 0.4.5.45 you might want to upgrade to 0.4.5.46 now and remove your brgc configuration afterwards to recalibrate your setups.

I've changed some of the calibration code for reactors so those might calibrate a lot slower. If you feel calibration does not terminate, please send me a schematics of your reactor.

Also... I can't stress enough how sexy this looks:

It's pure coincidence the spacing works out so well too

[BrisingrAerowing 12]

Yay!

[Arcanox 0]

5 hours ago, XyFreak said:

It's been a WHILE - but it is finally time...

Big Reactors Grid Control Version 4.2.6 has been released!

Changelogs:

 - Greatly reduced the number of API calls for setting reactor fuel rod levels.
 - Fixed a bug where the reactor controller would miscalculate the fuel rod offsets with sub 1% precision.
 - Fixed a bug where the grid controller would not set the reactors output rate to the optimum but leave it as is when coming out of "HOLDING CHARGE" mode.
 - Partially rewrote calibration code for reactors to remove "magic values".
 - The Tabs for "Reactors" and "Turbines" will be omitted if there's not enough space for them (only calculated on GUI startup).
 - Fixed GUI resolution misbehaving on T2 screen setups. The colors are still off due to colorspace limitations on those screens.
 - Fixed grid UI for very slim screen setups. Try a sexy 3x1 T3 screen setup!
 - Added experimental support for mekanism induction matrix. J -> RF conversion ratios can be set in mekanism config.
   Conversion ratios other than 5:2 (J:RF) will confuse the controller.
   The ratio for the induction matrix can be changed in /usr/lib/brgc/energy_storage_component.lua
 - Added support for thermal expansion energy cells.

In order to upgrade from previous versions, you just need to run the installer again.

If you've used BRGC with any ER version between 0.4.5.40 and 0.4.5.45 you might want to upgrade to 0.4.5.46 now and remove your brgc configuration afterwards to recalibrate your setups.

I've changed some of the calibration code for reactors so those might calibrate a lot slower. If you feel calibration does not terminate, please send me a schematics of your reactor.

Also... I can't stress enough how sexy this looks:

It's pure coincidence the spacing works out so well too

I just updated BRGC and now it won't start my reactor. I did delete the /etc/br_control.cfg file before starting the services again. Every time I try and turn the reactor on, it just immediately goes to the "ERROR" state without heating up the reactor at all. It didn't re-create the /etc/br_control.cfg file at all.

 

EDIT: Apparently something really screwed up with my power system while updating and the P2P nodes weren't getting power, so the reactor filled up with steam. Fixed now.

[hron84 1]

@Arcanox I read the update, but besides that, if you sometime find yourself with a bugged brgc setup, I reinstalled the hdd, it solved all of the issues for me. It seems like OpenOS is not a Windows, but some solutions just works on that too :-)