Hi guys!
I’m in need of some help/advice/fresh ideas…
I’m working on a self-build wax-printer or dispenser, however I’ve run into a problem I can’t seem to fix.
On straight lines the print is fine but it slows down to much when making a curve, and also sets small steps instead of the entire curve at once, resulting into accumulations or as I refer to; filament blops.
The machine runs on a Atmega2560 + RAMPS 1.4 with Marlin 2.0 (edited to run the machine). To print I create a pattern in Adobe Ai > import it into LightBurn > print.
Now one solution I thought might work is to make a circle using G2 code instead of lots of small steps.
I know LightBurn doesn’t generate G2/G3 g-codes, however in my understanding it does support it. So I’ve written a small piece of code using the G2 command, and ran it directly through LB to the machine. But it doesn’t seem to have any effect.
I’ve tried all the settings in LightBurn I could think of: Curve Quality, Curve Tolerance, faster speed overall, Backlash.
And used M commands to tweak things a little bit: M201, M204 & M205.
But unfortunately nothing has had much if any effect on the quality of the curved lines, or eliminated/reduced the blops.
Even though it is a home build machine the problem doesn’t seem to be in the hardware. So I was wondering if there’s anyone who can help me with solving this problem of winding arc’s and filament blops……
Can you elaborate what you mean by this? In what way do you understand LightBurn to support G2/G3? It will never generate them as you say.
In this capacity LightBurn is just a g-code sender. You needn’t even use LightBurn in this scenario and you could use any other g-code sender. LightBurn is not parsing or in any way involved in handling of the G2. Assuming the code was sent to the controller as-is then it’s purely an issue with the controller setup.
I do know in the 3d-printer world that G2 support is relatively new for Marlin. Did you make sure to configure Arc support when you compiled the firmware?
LightBurn can produce circles that are imperceptible from round even without G2 support. It’s likely not necessarily an issue in the code causing your curve issues.
Is it possible that your controller cannot keep-up with the g-code stream and is missing instructions? Have you tried switching to synchronous transfer mode in Device Settings or reducing baud rate?
Can you send a photo showing the artifacts that you’re seeing? Also, when you run the job can you see physical stuttering or hear any strange sounds?
Have you tried this? How are you coming to this conclusion? Also, suggest you try synchronous mode if you haven’t. I’ve heard of cases where Marlin boards overrun their buffer because they can’t keep up.
This needs to be configured in configuration_adv.h before compilation.
That’s fine but won’t have an effect on the outcome. The g-code is the g-code is the g-code. There may be other reasons for using other senders, however.
Overall, unless your machine is process bound (as-in can’t keep up with g-code commands) I suspect you’re barking up the wrong tree with arc support. Arc support is really nice and can give really good results but again, LightBurn can generate code for very smooth curves. If for some reason your curves are coming out jagged there’s likely another cause for that.
I have seen jagged edges from slop in the drives. Like belts being loose or even the pulley on the motor shaft. I have also seen it a few times on worn or improperly set up screw drives.
If possible id suggest testing the gcode on another machine.
Yeah, I saw @Waxtruder was using this for some sort of wax process which is why I wanted to see photos. It’s possible that the process is so sensitive that even the slightest variation from a true arc would disrupt this but it would surprise me if LightBurn’s approximation would result in visible facets. I think it more likely something mechanical or a limitation in the machine.
I suspect there’s a few things going on… the work is non-trivial and of limited value whereas linear approximations fit all scenarios. Some g-code implementation don’t support arcs either so may not get priority.
You’re not wrong. Some implementations can result in quite a jagged look. I just haven’t seen this in LightBurn output. I regularly cut items requiring a lot of curved details and have never noticed anything that I would attribute to a rendering issue or facets of any kind. This is going to be a function of processing speed, memory size, streaming speed, and the quality of the renderer. I know in 3D-printing the facets can be quite pronounced so it was quite a big deal when arc support was added in Marlin. I still don’t think it’s universally supported, however, as it needs support up and down the entire toolchain.
So using G2 and G3 in marlin won’t change your output. Even with arcs it is still broken down into line segments. There are a couple things you could look at doing.
1 - in LightBurn settings at the bottom there is a “curve tolerance” factor. You can adjust that as needed and it acts similar to path smoothing in some CAM software effectively making less points. This is helpful because your printer is likely coming to a stop at every g1 point and making your blobs.
2 - Move to a firmware that has a path smoothing factor enabled at the firmware level. LinuxCNC for example has G64 Pxxx that will “round off” paths within the tolerance defined with the P value. Even setting extremely low values can smooth out very jerky paths.
This is a hard problem to solve when you are dealing with a dispensing application like when a applying something like Wax, or glue, or ceramics or concrete because the flow is not near as controllable as it is with something like thermoplastic on an FDM printer.