› ›

Random pausing during print

andy1989andy1989
in Bug Reports
I suddenly started experiencing random pauses during a print. Was using an older version  of Repertier server on a Pi 3. Version 7.something I think. 
Was originally installed around march this year and was working fine until a few days ago. Seamed to happen shortly after my webcam feature disappeared. 
Iv tried updating to the latest version, and it still happens.
If I plug the printer into my laptop and print from there it is okay, so must be the Pi or Repetier server that is causing the problems.

Any suggestions how to diagnose and fix the problem?

I tried the new pre-configured Pi SD image but couldn't get it to connect to my WiFi. Sounds like a common problem so I just went back to my original SD image and updated.

Any help would be greatly appreciated. 

 

Comments

  • RepetierRepetier
    Yes, wifi is a bit broken in V5 and will be fixed with new update.

    To diagnose it you would need to log a print and check at times when it happens. Typical I'd expect some communication errors when print pauses. For this some solutions depending on used firmware exist to solve them more quickly.
  • andy1989andy1989
    Just run a couple of prints, both had just one noticeable pause in them.
    I searched logs for error and wait and these two popped up.

    Not quite sure what to make of these. Any sugestions?

    > 15:03:54.182: ok 33318
    < 15:03:54.182: N33324 G1 X89.891 Y93.537 E4.52311
    > 15:03:54.211: ok 33319
    < 15:03:54.211: N33325 G1 X89.250 Y93.596 E4.55964
    > 15:03:54.228: ok 33320
    > 15:03:55.587: ok 33321
    > 15:03:55.587: ok 33322
    > 15:03:55.587: ok 33323
    > 15:03:55.588: ok 33324
    > 15:03:55.588: ok 33325
    > 15:03:55.588: wait
    < 15:03:55.588: N33326 M105
    < 15:03:55.589: N33327 G1 X88.626 Y93.541 E4.59523
    < 15:03:55.589: N33328 G1 X88.020 Y93.379 E4.63082
    < 15:03:55.589: N33329 G1 X87.452 Y93.114 E4.66642
    < 15:03:55.589: N33330 G1 X86.939 Y92.755 E4.70201
    < 15:03:55.590: N33331 G1 X86.596 Y92.412 E4.72955
    < 15:03:55.590: N33332 G1 X85.777 Y92.192 E4.77766


    < 14:15:54.626: N479 G1 E3.00000 F4200.00000
    > 14:15:54.806: ok 473
    < 14:15:54.806: N480 G1 X127.679 Y101.692 E3.28549 F1200.000
    > 14:15:54.919: ok 474
    < 14:15:54.920: N481 M105
    > 14:15:57.174: ok 475
    > 14:15:57.175: ok 476
    > 14:15:57.175: ok 477
    > 14:15:57.175: ok 478
    > 14:15:57.175: ok 479
    > 14:15:57.176: ok 480
    > 14:15:57.176: ok 481
    > 14:15:57.176: T:195.69 /195 B:50.15 /50 B@:0 @:81
    > 14:15:57.176: wait
    < 14:15:57.177: N482 M105
    < 14:15:57.177: N483 G1 X125.074 Y101.334 E3.43477
    < 14:15:57.177: N484 G1 X124.616 Y101.181 E3.46222
  • andy1989andy1989
    Checked my firmware settings (Repeteir firmware by the way), and I have the "Send "wait" when firmware is idle." option enabled.

    Ill run a print from my laptop and see if i get the same "wait" commands.
  • andy1989andy1989
    Ran a 90 minute print from my laptop and no "Wait" in the log.

    Definitely the Pi or Reptier server that is causing the problem.

    Everything on the Pi is upto date. Ran the apt-get and apt-upgrade commands last night.

    Andy sugestions?
  • RepetierRepetier
    These 2 waits are no pause and are complete in accordance with the protocols. You see firmware is firing a row of ok followed by wait. So server had buffer full and correctly did not send new commands as "ok" was missing and as soon as it received "ok" it answered with moves. This can happen when a longer move prevents freing next "ok".

    If exactly that time correlates with a pause it might be that server was paused by linux for some time intensive other job. But that is more or less impossible to detect afterwards. From 0.80.3 on it will therefore get a higher priority.
  • andy1989andy1989
    Iv not checked the exact times of the pauses, but I noticed two pause and there are two waits which seams to much of a coincident.

    I checked the niceness parameter for repetier server using the top command and its at the minimum of -20 which as far as i know means the highest priority already.

    There are a bunch of other command with nice = -20, but i don't know enough about software to know if this is normal or not, and if not what to do about them.

    The command constantly at the top of list when im not printing, and using 1.6% cpu is mjpg streamer. Is this worth killing and trying a print without? 




  • RepetierRepetier
    1.7% is nothing if you have 400% on pi 3, so that should not be the issue.

    As you already have nice -20 you are using wheezy I guess. On Jessie it gets ignored with current release since I need to reduce limit before it works.

    Other processes with -20 should be kernel processes also needing high priority.

    Maybe run top on ssh console while printing to see what takes high cpu when hang happens, but would require fast reaction if it is just a short running process like a cron job doing some regular tasks like cleaning logs. As I said log show a possible delay in communication but also show server reacts immediatly after it gets the data. So is it a long move that delays because it blocks the input or is there a hang on communication for some unknown reason.
  • sangokusangoku
    Hellow. Is there any update on the issue? im having the same problems as described here. Latest server version running it on a raspbery pi w zero on base install. 
  • RepetierRepetier
    There is no general problem causing pauses. You need to check console if you experience communication errors which can cause this of course. Also make sure to not have too small gcode segments. With ping pong mode disabled you can normally send 300 lines per second without problems. If your model is so fine that it exceeds it the printer will also get problems getting to speed.
  • sangokusangoku
    In marlin i have 
    #define BLOCK_BUFFER_SIZE 16
    Does that mean that i need to set the input buffer size in the raptier to 16 as well? 
    I am connecting to it via an ESP3D via direct pin connectioon. 

  • RepetierRepetier
    No, that is just how many moves marlin caches. The input buffer is most likely 127 byte long.
  • RepetierRepetier
    ESP3D - does that mean you use tcp/ip over wifi for communication? In that case you might get pauses if wifi gets interrupted. I'm not a big fan of using wifi for sending serial data as it is not stable enough especially if I look at my wifi network. Leases, other devices connecting, delays due to big data packets getting send. No idea what will happen there all the time.
  • TintinTintin
    edited November 2020
    Hi folks,
    I know the thread is a bit old, but I have experienced very similar issues and found a solution. The problems I had :
    • Random pause of the printhead (causing blobs on the print beacause of the pressure buildup in the nozzle) with a "wait" command received
    • Warnings like "Missed line detected - correcting buffer usage.", or "Seems like we missed a ok - continue sending." at random moments
    What I tried and did not work :
    • Increasing the baud rate in printer firmware and repetier server (on raspberry pi 3) from 250000 to 460800
    What I tried and did work :
    • Changing the original USB cable (~1.5m long) for a shorter (~50cm long) and thicker. Now I have no more warnings in the logs, and no more random stops of the printhead.
    Hoping this can help someone else.

    My config : reprap µdelta original with Teensylu PCB, Repetier server v0.93.1, repetier host v2.1.6, Cura v4.8

  • TintinTintin
    edited February 2021
    Hello again,
    An update about the problematic message "Missed line detected - correcting buffer usage" I had every few seconds. I don't think changing the USB cable for a shorter thicker one helped, in the end. At the moment yes, but then the problem came back.
    I got the idea from this thread that it may be due to a process on my Raspberry Pi messing with the Serial USB ports. And then I remembered : I once installed a software which was automatically started by the crontab, and this process involved serial communication over USB. I disabled the crontab line and killed the process. Now the problem is gone : no more missed line, and no more random pauses during curved movements of the print head !
    If you still have an issue and don't know if another process may be messing with serial ports, you can always have a fresh Raspbian install on your Pi. That way, any problematic program would disappear. It would have done the job for me.
    Good luck

Sign In or Register to comment.