Max actual speed at high path detail

Kulitorum

I don't remember - I think around 1000 for XY movements.

But I think jerk should not matter if there's no change of direction?

dc42

Are you printing from SD card, or over USB? Which firmware version are you using?

Kulitorum

@dc42 From SD card, 2.02(RTOS) (2018-12-24b1)

Kulitorum

; Configuration file for Duet WiFi (firmware version 1.21)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v2 on Sun Jan 13 2019 15:01:31 GMT+0100 (Central European Standard Time)

; General preferences
G90 ; Send absolute coordinates...
M83 ; ...but relative extruder moves

M584 X5 Y6 Z7 E8 U9 ; Apply custom drive mapping

; Network
M550 P"BOD2-444" ; Set machine name
M551 P"COBOD: ; Set password
M552 P10.10.10.250 S1 ; Enable network and set IP address
M553 P255.255.255.0 ; Set netmask
M554 P10.10.10.1 ; Set gateway
M586 P0 S1 ; Enable HTTP
M586 P1 S0 ; Disable FTP
M586 P2 S0 ; Disable Telnet

M569 P9 S1 ; U axis positive

; Drives
;M569 P5 T2.5:2.5:5:0 ; X driver 5 requires an active high enable, 2.5us minimum step pulse, 2.5us minimum step interval, 5us DIR setup time and no hold time
;M569 P6 T2.5:2.5:5:0 S0 ; Y driver 6 requires an active high enable, 2.5us minimum step pulse, 2.5us minimum step interval, 5us DIR setup time and no hold time, negative direction
M569 P7 T2.5:2.5:5:0 ; Z driver 7 requires an active high enable, 2.5us minimum step pulse, 2.5us minimum step interval, 5us DIR setup time and no hold time
;M569 P8 T2.5:2.5:5:0 ; E driver 8 requires an active high enable, 2.5us minimum step pulse, 2.5us minimum step interval, 5us DIR setup time and no hold time
M569 P9 T1.5:1.5:1:0 ; U driver 9 requires an active high enable, 2.5us minimum step pulse, 2.5us minimum step interval, 5us DIR setup time and no hold time

M569 P5 S0
M569 P6 S0

M350 X16 Y16 Z16 E16 U16 I1 ; Configure microstepping with interpolation
M92 X180.965147453 Y180.965147453 Z1226.99386503 E150.00 U525.14165 ; Set steps per mm
M566 X3000 Y3000 Z100 U45000 E10 U1200 ; Set maximum instantaneous speed changes (mm/min)
M203 X90000 Y90000 Z2500 U7500 E2000000 U20000 ; Set maximum speeds (mm/min)
M201 X500 Y500 Z100 E250 U5000 ; Set accelerations (mm/s^2)
M906 X300 Y300 Z300 E800 U400 I30 ; Set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout

; Axis Limits
M208 X0 Y0 Z0 E-90000000000000 U-999999999 S1 ; Set axis minima
M208 X9500 Y9500 Z5000 E900000000000 U999999999 S0 ; Set axis maxima

; Endstops
M574 X0 Y0 Z0 S1 ; Set active high endstops

; Z-Probe
M558 P4 H50 F2400 T15000 ; Set Z probe type to switch and the dive height + speeds
G31 P500 X0 Y200 Z0 ; Set Z probe trigger value, offset and trigger height
M557 X0:2500 Y0:2500 S500 ; Define mesh grid

; Heaters
M140 H-1 ; Disable heated bed

; Fans

; Tools
M563 P0 D0 H ; Define tool 0
G10 P0 X0 Y0 Z0 ; Set tool 0 axis offsets
G10 P0 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C

; Automatic saving after power loss is not enabled

; Custom settings are not configured

; Miscellaneous
T0 ; Select first tool
M302 P1 ; Allow cold extrusion
M564 S0 H0 ; allow moves outside of print area

Kulitorum

gcode example here:

https://pastebin.com/1t6g29Wi

Kulitorum

With this configuration I am getting a max speed of 357.1 mm/s for the gcode linked, with a max line length of 5mm

with a line length of 20mm, I can do 539.3 mm/s. These are not fluctuating numbers, they are totally steady.

My target speed is 1500mm/sec, and long G1 moves can go 1500mm/sec without issue.

Kulitorum

Kulitorum

BTW, I slice everything to 100mm/sec and use M220 S1500 to speed it up to 1500mm/s

Kulitorum

dc42

I'll try to make time to run your example over the next few days.

dc42

I have run some tests to replicate the issue.

The main reason why the maximum speed gets limited is the combination of small segment size (5mm) and low XY acceleration (500mm/sec^2). RRF maintains a pipeline of moves. When a new move is pushed into the pipeline, initially it has to be set to end at zero speed, in case no more moves arrive in time. Its end speed can be adjusted later after further moves are added to the pipeline. The capacity of the pipeline is 30 moves. However, in order to maintain a reasonable response time to a pause request, RRF won't push any more moves into the pipeline if it already contains more than 2 seconds of moves. So the maximum speed it can get up to is the lower of the following:

Distance limited: 30 moves at 5mm = 150mm. From v^2 = u^2 + 2as and putting u=0, we get:

v = sqrt(2*500*150) = sqrt(150000) = 387.3

Time limited: 2 seconds of deceleration. From v = u + at we get:

v = 500 * 2 = 1000

This isn't the whole story because the first few moves in the pipeline are frozen ahead of time to ensure they will be ready in time. So the actual number of moves that can be adjusted isn't quite as high as 30. That's why you are getting 357.1 instead of 387.3. This corresponds to 25.5 moves that can be adjusted in the pipeline. The 0.5 arises because while the pipeline is being filled initially, there will be an accelerate/decelerate move in the middle of it.

If I increase the acceleration, then the displayed top speed increases, roughly with the square root of the acceleration as expected.

Bear in mind that if you were printing at 1500mm/sec, the printer would take 1500^2/2*500 = 2250mm to stop. So dividing the move into 5mm segments won't achieve anything significant anyway.

I can see the following solutions, or you could use a combination of them:

You can increase segment length. If you increase segment length to 100mm, that's still less than 5% of the stopping distance.
You can increase acceleration, if your hardware permits. Maximum speed will increase with the square root of acceleration.
There may be scope for us to increase the pipeline length by a modest amount in the 2.03 release of RRF, for example to 40 moves. Maximum speed will increase with the square root of available pipeline.
We could implement faster pause code by modifying the current move and other frozen moves when a pause command is received, so that you don't need to segment the GCode. This won't help when you are printing curves with short segment lengths.

Kulitorum

@dc42 said in Max actual speed at high path detail:

faster pause code

Thank you for that explanation, I almost figured the same out myself

Faster pause code would be super - the ability to pause in the middle of a long segment would make a large difference to me.

Kulitorum