I have a K40, with cohesion3d board and LIghtburn software. I’m trying to run pictures on birch plywood. My issue is I am getting stuttering during the projects which is causing my images to become unaligned. So I slowed it down to 125 MM/s and it seems to have remedied the alignment part, but I have to lower the power so much that I am no longer getting the quality that I want. They are 5-6 inch in size, around 400 DPI and I am running it in the stucki mode as it seems to have the leas amount of issues with the best quality. My question is obviously how do I remedy this or can I? I have tightened and loosened the belts so that is not the problem. My pc is fairy old and not very powerful, could this be the, or an issue? Or is this just a limitation of the k40?
Are you running the cluster firmware from Cohesion3D’s site? If not, I would look at that - it’ll increase the speed quite a bit - even with that you’re pushing the limit of what that board can do. Dropping the DPI to 300 to 350 would allow you to go a bit faster, and you could increase the power a little.
Yes, I am running their latest firmware. I will run some more tomorrow and lower the DPI. So in your opinion it is the board being pushed and not the pc?
Thanks for the quick response… by the way I love the software!
Yes, it’s mostly down to the board & firmware. Stock Smoothieware can process about 800 gcode instructions per second. With my changes to add clustering, that goes up to about 2400.
At 400 DPI, your file would be pushing about 1970 gcode instructions / sec, worst case, so you might be able to go a touch higher. At 330 DPI you could go 180 mm/sec (in theory - probably 150 to 160 safely).
Ruida and other DSP controllers have very specialized hardware and firmware that allows them to hit the speeds they do. I haven’t seen anything from the DIY community that comes close yet.
He posted a pic on FB that shows the old school shifting artifact though. With cluster, it shouldn’t shift if you tell it to go too fast, it just won’t process the data faster than it can take it in (this was what our testing showed, anyways).
You may want to verify that the cluster firmware build has been properly flashed to the board using the information from C3D, and that you have enabled the necessary toggle in LightBurn:
Practically speaking, Do 40W tube and/or $60 LPSU used in Chinese K40 grade machines are fast enough to support the speed gained by running the cluster firmware? how did you guys measured the speed - at tubes output or smoothie generated PWM output? i wish to run the cluster fw but before i spend time in tuning it to my specific board i would like to know i will gain such a huge difference. being able to engrave x3 faster is really tempting. I drive my cutter with an SKR board not with C3D (100Mhz - a bit slower than C3D’s 120Mhz so i think), so i’m guess no plug and play for me but if it’s doable - i would love to try it out, unleashing lightburn’s full potential.
@LightBurn
Oz, Can i continue using my config file as-is, or i need to use a specific one to enable the clustering thingy? is this feature baked in the bin file and no need for specific config? do i need to add specific lines to my config file to enable it?
There’s nothing in the config - it’s just something the firmware supports now. There’s a switch in LightBurn itself in the device settings to enable sending clustered gcode. That’s it.
I need to pinch myself.
I have just flashed the cluster firmware, re-powered my cutter, loaded lightburn, enabled cluster, loaded a simple image, set mode to stucki @ 250mms & 400dpi and watched my cutter engraving perfectly without a single hiccup.
Too good to be true. I need to spin my spinning top totem for making sure I’m not dreaming.
wt…
Not a single stutter, not a single hiccup.
Thank you Oz. For you this is science, for me this is magic (though i understand the cluster gcode structure used here).
Oz, I did not have the tab clicked to allow the clustering to be enabled… now it works!!
Thank you so much for the quick responses and it seems it helped Squid as well.
Thanks,
Eric