Unwanted pause during printing!!!

edited April 2017 in Repetier-Server
As i've already reported i've this annoying problem with Repetier Server and Raspberry PI 3.
During printing stops random like in the video, of course, creating imperfections.
Probably the data transfer on USB port is lost for a moment, and then recovers.
From the print log I do not see anything abnormal.
Tried same gcode with "Octoprint" without any issue, same good result when printing from SD, so it's not a Raspberry or printer problem!!!
I hope
that as soon as it's released a new server version that fixes this annoying problem.
If the product was free we should be content, but having paid Repetier Server license and i wish more reliability.



  • Are you using the same sd card image for octoprint?

    The reason I ask is that linux seems to freeze sometimes when some wlan stuff is running and that means no new data for the print. It is not clear which wlan action this causes and if it is one called from server or just a effect of using networkmanager instead of the default network config you get. At least with one user we could see that exactly in the pauses syslog did show a lease expiry I think.

    So if you have different images, install server on octoprint image so it does not use the networkmanager and does not control wifi and see if it still happens.
  • No, i use different SD image, your and the SD image for Octoprint downloaded from their website.
  • Just as I guessed. Would be great if you could confirm that the problem on octoprint image is not present with repetier-server. Then I know I'm searching in the right direction for the solution.
  • Ok, installing now Repetier Server on Octoprint SD image, i keep you informed.
  • edited April 2017
    Hello Roland, i inform you that I renamed the file "/usr/local/Repetier-Setup/bin/manageWifiAccess" (simply add an underscore at the end), reboot my Raspberry PI 3, and now the problem has disappeared!
    So i can confirm, the problem is the wifi network manager! ;-)
  • DAMN!
    I'm sorry, the problem is here again!
    Now i try to install a fresh copy of Repetier Server on Octoprint SD image...
  • Our image uses networkmanager instead of the default wifi with spa_supplement so even if we do not query it, it is running. But as a result we now know that it even happens if we would not query. Hope octo image has a better solution here.
  • edited April 2017
    Two news, one bad and the other nice.
    Tried with "OctoPrint SD", i've only installed Repetier Server for Armel (with dpkg) and recovery my backup from "/var/lib/Repetier-Sever" of my other "Repetier Server SD", same printing issue, but if i print with the same SD with Octoprint all work fine, both daemon are in execution.
    Then i try to disabled the "write log during printing" in your original SD image and at the moment, after 2 hours, no issue with Repetier Server.
    My SD is Class 10, so please check the "sd write" routine of the log during printing, I strongly suspect that it's the problem.
  • I have read that octoprint also can get pauses if logging is on so you might be right that it is a problem. As it writes in receiving thread it can block sending new lines. I think in general it can write fast enough but at some situations linux might also be writing so it blocks a bit too long. Will see if I can add a extra logging thread so it is only reading in own thread and logs get buffered until written.
  • One more question - are you also storing timelapse videos? Might be an additional source since that requires also writing files that could delay log writing in addition.
  • edited April 2017
    No, timelapse disabled.
  • Maybe this helps:

    On a similar topic, maybe not directly related to your issue: I noticed that if I use Cura (2.5) for slicing there are fewer interruptions compared to slic3r Prusa Edition 1.34.1. Could not figure out the source of the problem.
  • I could verify that logging while printing can cause pauses. Linux simply blocks the write for a few seconds for some reasons and this prevents sending next line. For next release I have decoupled this so that causes no pauses any more then even with log enabled.

    Different slicers generate different size of moves. Since it is blocking problem it only gets visible when the buffers run empty. So while printing long it is likely not to be visible. On curves slicers may have different number of moves so the one with more moves will get more likely a visible short hang.
  • Repetier said:
    For next release I have decoupled this so that causes no pauses any more then even with log enabled.
    Now, I cannot wait for 80.4 Release even less!!!Pleeeeeeeeeeeeeeeeeeeease?
Sign In or Register to comment.