search

MikaylaFischler / cc-mek-scada

Configurable ComputerCraft SCADA system for multi-reactor control of Mekanism fission reactors with a GUI, automatic safety features, waste processing control, and more! Please be sure to take a look at the Wiki tab, this project has lots of docs!
https://www.youtube.com/@cc-mek-scada
MIT License
336 stars 13 forks source link

Reactor PLC PPM Crash on Server Boot #476

Closed Sharparam closed 5 months ago

Sharparam commented 5 months ago

Describe the bug Shut down the server yesterday with everything in a working (idle) state, and booted it up today. Immediately there was a warning about reactor lost, which was apparently because the PLC crashed.

To Reproduce Steps to reproduce the behavior: Unsure exactly how to reproduce it since this seemed like a chance happening, but recent things I did before shutting down the server yesterday:

Matrix reached full charge while everything was on auto control, and scrammed the reactor properly.

To experiment, I put the reactor in manual control and let it run until it was scrammed due to the turbine energy buffer filling.

Reset all the warnings and left it all on idle before shutting down the server.

Booted server up the following day, with the PLC crashing on load.

Expected behavior PLC boots normally.

Screenshots and Logs Relevant section from the PLC log.txt: https://gist.github.com/Sharparam/588688aeda1abcad5e64e8fef9668dfb

The supervisor log as it disappears:

[Tue Apr 16 21:00:18 2024] [INF] PLC_ESTABLISH: PLC (v1.7.9) [@4] reactor unit 1 PLC connected with session ID 0
[Tue Apr 16 21:00:23 2024] [INF] plc_session(0): session closed by server
[Tue Apr 16 21:00:23 2024] [INF] UNIT 1 ALARM 3 (ReactorLost): TRIPPED [PRIORITY TIMELY]

Additional context

MikaylaFischler commented 5 months ago

Thanks for the report!

These startup issues are hard to test since they can be inconsistent. I wasn't able to get this to happen when I tested the change a while back, but this issue is glaringly obvious looking at my code:

The fault counter isn't initialized to zero if it does the initialized previously undefined field, only when the function was present at startup. I'm surprised that didn't happen to me, so thanks again. The fix will be on the devel branch shortly and included in the next release.