Octoprint with MK3 Crash Detection missed lines of gcode
Ever since i received my MK3 I have been working through trying to get Octoprint to work reliably. I think I finally have it where I can print long prints from my Pi3B over USB with a high success ratio. One of the issues I have been working through is getting crash detection to work properly period even when printing from SD. After the last changes in the latest firmware and better homing was implemented I still had layer shifts for some reason. After long sessions of troubleshooting I found that belt tension was critical (not too tight) and I also found that if you ever need to cut the cable ties coming from the back of the extruder make sure that they are set with the cable tie head up and down and do not hit the Einsey case when the homing is calibrated. If you get this wrong and it needs to find home and the cable ties are in a different spot from the calibration you will get layer shifts.
Collision detect now seems to be working real good and will catch a collision reliably without a layer shift usually. But one problem I am now seeing is that when printing from OcoPrint and a layer shift is detected it will recover and it looks like it starts back where it left off. I found last night that it does not actually start where it left off but will skip lines of gcode and then continue. This has not been evident until now because usually when a crash happened it would happen at a higher layer where it is extruding the infill. So if parts of the infill were missed you would never realize this. But testing the crash detect on a first layer or the top layer this is what happens. I wonder if there is an option to get this to work better. I know that the "Replace Filament" feature while using Octoprint works just find and picks right back up where it left off. I think that when doing this it sends a M600 to the printer and then Ocoprint is told to pause everything until this process is done. Same type of process used while preheating the bed and the extruder. I think that when a collision is detected it should be able to quickly send a pause on the serial USB just like it would for these other processes. Just throwing this out to see if anyone else has any input or ideas.
Tim