Logging terminal information on failed print

Get Help
1

Hi,

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.

Many thanks,

2

Just write out to the serial log. You can always sort through it from the commandline.

1 Like
3

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

4

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 (?)

5

these things are both true- keeping history might be easier, and yeah, less writes might be good.

I'm much less interested in resuming prints than I am in detecting air-prints or spagetti prints.

6

You've lost me completely there. They may both be true but they're a mutually exclusive choices in this case. This question isn't about detecting air/ spaghetti prints.

Am I missing something?

7

Tangental. It made me think of it because it's kinda-related to tracking the serial actions.

8

@foosel

Purely for my own learning, would that 'Z counter' idea work?

Thanks for looking at this, appreciate you're busy.

9

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.

10

This is not an easy problem to solve in general because of buffering, different firmware, and many different printers.

In your case, the best solution would appear to be eliminating the thermal runaway problems. Manual cancels should be dealt with on a case by case basis.

Your slicer can probably be taught to add whatever gcode you want between layers.