› ›

(RADDS) Printer often stops for a short time while printing fast

moelskimoelski
edited November 2016 in General

Hello,

I just build my new SprakCube XL and almost everthing works fine. But there is one problem when printing fast ... (setting the printspeed > 130%).

My setup : Raspberry Pi 2B+ with Rep. Server 0.80 PRO, RADDS 1.5 with DUE and latest Firmware.

If I print at 100% everythings works as expected. No short interruptions while printing and no blobs. But if I increase the printspeed to > 130% things getting worse ... The printer often makes little stops while printing. And that leads to small nasty blobs.

If I watch the LCD display while printing I can see that the Puf value get´s near to zero when the stops appear. And that happens often if there are a lot circles / curves to print.

I looked into the configuration and there are two values:
#define PRINTLINE_CACHE_SIZE 64
#define MOVE_CACHE_LOW 10

Can I change something here to have more Cache size? The DUE has a lot memory ...

Any help would be much appreciated.

Dominik

Comments

  • RepetierRepetier
    You are on the right trace. Low buffer causes this effect and many small segments enforce this effect. Then usb connection can not send enough data to refill. Bigger buffers are only a partial solutions as you can still make it happen with enough small segments - it just gets more unlikely that so many lines appear, so it will happen less often. But then path planning takes longer. Not sure how far we can go on due. For avr I never exceeded 32 but also never have your problem. Maybe I'm not printing as fast as you do. Speaking of speed - what speed are you using? Printing with 60mm/s is no problem for my models. Or do you make your models super precise so they create so many small segments? Slic3r can reduce the number of segments if you allow small unvisible imperfections.

    MOVE_CACHE_LOW could be increased. That should throttle speed a bit earlier. With your bug cache size, 30 should be no problem. 

    Make sure pin pong mode in connection settings is disabled and buffer is 127 byte. You need all the speed you can get from these 2 optimizations.
  • moelskimoelski
    Hi !

    what speed are you using?
    It´s not that fast ... First try was 55mm/s and now 80mm/s.

    Now I have tested with
    #define PRINTLINE_CACHE_SIZE 80
    #define MOVE_CACHE_LOW 30

    But I still get interruptions.

    Make sure pin pong mode in connection settings is disabled and buffer is 127 byte
    Where can I set these options? Can´t find it in the online configuration nor in the sources.

  • moelskimoelski

    One additional question ...

    Would it help to use higher baud rates? Actually I use 115200. Maybe I should give 230400 a try?

  • RepetierRepetier
    ping pong is set in server printer settings general tab.

    230400 baud might help a bit, but most delay is from latency during usb->serial conversion.

    For a test how many lines you can send send manually
    M111 S24
    Then print a file and see how many lines in how many seconds got printed. This makes firmware to just send back ok on every command. We use this for communication testing.

    Also try printing with console visible to see if you have communication errors. If you have frequent errors especially in fine parts that can also slow down communication and cause the same effect.
  • moelskimoelski

    Hi !

    I will try your suggestions this evening.

    ping pong is set in server printer settings general tab.
    I can set PingPong only in Repetier-Host or is it available in the webserver version, too?


    but most delay is from latency during usb->serial conversion

    So it could be a good idea to connect the DUE with a direct serial connection to the raspberry pi?
    I have a DUE board which has pinouts for the serial port instead of the USB / serial converter.


  • RepetierRepetier
    You should disable ping ping! This doubles speed. It is in server settings -> general if you are printing over the server. Host has it if you print with serial connection over host and not submitted through server.

    DUE native pin does no serial conversion and might also have less latency. Would be a try. Haven't checked what is faster. But you loose the reset on connect.
  • moelskimoelski
    Hi !

    I checked it and Ping Pong is disabled.
    And setting the Cache values higher didn´t change something.

    I did a Test with "M111 S24"
    In one second my Printer receives / consumes ~350 lines of GCode. Don´t know if this value is ok?

    Now I made a print with logging. You can download the print log here:
    There is one communication Error:
    <  3:53:25.625: N51 G92 E0
    >  3:53:56.627: Warning: Communication timeout - resetting communication buffer.
    >  3:53:56.628: Connection status: Buffered:112, Manual Commands: 2, Job Commands: 5000
    >  3:53:56.628: Buffer used:112 Enforced free byte:23 lines stored:7

    And if you look at line 2304 for example ...
    N1114 G1 X145.685 Y132.187 E29.6365 was send at 3:54:42.054
    and the ok 1114 came at 3:54:44.415
    That are ~2,5 seconds of delay. Is that normal?

  • RepetierRepetier
    350 lines is good. One thing I recently had was that some users have set extruder start speed very low which forces low speeds making it go fast/slow. When they started setting extruder start speed to 20-40 it went away.
Sign In or Register to comment.