Octoprint helpfully send the last lines from the terminal to it's octoprint.log file on error (in my case I'm dealing with a bed thermal runaway issue on CR10).
Is there some way to alter the number of terminal lines it sends to the log.
I understand I can log all the terminal to serial.log but would prefer to avoid that if possible, although am reading into increasing the buffer size there as it's currently the printer firmware that's halting, not octoprint so I can still access the information there if I'm quick enough.
Ideally, for future, it would be nice to go back to the last layer/ Z access reading for resuming failed prints.
Not without modifying the source code - that number is currently hard coded to 20.
Kinda tricky to reliably determine that as fast as possible, and without an upper limit it could eat up a ton of memory depending on layer size (it would have to keep the full communication for every single layer in memory just in case of error, and then swamp the log file with that). I'm not going to do that, but I can look into making the number of lines configurable at least (within a limited range).
Thanks for coming back to me on this Gina, and for Octoprint in general. Both hugely appreciated.
Understood - could you keep the current layer, rather than the whole layer information, and just dump that as part of the output along with the current information? Increment that number by one every time a new layer is started.
That should allow you to resume the print easily and be less to track in memory but I'm not a dev so may be full of it.
@ tedder - that's certainly an option as I mentioned. That said it's always writing to disk (potentially wearing an sdcard) when perhaps not needed (?)
I’m also trying to figure out how to resume non spaghetti fails (thermal runaways or manual cancels). Is the serial log referenced above getting info from an M114 or something else? What would happen if you had a script to send an M114 upon layer completion or in the event of a thermal runaway or cancellation and then had it stored for reference upon resuming the print? I still know very little about this stuff but I was having a lot of thermal runaways and it would have been so much easier if there had been a plug-in that automatically started the print exactly where it stopped.