Raster engrave constantly accelerating and decelerating?

bg_86

I just set up my Duet3D Duet 3 Mini 5+ on my laser engraver. First time doing any laser engraving at all. I expect with the current configuration and gcode for the machine to accelerate up to 300MM/sec in the x axis and then modulate the 5KHZ control wire to turn the laser on and off as it goes, just like a laser printer. Why does the machine accelerate and decelerate as the laser is turned on and off as it travels along? Is there a default setting that's specific to the laser mode in RRF that limits the machine feed rate during laser on G1 moves? (EX: G1 X0.085S1000) I could do some manual tests to see what's actually happening, but I am in the middle of a very long raster engrave image that is severely slowed by this. GCode and config.g are below. By the way, first time RRF user and Duet3d board owner. Best firmware and board documentation I've ever used. Coming highly recommended from me.

; LightBurn 1.4.00
; GRBL device profile, absolute coords
; Bounds: X2.42 Y9.98 to X217.41 Y235.39
G00 G17 G40 G21 G54
G90
M4
; Image @ 300 mm/sec, 100% power
M9
G0 X2.42Y9.981
; Layer C00
G91
G1 X7.5F18000S0
G1 X12.944S1000
G1 X0.042S0
G1 X0.085S1000
G1 X0.803S0
G1 X0.042S1000
G1 X0.085S0
G1 X0.085S1000
G1 X0.042S0
G1 X0.042S1000
G1 X0.043S0
G1 X0.126S1000

G90                            ; send absolute coordinates...
M83                            ; ...but relative extruder moves
M550 P"CoreXY Laser Engraver"  ; set printer name
M669 K1                        ; select CoreXY mode

; Network
M552 S1                        ; enable network
M586 P0 S1                     ; enable HTTP
M586 P1 S1                     ; enable FTP
M586 P2 S1                     ; enable Telnet

; Drives
M569 P0.0 S1                   ; physical drive 0.0 goes forwards
M569 P0.1 S1                   ; physical drive 0.1 goes forwards
M584 X0.0 Y0.1                 ; set drive mapping
M350 X16 Y16 I1            ; configure microstepping with interpolation
M92 X80.00 Y80.00              ; set steps per mm
M566 X900.00 Y900.00           ; set maximum instantaneous speed changes (mm/min)
M203 X18000.00 Y18000.00         ; set maximum speeds (mm/min)
M201 X5000.00 Y5000.00           ; set accelerations (mm/s^2)
M906 X1400 Y1400 I30             ; set motor currents (mA) and motor idle factor in per cent
M84 S30                          ; Set idle timeout
M204 P5000 T2000                 ;Set printing acceleration and travel accelerations

; Axis Limits
M208 X0 Y0 S1                  ; set axis minima
M208 X304 Y304 S0              ; set axis maxima
M564 S0 H0                     ; H0 = allow movement of axes that have not been homed S0 = allow movement outside boundaries

; Endstops
M574 X1 S3                     ; configure sensorless endstop for low end on X
M574 Y1 S3                     ; configure sensorless endstop for low end on Y

; Z-Probe
;M558 P0 H5 F120 T6000          ; disable Z probe but set dive height, probe speed and travel speed
;M557 X15:215 Y15:195 S20       ; define mesh grid

; Heaters
M140 H-1                       ; disable heated bed (overrides default heater mapping)

; Fans
M950 F0 C"out3" Q500           ; create fan 0 on pin out3 and set its frequency
M106 P0 S1 H-1                 ; set fan 0 value. Thermostatic control is turned off

; Tools

; Custom settings are not defined

M452 C"out6" R1000 S1 F5000 ; Enable Laser mode, on out6, with max intensity being 1000, sticky mode on, and a PWM frequency of 5KHZ

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.4.5 (2022-11-30 19:41:16) running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: 1Y776-WN6KL-K65J0-409N2-4D02Z-7U7BL
Used output buffers: 4 of 40 (31 max)
=== RTOS ===
Static ram: 103652
Dynamic ram: 109692 of which 204 recycled
Never used RAM 26724, free system stack 110 words
Tasks: NETWORK(notifyWait,373.0%,199) LASER(notifyWait,14.4%,38) HEAT(notifyWait,0.3%,374) Move(notifyWait,295.6%,265) CanReceiv(notifyWait,0.0%,942) CanSender(notifyWait,0.0%,336) CanClock(delaying,0.8%,333) TMC(delaying,39.5%,72) MAIN(running,195.7%,417) IDLE(ready,41.8%,30) AIN(delaying,47.9%,263), total 1009.0%
Owned mutexes: SD0(NETWORK)
=== Platform ===
Last reset 19:26:19 ago, cause: reset button
Last software reset at 2023-07-14 21:53, reason: User, GCodes spinning, available RAM 26964, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
MCU revision 3, ADC conversions started 70167466, completed 70167465, timed out 0, errs 0
Step timer max interval 1491
MCU temperature: min 34.7, current 49.8, max 57.9
Supply voltage: min 23.7, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, read errors 0, write errors 1, ifcnt 125, reads 7914, writes 105, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, SG min 0, read errors 0, write errors 1, ifcnt 125, reads 7914, writes 105, timeouts 0, DMA errors 0, CC errors 0
Driver 2: standstill, SG min 0, read errors 0, write errors 1, ifcnt 32, reads 8007, writes 12, timeouts 0, DMA errors 0, CC errors 0
Driver 3: standstill, SG min 0, read errors 0, write errors 1, ifcnt 29, reads 8010, writes 9, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, SG min 0, read errors 0, write errors 1, ifcnt 29, reads 8010, writes 9, timeouts 0, DMA errors 0, CC errors 0
Driver 5: not present
Driver 6: not present
Date/time: 2023-07-15 17:26:02
Cache data hit count 4294967295
Slowest loop: 701.85ms; fastest: 0.08ms
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 7.2ms, write time 108.4ms, max retries 0
=== Move ===
DMs created 83, segments created 60, maxWait 32001315ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 19982, completed 19982, hiccups 0, stepErrors 0, LaErrors 0, Underruns [8106310, 0, 198], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Segments left: 0
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
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== CAN ===
Messages queued 349898, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 18 (min 18), ts 349898/0/0
Tx timeouts 0,0,349897,0,0,0 last cancelled message type 30 dest 127
=== Network ===
Slowest loop: 4234.74ms; fastest: 0.00ms
Responder states: HTTP(3) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
= WiFi =
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 2.1beta4
WiFi MAC address e8:68:e7:e1:4f:a1
WiFi Vcc 3.42, reset reason Power up
WiFi flash size 2097152, free heap 40232
WiFi IP address 192.168.69.212
WiFi signal strength -34dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002001
Socket states: 3 2 0 0 0 0 0 0

Perhaps because my overscan setting isn't long enough, the M204 P1500 T2000 setting is causing it to slow down accelerating before it reaches 300MM/SEC? Still, that doesn't make sense to me why it would be decelerating during a single X raster pass...

dc42

@bg_86 please try increasing the movement queue length. See the PS in my previous reply.

bg_86

@bg_86 discovered gcode move clustering posts. It started off printing the first 10 seconds or so with the same issue then unexpectedly started FLYING. Still does some decelerations mid-pass but seems to average around 250 of the expected 300mm/s.
Massive improvement. But still, why is it decelerations mid pass? I did change the print acceleration to match machine acceleration to match in case it is activated during "laser mode"

oliof

@bg_86 try adjusting minimum segment length in your kinematics definition https://docs.duet3d.com/User_manual/Reference/Gcodes#m669-set-kinematics-type-and-kinematics-parameters

o_lampe

@bg_86 It might still be suffering from a too small planner buffer? I remember vaguely that the buffer could be increased via mcode, which was related to dual gcode streams. But it might help here too.

dc42

@bg_86 are you running the job from the SD card? Do you have any form of bed compensation enabled?

PS if you need to increase the movement planner queue length, see https://docs.duet3d.com/User_manual/Reference/Gcodes#m595-set-movement-queue-length.

bg_86

@dc42 Yes, from an SD card. A 4GB one that meets the specs in documentation. I know we are talking about a READ issue here, but I can say that the write speed over Ethernet->Wi-Fi is ~600KB/sec. Clustered file is 80MB, non-clustered is 110MB.

No z axis, mesh leveling is off.

dc42

@bg_86 please try increasing the movement queue length. See the PS in my previous reply.

bg_86

@dc42 That did the trick... Sorta.I figured it was the planner queue but didn't find it in the documentation because I was calling it a "buffer" in my searching.

However, in the first 30 seconds of running the issue persists (with clustering gcode at least) which I could live with, however it seems to have a direct effect of how many photons are hitting a given area. The result is an area with a deeper burn before the buffer gets fully loaded and the movement is no longer bottlenecked by the planner not being big enough. Suppose it's time to clone this SD card and put everything one the one that was shipped with the unit just to remove another variable?

Worked my way up to M595 P100 R10000. R value doesn't seem to change anything like I thought it would. Ideally I want to front load and fill the queue before the first move takes place. I thought the r value from my interpretation of the documentation did that.

1am I think it's time for bed lol

bg_86

@dc42 I believe I was using the provided SD card afterall. Found a random 32GB Samsung EVO card that I believe came with one of my Raspberry Pi. Massive improvement right out the gate, with jittering only occuring on the first two X direction passes (200mm across).

When I get done doing some family things I will follow up on more thorough clustering testing later today.

Without access to realtime diagnostics it will be hard for me to get a handle on what's going on. But for my purposes, I consider it solved. Do you have any workarounds? G4 PXXX looks like it clears the planner queue from the docs I have read.

dc42

@bg_86 yes G4 clears the movement queue, so does M400.

o_lampe

@bg_86 said in Raster engrave constantly accelerating and decelerating?:

Without access to realtime diagnostics it will be hard for me to get a handle on what's going on.

@dc42 Isn't there a buffer underrun counter in the diagnostics? Maybe when setting the debug-log level to warnings? (but debugging_on could induce even more errors in this case...)

bg_86

Yes, there is. The counter doesn't seem to match the formatting in the documentation, though, so I'm not sure what I'm looking at.

M122 results:

=== MainDDARing ===
Scheduled moves 19982, completed 19982, hiccups 0, stepErrors 0, LaErrors 0, Underruns [8106310, 0, 198], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1

Compare that to the information here: https://docs.duet3d.com/en/User_manual/RepRapFirmware/SD_card#stuttering-during-printing

@o_lampe no jittering on the 4MB clustered gcode test file I just did at 400MM/SEC, 6000 acceleration. With overscan, it maintains the full 400MM/sec throughout each X axis pass.

Seems that jittering issue I reported in my post from yesterday is directly tied to not only the speed of the SD card, but the size of the gcode file. Those files were 90-140MB! I just dreamed up a potential workaround where lightburn posts a beginning-of-file manual gcode to the post that commands a slow move that lasts a few seconds to allow whatever might be causing this issue for the first few seconds of a run to take place, but I haven't tried it yet.

bg_86

@dc42

@bg_86 said in Raster engrave constantly accelerating and decelerating?:

I just dreamed up a potential workaround where lightburn posts a beginning-of-file manual gcode to the post that commands a slow move that lasts a few seconds to allow whatever might be causing this issue for the first few seconds of a run to take place, but I haven't tried it yet.

I just tried this workaround and it did in fact remove the initial jittering I was seeing on the first two or three X raster passes. Just threw in G1 X100 Y100 F500 to create a move that takes 10 seconds or so to complete before the print starts going on the 80MB clustered gcode file. I also noticed that lightburn grbl gcode post is putting a G4 P1 at the beginning of the file for some unknown reason. Tomorrow I will remove that line and my workaround on the offending file without my workaround and see if is in some way contributing to this planner queue jitter issue at the beginning of the file after expanding the planner move queue and the sd card upgrade.

dc42

@bg_86 it may be worth using an Application Class 1 or 2 SD card, because they perform much better at random file reads/writes than tradition SD cards designed for use in digital cameras. See https://www.sdcard.org/developers/sd-standard-overview/application-performance-class/#:~:text=The Application Performance Class 2,of Command Queuing and Cache.