Problem of connection. Empty buffer.
Greetings! Tell me what to look for in the settings to fix this problem: when the buffer is empty, the repetier-server writes in the console that there is no connection with the printer. Buffer emptying occurs at the end of printing. after receiving the last command, after a while, the printer restarts. The print head remains hot at the last point of its route, which spoils the finished product. After the restart, the server offers to restore printing and then the head drives off to the parking lot, as laid down by the slicer. The same problems occur during pause printing. You have to reconnect the printer so that you can control it. Firmware repetier v.1.0.4. What function monitors the buffer and leads to this result? help me please
Comments
Since it always happens at the end the guess is that one command is causing the problems. Often commands changing power consumption can lead to unexpected result. Or there is a bug in that command. Since you know nearly where it happens you could try sending the commands around there manually after enabling the heaters. Then you should see after which command connection is broken. As a test send e.g. M114 after each command to see in log if communication is still up.
21:00:55.114: N1 N1 M110
Info:POWERLOSS_DETECTED
was send in both cases by firmware. This is a message that it will loose power and server will stop any running print. Octoprint does not know that signal and will ignore it.
The big question is why do you get that message. The currently only implemented way in firmware is that it got a M416 gcode, while I only see a M415 before your pause. So please check if sending M415 triggers the message in log and if not if you have M416 set in any of the gcode events like print finished, paused, stopped.
add the break and M415 will not trigger power loss any more.
Looks like watchdog triggered a reset here. Hang happened during M104 S0 as it seems, but is not visible why. That is a frequent command as any print doe sit and normally not watchdog is triggered. On second try it also worked as planned.
Can't say more about this here.
What printer type are you using? Especially delta tend to run on low ram and that can cause any kind of problems if heap and stack run into each other. You should have at least 900-1000 byte ram on a 8 bit platform or problems will happen.
So new question is why does it happen to you and when exactly. As far as I know it always happens at the end of the print. The only log I know shows bed being disabled and M104 S0 waiting for execution. That would mean you are in Extruder.cpp in this function:
The only part that can cause such a hang is updating the printed time in eeprom. This happens when all heaters are off and it is a write to a chip connected with I2C. If that chip does not answer it will block for ever.
So try compiling with EEPROM_MODE 0 instead and see if the problem goes away. If it does we know at least what it is. At startup it would normally also hang if chip is defect, but that works. So must be something disturbing at exactly that moment. Maybe the timing that power consumption just dropped significantly made it error.
It gets written in line 1099
You can remove that part for testing. It just stores total printed time so that doe snot get updated. If it then works with eeprom and you can also change eeprom normally we can try adding a delay there and see if it helps.
whcih is most likely the part that hangs. Also try changing eeprom with eeprom editor once enabled. Just to see if it works in general and only has problems when heater got disabled. In that case we might survive by adding a delay to wait until it normalizes.