Temperature Offset leads to unrecoverable Crash of the connection
karawedi opened this issue · 3 comments
The problem
Hello everyone!
I just begin experimenting with the temperature offset features of Octoprint.
The following things happen, after setting my desired offset:
- The Print Job starts.
- The Tool and the Bed will be heated to the correctly calculated temperatures.
- Octoprint will attempt to start the actual print, panic, and disconnect.
The GCode works fine without the offset being set.
Safe-Mode does not change anything.
Heres my Sysinfo Bundle:
octoprint-systeminfo-20231101152737.zip
And a screenshot of the relevant Log Entries, including the trace:
It appears to me, as if the set offset is not being transfered into some parts of the application. However, I haven't yet dug deep enough into the code to fully understand the trace.
Thanks a lot to everyone contributing to this project! If I can further assist you with Information, let me know.
If I find the time, I'll attempt to fix aswell.
Did the issue persist even in safe mode?
Yes, it did persist
If you could not test in safe mode, please state why ("currently printing" is NOT an excuse!)
No response
Version of OctoPrint
1.9.3
Operating system running OctoPrint
Docker
Printer model & used firmware incl. version
Anycubic Kobra Neo
Browser and version of browser, operating system running browser
No response
Checklist of files to include below
- Systeminfo Bundle (always include!)
- Contents of the JavaScript browser console (always include in cases of issues with the user interface)
- Screenshots and/or videos showing the problem (always include in case of issues with the user interface)
- GCODE file with which to reproduce (always include in case of issues with GCODE analysis or printing behaviour)
Additional information & file uploads
No response
Can you share a GCODE file with which to reproduce this? There seems to be something wrong with parsing of a contained temperature line that is leading to this.
I was able to reproduce this with a test GCODE file containing only an incomplete M109 command:
M109 S
The above commits protect the code against stuff like this now. It would still be good to see a GCODE file with which you were able to reproduce this issue, to make sure this was indeed the culprit.
If so, the next question would be why the slicer is producing broken temperature commands that are missing the actual target to set.
1.10.0 has been released.