Raster engrave constantly accelerating and decelerating?

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.