Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

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

    Scheduled Pinned Locked Moved
    My Duet controlled machine
    4
    10
    2.0k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • HebigTundefined
      HebigT
      last edited by

      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!

      Phaedruxundefined 1 Reply Last reply Reply Quote 0
      • Duckleundefined
        Duckle
        last edited by

        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?

        1 Reply Last reply Reply Quote 1
        • Phaedruxundefined
          Phaedrux Moderator @HebigT
          last edited by

          @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.

          Z-Bot CoreXY Build | Thingiverse Profile

          1 Reply Last reply Reply Quote 1
          • dc42undefined
            dc42 administrators
            last edited by dc42

            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.

            Duet WiFi hardware designer and firmware engineer
            Please do not ask me for Duet support via PM or email, use the forum
            http://www.escher3d.com, https://miscsolutions.wordpress.com

            1 Reply Last reply Reply Quote 1
            • HebigTundefined
              HebigT
              last edited by HebigT

              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 ===

              1 Reply Last reply Reply Quote 0
              • dc42undefined
                dc42 administrators
                last edited by

                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.

                Duet WiFi hardware designer and firmware engineer
                Please do not ask me for Duet support via PM or email, use the forum
                http://www.escher3d.com, https://miscsolutions.wordpress.com

                HebigTundefined 1 Reply Last reply Reply Quote 0
                • HebigTundefined
                  HebigT @dc42
                  last edited by

                  @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!

                  1 Reply Last reply Reply Quote 0
                  • dc42undefined
                    dc42 administrators
                    last edited by dc42

                    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.

                    Duet WiFi hardware designer and firmware engineer
                    Please do not ask me for Duet support via PM or email, use the forum
                    http://www.escher3d.com, https://miscsolutions.wordpress.com

                    HebigTundefined 1 Reply Last reply Reply Quote 0
                    • HebigTundefined
                      HebigT
                      last edited by

                      This post is deleted!
                      1 Reply Last reply Reply Quote 0
                      • HebigTundefined
                        HebigT @dc42
                        last edited by HebigT

                        @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!

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Unless otherwise noted, all forum content is licensed under CC-BY-SA