@Aquilux I just think it's the right tool for the job. I have a 4 axis 4'x8' CNC router and I run it. Everything you're looking for is already built into the interface, and it scales to any size monitor and is set up for a touch screen.
I totally get how it seems unhelpful given you're already deep down this path.
@o_lampe I do, but the air was off for late night testing in the garage. Clever thinking tho
@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.
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.
@dc42 My 10W diode laser doesn't deliver enough photons at 400mm/s to get any real definition that you can visually analyze well on the one rastered image test I did tonight. I'm not sure where your concerns might lie in regards to adjacent row alignment and testing. Are you looking for a heavy clustered line from a rastered image with lots of on/off commands in a single row or will a basic vector outline image with less clusters work? Also, if I do happen to see streaks that extend beyond the point where the laser should be commanded to stop, could the speed of the 5khz LaserTree 10W laser to shut off the beam be muddying the waters of the test? I did a quick test of a 5" wide rastered image and I want to say I see streaks extending but I figured I would reach out with a little more guidance on this testing before I provide any kind of seat of the pants test results.
So far though? Looking good!
@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 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
@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 I resorted to turning on clustering because I was desperate to resolve a speed issue which I detailed in my first post here earlier. Ran the clustered gcode for 3 minutes and saw immediate speed increases but if you need me to do any testing I have a corexy machine I built out of 1/4 aluminum plate with 2A nema17s that flies. Raster engraving preliminary test and subsequent print cancel showed excellent results. Not sure what you want tested.