Something is limiting the max speed of our printer...



  • Hello,

    Curious if any one has insight on our issue.

    Brief Background:

    Our printer is actually a modified CNC gantry with servo motors driving the x and y axes. It works, but the max speed is being limited to 49mm/s (~3000mm/min) by something.

    The Duet board sends step/direction signals for each axis thru a "pulse to quadrature" converter and into the servo drives (our servo drives cannot receive step/dir directly).

    For all intents and purposes, it ends up being just like a normal printer, except that we can monitor the position and velocity through the servo drive software.

    Issue & Attempts to Fix:

    • Regardless of slicer speed settings or firmware configs, the max velocity is being limited to about ~49mm/s. However, files set to print below 49mm/s print normally and achieve their max velocities as expected.

    Adjusting firmware settings were no help in the end. Here is the current firmware config for what I think are the obvious settings:

    M566 X20000 Y20000 Z21 E350 ; Set maximum instantaneous speed changes (mm/min)
    M203 X12000 Y12000 Z1200 E1200 ; Set maximum speeds (mm/min)
    M201 X18000 Y18000 Z500 E250 ; Set accelerations (mm/s^2)

    We've also tried different slicers, and ensured that any "auto-cooling" or first layer speeds are not to blame.

    Since our printer setup is non-traditional, we questioned whether the servo drives are limiting the speed. To test that, we did two tests: a print below 49mm/s and a print above that speed. Since our servo software gives position feedback, we could compare where the Duet thinks the print head is to where the servo thinks it is. If the Duet thinks that it is printing faster than the servos are moving, there should be a discrepancy in the position. But our tests showed that the position was the same between the two. (As a side note, the Duet gets no positional feedback from the servos)

    The above tests are the reason we currently think the Duet firmware settings may be the limiting factor, but we are not 100% sure. Anything obvious that we're missing?

    I appreciate any feedback you may have!



  • What kind of extruder do you have on there? It's being limited to 20 mm/s. If it's a large diameter nozzle and 1.75mm filament, it might be hitting that limit?



  • @jpomo10 I agree, try increasing the values for your extruder limits and see if it persists. They are a bit low for max speeds I think.


  • administrators

    Here are some other things that can limit the speed:

    • The M204 settings. The default is 10000mm/min for both travel and printing moves.
    • The rate at which step pulses can be generated. This depends on your steps/mm, taking into account the microstepping you use. External drivers have a lower microsteps/sec limit because they have lower step pulse frequency limits, as defined by the M569 T parameter and rounded up to a whole number of step clocks. So you might need to reduce microstepping. To see if you are hitting the limits, run M122 after executing some fast moves and look at the hiccup count.
    • If bed compensation is active then the Z maximum speed and acceleration can limit the XY speed.


  • Thank you for your replies.

    So far we have tried:

    1). Increasing extrusion speeds (and associated acceleration values)
    2). Disabling bed compensation
    3). Checked that our slicer speed settings are not exceeding the M204 limits.

    We ran M122 a few times which yielded hiccup counts as low as ~200000, and as high as 1800000 (copied below).

    Since it may be important to note, we are sending step/dir signal directly from the pads labeled "Test" points on the Duet, not the steps that have been processed by the in-board drivers.

    Unfortunately, I'm not sure what the microsteps/sec limit might be for our servo drives.

    Also, here is a snippet from our config:

    ; Drives
    M584 X0 Y1 Z11 ; Sets Z-Axis to drive 11 (LCD header)
    M569 P0 S1 T15 ; Drive 0 goes forwards
    M569 P1 S1 T15 ; Drive 1 goes forwards
    M569 P2 S1 T15 ; Drive 2 goes forwards
    M569 P3 S0 ; Drive 3 goes forwards
    M569 P11 S0 T50 ; Drive 11 goes forwards
    M584 X0 Y1 Z11 E3 ; Apply custom drive mapping (Z-Axis to drive 11)
    M350 Z16 E16 I1 ; Configure microstepping with interpolation
    M92 X200 Y200 Z640 E837 ; Set steps per mm

    M122
    === Diagnostics ===
    RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS) running on Duet Ethernet 1.02 or later
    Board ID: 08DGM-95BNL-MGPSJ-6JTD8-3SJ6T-11WHZ
    Used output buffers: 3 of 20 (7 max)
    === RTOS ===
    Static ram: 28380
    Dynamic ram: 95456 of which 0 recycled
    Exception stack ram used: 420
    Never used ram: 6816
    Task NETWORK ready, free stack 324
    Task HEAT blocked, free stack 1256
    Task MAIN running, free stack 3560
    === Platform ===
    Last reset 00:13:25 ago, cause: software
    Last software reset time unknown, reason: User, spinning module GCodes, available RAM 6920 bytes (slot 3)
    Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff
    Error status: 0
    Free file entries: 9
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 5.2ms
    MCU temperature: min 36.4, current 38.8, max 39.8
    Supply voltage: min 11.8, current 11.8, max 12.2, under voltage events: 0, over voltage events: 0
    Driver 0: standstill, SG min/max 0/14
    Driver 1: standstill, SG min/max 0/12
    Driver 2: standstill, SG min/max not available
    Driver 3: standstill, SG min/max 0/380
    Driver 4: standstill, SG min/max not available
    Date/time: 2018-10-16 08:53:02
    Slowest loop: 846.75ms; fastest: 0.07ms
    === Move ===
    Hiccups: 1886943, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 171, MaxWait: 4293829178ms, Underruns: 0, 0
    Scheduled moves: 301, completed moves: 301
    Bed compensation in use: none
    Bed probe heights: 0.000 0.000 0.000 0.000 0.000
    === Heat ===
    Bed heaters = -1 -1 -1 -1, chamberHeaters = -1 -1
    Heater 1 is on, I-accum = 0.4
    === GCodes ===
    Segments left: 0
    Stack records: 2 allocated, 0 in use
    Movement lock held by null
    http is idle in state(s) 0
    telnet is idle in state(s) 0
    file is idle in state(s) 0
    serial is idle in state(s) 0
    aux is idle in state(s) 0
    daemon is idle in state(s) 0
    queue is idle in state(s) 0
    autopause is idle in state(s) 0
    Code queue is empty.
    === Network ===
    Slowest loop: 8322.43ms; fastest: 0.01ms
    Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
    HTTP sessions: 1 of 8
    Interface state: 5
    === Expansion ===


  • administrators

    The problem is that the T15 parameter in your M569 commands is limiting the step rate to a little over 30kHz. Does it need to be that high? Check the manual for your servo drives for the minimum timings.



  • @dc42 Decreasing the parameter T from 15 did not seem to make a difference, however, removing T or setting T0 seemed to solve the issue. Is this behavior normal? Thank you for your help!


  • administrators

    Did you reduce all the T parameters in M569 commands in config.g, and then restart the Duet? The firmware remembers the highest T parameter it has seen, and uses that.

    With T0 you are likely to get missed steps when using external drivers. You probably need at least T1 or T2.



  • This post is deleted!


  • @dc42 I will re-test, but I did reboot after changing the parameter each time. I also increased T, which did make a difference (max speed was even lower).

    I reduced the parameter for X and Y only, since the Z-Axis seemed to be ok.

    Update: With both axes set to T1, the the max speed was still limited. Compared to previous tests using just a square with only x or y movement at any given time, this was a figure 8. M122 now appears to show incomplete moves:

    === Platform ===
    Last reset 00:03:56 ago, cause: software
    Last software reset at 2018-10-19 14:48, reason: User, spinning module GCodes, available RAM 6816 bytes (slot 1)
    Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff
    Error status: 0
    Free file entries: 9
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 0.0ms
    MCU temperature: min 37.9, current 38.2, max 38.7
    Supply voltage: min 11.8, current 11.9, max 12.1, under voltage events: 0, over voltage events: 0
    Driver 0: open-load-A open-load-B, SG min/max 0/14
    Driver 1: open-load-A open-load-B, SG min/max 0/12
    Driver 2: standstill, SG min/max not available
    Driver 3: ok, SG min/max 0/395
    Driver 4: standstill, SG min/max not available
    Date/time: 1970-01-01 00:00:00
    Slowest loop: 646.41ms; fastest: 0.08ms
    === Move ===
    Hiccups: 1243034, StepErrors: 0, LaErrors: 0, FreeDm: 174, MinFreeDm 150, MaxWait: 0ms, Underruns: 0, 0
    Scheduled moves: 1237, completed moves: 1215
    Bed compensation in use: none
    Bed probe heights: 0.000 0.000 0.000 0.000 0.000

    Not sure where to go from here. Our servo drive manual states that the drives are updated at a rate of 1kHz, but there is no mention of a microsteps/sec limit . The Rep-Rap wiki shows an "extended" configuration for the parameter T, like: Taa:bb:cc:dd in which 'minimum step pulse' and 'minimum step interval' can be configured. Is this a way forward?

    Thanks!


 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.