Improved Raster Speed Firmware Update for Cohesion3D Boards!

Indeed it does!
Burn baby, burn!

The implementation doesn’t care which axis is involved, and will handle scanning at an angle too. It basically just clusters a bunch of pixels into a single GCode move, allowing the motion planner to see further ahead than it could before (up to a max of 8x).

The motion planner in Smoothie can only see 32 moves ahead. If those moves are all 0.1mm each, it means that it can only see 3.2mm ahead. If the next move to be added to the planner reverses direction, it has to be able to do a full stop within 3.2mm. Depending on your speed and accel, this might not be possible, so it will limit your speed accordingly.

Putting multiple image pixels into a single, longer move means that it can now “see” farther ahead. If we put 10 dots into a single move, you’d now be able to “see” 32mm ahead, and that’s far enough ahead to be able to stop in time even if you’re moving pretty fast.

There are still other bottlenecks - processing all this data takes computation, and I had to increase how often it updates the PWM output, which increases overhead too, but in testing it’s been at least 3.5x faster than it was, and that’s a reasonable practical limit, given the other components in the system (PSU, glass tube firing time, small motors, etc).

Hopefully this makes Smoothieware just as capable as GRBL-LPC for raster engraving, and it still has all the cool Smoo stuff, like SD card and LCD support, smoother motion, and so on.

Feedback is welcome.


BRAVO!!! This update is amazing on my C3D Mini! Engravings have gone so much faster and without the skipping and buffer errors from before. I could actually engrave an image at 200mm for 254dpi with no issues. Again, Thank you!


That’s awesome - I can use my LCD screen again :+1:

Are any changes needed to run the new firmware on LaserWeb?

The improved sending speed will only work with LightBurn. If you have not tried LightBurn yet, there is a 30 day fully functional free trial at:

It is so much better than LaserWeb. Give it a try!


Where can I get the source code of this firmware? I’d like to check how it’s made :thinking:

Ray or I can send you the code changes. You’ll see the most benefit if you use it with a fast-stream implementation.

The simple explanation is that you send one G1 move and send one or more S values, separated by colons, to be evenly distributed along the G1 move, like this:

G1 X0.5 S1:0:0.5:0.75:0:0.2

Up to 8 values can be sent in a single G1 move.

1 Like

Here are the modified Smoothieware files:

1 Like

Ok, that makes sense. Thanks for the explanation and code!

These changes should go in the github repo! It would be great to be able to easily build or pull improvements into the upstream project.

Agreed, but that would be up to the owner of the repo. :slight_smile:

So when it says that clustering only works with lightburn, does that mean only when sending with lightburn? Or will lightburn generated gcode run from the SD card using the GLCD also perform the same?

It means that LightBurn creates the gCode in the way needed to take advantage of the clustering speed improvement. I honesty don’t remember if we tested when running via the SD Card or not, but I don’t see why it wouldn’t work.

Clustering specifically improves the speed of engravings where the controller is getting fire-hosed with data. Lines do not have any such issue and clustering does not apply to them, so that gCode would look exactly the same.

I figured that out, hence why I tried to delete previous post.

I put the post back, I wanted the answer out there to help others.

1 Like

Hi - first off this upgrade is amazing. I thought I was missing steps, had motor driver issues, etc. unless I engraved at slow settings. I did this upgrade and changed setting in the software and it’s seamless.
One question now, when I flashed the new firmware, it seemed to mess up my rotary settings. I for now, tricked the software by telling it a half inch dia cylinder was something like .01". I assume I need to revisit the config and try changing stuff there. Can someone let me know if they saw the same phenomenon after the update? Is there something I can change by some known factor to get the rotary back and going without trial and error?? Thanks!

Hi, from time to time I get some issues (skipping when doing images) and looks like I found the solution with your info, thanks! I do have some questions, though. You mentioned that “should allow it to go approximately 3 times faster than it could before”. What would be that? 240 mm/s? and, is there a ration or correlation with dpi / speed ? if I have lower dpi can I go faster ? if I go slower can I increase dpi ? I did a table trying to figure that out and wonder if in fact I can relay on that:


In theory, if I stay on or below 1 on my margin, I should be ok.

Can you please advice on all this?
Thanks a lot.

… two years later… XD sorry, i’m new here.
Hi, not sure if this helps, but I have this on my setting:

A axis

delta_steps_per_mm 17.77 # may be steps per degree for example
delta_step_pin 2.3 # Pin for delta stepper step signal
delta_dir_pin 0.22 # Pin for delta stepper direction
delta_en_pin 0.21 # Pin for delta enable
delta_current 0.8 # A stepper motor current
delta_max_rate 6000 # mm/min
delta_acceleration 100 # mm/sec²

I remember I had to change delta_steps_per_mm to that value; forgot why I did it. XD

Sorry for reviving an old post, but has this ever been upstreamed to either the main Smoothieware repo or some other git repo?
3 years later there’s been a lot of changes made to Smoothieware so I doubt I could just make a simple patch and apply it if it hasn’t been.
I’d kind of given up on fixing the weird issues my brother’s K40/C3D has years ago, but now that I’ve got a better understanding of how the stack sticks together, I figured I’d try again, and figured I might as well look into trying out the latest upstream Smoothieware, but if this didn’t make it in that’d be a bit of a dealbreaker for that.