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

HebigT · 15 Oct 2018, 21:28

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!

Duckle · 15 Oct 2018, 22:04

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?

Phaedrux · 15 Oct 2018, 22:55

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

dc42 · 16 Oct 2018, 13:14

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.

HebigT · 16 Oct 2018, 15:24

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

dc42 · 16 Oct 2018, 23:17

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.

HebigT · 18 Oct 2018, 19:28

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

dc42 · 18 Oct 2018, 21:16

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.

HebigT · 18 Oct 2018, 21:30

This post is deleted!

HebigT · 18 Oct 2018, 21:31

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