FormerLurker
commented
6 years ago I have never tested that scenario, thanks for mentioning it. I'll try to add some code to suppress the snapshot gcode when octolapse is disabled, and an option within the printer profile to enable this and will get back with you. Sorry you want through all of that debugging with prusa!
On Sat, Aug 11, 2018, 7:57 AM mmontminy notifications@github.com wrote:
If this is a feature request describe it here
FEATURE_REQUEST_DESCRIPTION_GOES_HERE Version of Octolapse
Octolapse Version: 0.3.1 Version of OctoPrint
OctoPrint Version: 1.3.9 When you ran into the problem, did you have diagnostic logging enabled?
Diagnostic Logging was Enabled: NO What were you doing when the problem occurred
Using the improve print quality wiki, I recently configured Octolapse to trigger snaps using an after layer change gcode command of Snap. This worked fine, until...
I started printing a number of uninteresting parts, and since I was still having some zit'ing issues caused by Octolapse, I turned it off using the disable slider on the Octolapse tab.
I started randomly having print failures, most often where the extruder stepper simply stopped working. All other aspects of the printer appeared normal, prints resumed, just no extrusion happening. Some prints worked, some failed.
Working with Prusa support, I went through all sorts of steps, factory resets, re-calibration, checking for faulty wiring, etc. Then on one nasty failure I was able to examine the Octoprint terminal, and scrolled back to see a number of errors from the printer. Scrolling back towards where they started occurring, I noticed they started in response to the "Snap" gcode.
It became obvious that with Octolapse disabled, it wasn't consuming the Snap command, and it was getting passed onto the printer, which didn't handle it well.
This is more operator error (and the printers inability to handle this better), but there seems to be things that could be done to help avoid this issue.
If Gcode Trigger is enabled, and the user disables Octolapse, a warning/reminder that their gcode will be sending an unknown command to the printer.
Update the wiki/guides to use a valid, but harmless Gcode, maybe M117 Snap. I've seen suggestions of M118 Snap. I plan to try one of these.
If Gcode trigger is enabled, and Octolapse is disabled, go into a mode where it's not fully disabled, still monitoring gcode and consuming any snap triggers. What should have happened?
Prints should have succeeded normally What happened instead?
Printer behaved badly Operating System running OctoPrint and Octolapse
OS Name: Octopi Os Version: 0.15.1 Printer model & used firmware incl. version
Printer Model: Prusa MK2/S Printer Firmware Version: 3.1.0 Browser and version of browser, operating system running browser
Browser: BROWSER_VERSION_GOES_HERE Browser OS: BROWSER_OS_GOES_HERE Link to the gcode file you were printing when the problem occurred
Link to Gcode File: GCODE_FILE_LINK_GOES_HERE Link to settings.json
Link to settings.json with all passwords removed: SETTINGS_JSON_LINK_GOES_HERE Link to plugin_octolapse.log
Link to plugin_octolapse.log: LINK_GOES_HERE Link to octoprint.log
Link to octoprint.log: LINK_GOES_HERE Link to contents of Javascript console in the browser
Link to javascript console output: LINK_GOES_HERE Screenshots and/or videos of the problem:
Screenshot/Video Links: LINKs_GO_HERE Please consider becoming a patron
If you like this project, please support my work by becoming a patron, https://www.patreon.com/bePatron?u=9588101 and consider adding a 'star' to the repository. It takes a lot of time and effort to maintain the project and respond to issues. The cost of test prints, software, cameras, printer parts, etc. can quickly add up, so every bit helps. I'm currently saving for some additional test cameras in preparation for develiping multi-camera support.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/Octolapse/issues/220, or mute the thread https://github.com/notifications/unsubscribe-auth/Af0UuO7ewioc68LwNxJ43UkKbRXDSamuks5uPtS-gaJpZM4V5KJ7 .
mmontminy
If this is a feature request describe it here
FEATURE_REQUEST_DESCRIPTION_GOES_HERE
Version of Octolapse
Octolapse Version: 0.3.1
Version of OctoPrint
OctoPrint Version: 1.3.9
When you ran into the problem, did you have diagnostic logging enabled?
Diagnostic Logging was Enabled: NO
What were you doing when the problem occurred
Using the improve print quality wiki, I recently configured Octolapse to trigger snaps using an after layer change gcode command of Snap. This worked fine, until...
I started printing a number of uninteresting parts, and since I was still having some zit'ing issues caused by Octolapse, I turned it off using the disable slider on the Octolapse tab.
I started randomly having print failures, most often where the extruder stepper simply stopped working. All other aspects of the printer appeared normal, prints resumed, just no extrusion happening. Some prints worked, some failed.
Working with Prusa support, I went through all sorts of steps, factory resets, re-calibration, checking for faulty wiring, etc. Then on one nasty failure I was able to examine the Octoprint terminal, and scrolled back to see a number of errors from the printer. Scrolling back towards where they started occurring, I noticed they started in response to the "Snap" gcode.
It became obvious that with Octolapse disabled, it wasn't consuming the Snap command, and it was getting passed onto the printer, which didn't handle it well.
This is more operator error (and the printers inability to handle this better), but there seems to be things that could be done to help avoid this issue.
If Gcode Trigger is enabled, and the user disables Octolapse, a warning/reminder that their gcode will be sending an unknown command to the printer.
Update the wiki/guides to use a valid, but harmless Gcode, maybe M117 Snap. I've seen suggestions of M118 Snap. I plan to try one of these.
If Gcode trigger is enabled, and Octolapse is disabled, go into a mode where it's not fully disabled, still monitoring gcode and consuming any snap triggers.
What should have happened?
Prints should have succeeded normally
What happened instead?
Printer behaved badly
Operating System running OctoPrint and Octolapse
OS Name: Octopi Os Version: 0.15.1
Printer model & used firmware incl. version
Printer Model: Prusa MK2/S Printer Firmware Version: 3.1.0
Browser and version of browser, operating system running browser
Browser: BROWSER_VERSION_GOES_HERE Browser OS: BROWSER_OS_GOES_HERE
Link to the gcode file you were printing when the problem occurred
Link to Gcode File: GCODE_FILE_LINK_GOES_HERE
Link to settings.json
Link to settings.json with all passwords removed: SETTINGS_JSON_LINK_GOES_HERE
Link to plugin_octolapse.log
Link to plugin_octolapse.log: LINK_GOES_HERE
Link to octoprint.log
Link to octoprint.log: LINK_GOES_HERE
Link to contents of Javascript console in the browser
Link to javascript console output: LINK_GOES_HERE
Screenshots and/or videos of the problem:
Screenshot/Video Links: LINKs_GO_HERE
Please consider becoming a patron
If you like this project, please support my work by becoming a patron, and consider adding a 'star' to the repository. It takes a lot of time and effort to maintain the project and respond to issues. The cost of test prints, software, cameras, printer parts, etc. can quickly add up, so every bit helps. I'm currently saving for some additional test cameras in preparation for develiping multi-camera support.