› ›

Repetier Server Pro probes Bad after completed print

KartoffelKartoffel
in Bug Reports
I don't know if it's a bug or I have miss configured something but it just cost me 20€, A lot of work and my printer is now damaged. The problem is the following;
After a print is completed (not the print job in Repetier) it tries to rehome the z axes resulting in the hot nozzle destroying my part. I observed this once before on a calibration cube and thought it was just a bug in my g code (Because it did not happen the next 10-15 prints). Then I printed a large part today and it smashed itself in the part luckily I stopped it before it got worse and bend the axes. Because I powered off to stop it the "Retten" feature turned against me and instantly tried to rehome xy resulting in even more damage. (Also the "Retten" feature has a bug where even if you press the STOP button it tries to rehome again). I did not configure any custom gcode in Repetier server also I observed the gcode from my part and there was nothing about rehoming z axes.
As a slicer I use Cura (4.6.1) with the Cura plugin for Repetier and I attached my Repetier Firmware and the GCode. 
(I used Octoprint with the exact same setup before so the bug must have something to do with Repetier server)

Comments

  • RepetierRepetier
    Never saw this behaviour, so a bit hard to say what exactly is the problem.
    First thing to check is firmware - you said repetier-firmware and latest 1.0.4 has special support for the rescue function. E.g. on usb disconnect for more than a few seconds it will move to a park position. Same feature can also cause an automatic continue after reconnect running the 2 rescue scripts Run on connect and Rescue to continue the print. So please check this for understanding the behaviour after a reset which is the same. You can also disable the automatic continue by setting the continue time to 0.

    The main problem seems to be the home after print running you into these problems. I know that is not a feature of server and surely is dangerous if you don't have z max homing. So please check the event dependent scripts in server configuration if they contain the home command. That would be the only logical place if it is not contained in the gcode.
  • KartoffelKartoffel
    Ok I got closer to a solution; The rehome has noting to do with wrong configuration but with the "send Gcode". In my first post I inspected the Gcode using the save function in Cura directly saving it to the disk. But the error accrues with the Repetier Cura plugin while sending it. It seems that the plugin sometimes messes up and sends the Gcode 2 times to Repetier server which results in the printer trying to print the part another time in the same print job. The Repetier Cura plugin is also absolutely unstable, so I will just stop using it for the time and report the error on GitHub.
Sign In or Register to comment.