Feature: gcode clustering support for faster engraving #1352
Comments
|
We have talked about a similar in the past. Since it is a common solution built into Lightburn, we might consider this approach. It will take a while to implement as we are dealing with a lot of new things right now. |
|
Point us to some code for some implementation. I'm not promising to do the work immediately, but having something to look at will make things easier. |
|
I think Lightburn should create a written spec for it. I have seen a few posts on it but not the complete story. LIghtburn "pixels" and FluidNC steps are not always the same, so FNC probably needs to sort that out on the fly. |
|
I think the Open Source controller community should refuse to support LightBurn until they publish their source code. Probably not going to happen though. They are abusing the community by not complying with the ethos of the firmware they depend on. |
|
attached are two files, one in regular grbl gcode and the other in @clustered@ gcode at 8 points per line, The implementation is as follows... In this case a Svalue is given for every dot |
|
I was hoping for a pointer to grbl implementation code |
|
i will try to get the sample code for you, |
|
This isn't quite a grbl implementation its more a grblhal implementation if that helps https://github.com/grblHAL/Plugins_laser/blob/master/lb_clusters.c |
|
Yes, that helps. GrblHal and FluidNC are very similar in many respects, particularly code that was derived from classic grbl. |
|
It seems pretty simple. We may be able to simply translate the lines on the fly and optimize a bit. G91 The 8 “pixels” are 1.364/8 or 0.1705 each. In the case where the power is repeated we would make a single move. It could be translated internally and pushed to the planner. g91 This does not work with line numbers, but why would you use them when trying to reduce characters. |
|
Need to remember that g91 moves can accumulate rounding errors |
|
I guess there are 2 parts to this. Character bandwidth and planer optimization. My idea only addresses the first. We are probably less sensitive than Smoothie with the planner. |
|
What I would really like to do is make a synchronous raster stepping method, optimized for laser rasters. Accelerate to constant speed then control the power synchronously with the step sequence, with a power change every N steps. The time for N steps would be a multiple of the PWM period. One alternative to expressing the raster data in GCode would be to use a standard image format, for example BMP. |
|
We need to be compatible with the laser software, so it needs a protocol. |
|
$sd/run=foo.bmp |
|
Can the laser software encode the speeds, directions, pixel size, etc in the file? The example file in this thread includes cut and engrave in the same file. |
|
Maybe it is not a good idea. But GCode really seems like a sucky format for rasters. The attempts to shoehorn it trigger all my "that is always going to be on the hairy edge of not actually working" alarm bells. |
|
Could the new format be treated as raster lines? We could allow more than the current lightburn max. |
|
Cut and engrave in the same file could be done with: .. GCode to setup the position, scaling and whatnot Or maybe the scaling is done with arguments to a $file/raster command |
|
Looking at the Stepper.cpp code: The segment_t data structure is pretty much a perfect representation of a sequence of pixels with the same value (laser power). The st_block_t structure represents the active (constant speed) part of a scan line. The complicated code in Stepper::prep_buffer() could be short-circuited for rasters, to generate a st_block_t for accel, a block for constant speed with interior segment spindle values taken from an array, then a st_block_t for decel, and finally one to move to the next line. I can't see how the existing code will work at all with rasters, since the spindle values are computed from the motion speed. I take that back. Maybe it sort of works because it is fed from a lot of planner blocks each of which has the same motion speed but different spindle values. |
|
Not to derail the implementation discussion but I just want to say how happy I am you guys are working on this. I've been pretty dismayed to learn that of the thousands of GRBL-derived diode lasers out there, presumably not a single one of them can raster and a reasonable DPI/speed combination purely because of unoptimized software. Very happy to see your team targeting optimizations. You can see me struggling with it this week: https://www.reddit.com/r/lasercutting/s/WmDgUMBTEk I can confirm that the problem is especially bad over USB at 115200 baud (and I was able to find no information on to change that rate in FluidNC) but also present when running from SD. Glad to see y'all talking about planning optimizations, not just uncompressing the gcode. My impression is that's needed. If you need tests on offending hardware, please let me know. My MKS DLC32 is ripe for testing and I am happy to build from source. EDIT: Realized that the "pass-through" option which sends the image directly to the controller was the solution for this. It can be found in the cut settings in lightburn. I'm not saying the optimizations discussed here aren't necessary, but it's nice to know that there is an existing solution for high-DPI engraving that doesn't slow the machine to a crawl. However, it has clear downsides such as not supporting grayscale. |
|
Hello, i got a response from Lightburn support: Hello Ed, LightBurn does not have firmware-side documentation on how to implement the Gcode cluster. However, most of the discussion and the source given to other companies that did implement it is based on this post on the GRBLHal Github Please verify if this helps. There are some other links regarding the implementation of Smoothieware, which could possibly help If you have any technical questions regarding the interaction, do let us know. Cheers, LightBurn Software Support i hope this helps |
|
I am pretty sure how to implement. The problem is finding time and motivation. |
Machine Context
for laser engraving using dither makes the moves "stuter" becouse of the comunication overhead or planning buffer
using gcode clustering for engraving has proven sucsesfull in making smother moves and faster while engraving
Feature Description
quote:
mar. 2023
Clustering was a thing I came up with to reduce the overhead required for planning a raster engraving job, originally for Smoothieware, but it’s been included in a couple of GRBL systems now too.
GCode based systems use a motion planner - this is the thing responsible for keeping the system within the limits of speed and acceleration set in the settings. If you tell it to draw a rectangle, it’s the thing that decides when it’s time to slow down before getting to a corner, and how long to take to speed back up again.
Any system that uses streamed GCode has a “plan buffer” that sits between the software and the firmware, holding moves that are coming but haven’t been executed yet. Each time a new GCode instruction is received, it gets added to the plan buffer and the planner looks through what’s there already and makes decisions about how fast each move can be allowed to go, just in case the NEXT move (that hasn’t been received yet) tells it to stop. You always have to be able to “see” far enough ahead to come to a stop within your desired acceleration setting.
Imagine driving a car around a blind corner at night on a road you’ve never taken - you probably slow down, just in case the part of the road you can’t see yet has a red light.
Smoothieware has a short buffer (32 moves) and each new move added to the buffer triggers a re-evaluation of everything before it, and it’s kind of slow. If each move is a single pixel in a grayscale image, and the pixels are 0.1mm, that means you can only see 3.2mm ahead. If you ask the thing to run at 100mm/sec, and the acceleration isn’t too fast, it can easily take more than 3.2mm to get up to (or slow down from) that speed, so you’ll never actually reach your desired speed.
Clustering changes this - Since all the pixels are going along the same line anyway, it uses one bigger move that’s 10 pixels long, and just plops the 10 power values on it all at once, instead of using 10 different G1 moves. Longer moves with multiple power values means the planner can see farther ahead, and it takes less effort to re-plan, and it takes less bandwidth to send it over the USB too.
“10” in this case is sort of arbitrary. We started with 8, because that’s what would fit in the limited RAM Smoothieware had available, but LightBurn supports clusters of up to 16 brightness values. A single cluster is also not required to use all of them, and normal GCode (with a single power value) is supported transparently.
TL;DR: Less computation, and can see farther ahead, meaning the machine will run faster and smoother, and take less bandwidth to do so, all in a way that still allows things like engraving along a diagonal, and support for grayscale. It’s also super simple for firmware coders to add.
Other Approaches
i have increased the panner buffer to maximum but still stuter at 100mm/s, adding this feature will help 3d engraving on co2 lasers and grayscale engraving in diode lasers plus higher speed engraving on all
How I Can Help
I can support testing on mks tinybee board and 80w diode laser
The text was updated successfully, but these errors were encountered: