Arcs on Marlin and Dual End Stops

By the way, the gcode was generated on Ubuntu. Notepad (Windows) does not open it right, but the MPCNC sees it with no issues as evidenced by the carving.

Sorry, I don’t have an answer for you, but now I have a question. I thought the Rambo boards used GRBL, but your post indicates you use Marlin. Furthermore, you used a GRBL post processor to generate the gcode. That leads me to the perplexing conclusion that you are running GRBL code on a Marlin board. Is that correct?

The Rambo board from V1 comes with Marlin. I was debating switching to GRBL but decided against it (for now) because all the previous tests I ran worked fine and I like having the display + SD card.

Others can explain better, but short answer is, Yes. As I understand, Marlin and GRBL gcodes are practically the same, with differences on plane (e.g., xy, xz, yz) selection/definition.

I am pretty sure I messed up the junction deviation setting in the newest Marlin. Try doubling that number and re-flashing. If that works I will update the firmware.

1 Like


Just to confirm, do you mean in Configuration.h, change from 0.005 to 0.01?

// Use Junction Deviation instead of traditional Jerk Limiting
#define JUNCTION_DEVIATION_MM 0.005 // (mm) Distance from real junction edge


1 Like

Won’t be until later today but I will report back once I have a chance.

Alright, updated the junction deviation to 0.01 to no avail other than it seemed to make the turn quicker - may just have been my impression.

However, I did make a cut with it to demonstrate the issue. As shown on the attached photos, the corners are far from correct and on the bottom left corner, the axis actually distorted the perpendicularity of the cut.

I understand that avoiding G2/G3 is an option but not really a solution… I’m open to any suggestions that could help with this!

For another point of reference, I opened the gcode in bCNC and an online gcode viewer, both show the same path correctly.

I can’t explain the dual steppers going opposite each other, but I have seen reports of strange behavior when the soft limits are triggered with G2/G3, and it looks to me very similar to your strange cuts. See here:

Linear movements are clipped to prevent going non-negative, and I think arcs are supposed to be clipped but the implementation is incorrect, causing bizarre movement. I notice in your gcode file you have negative coordinates.

Negative coordinates are fine if you jog the machine to the workpiece and do G92 X0 Y0. The machine will know that it can go negative relative to the G92 work offset without hitting the soft limits, so it is fine. But if you attempt negative movements in absolute space it will not move as programmed. This can happen even if the machine can physically move negative, e.g. if you power cycle the machine while it is at the workpiece, it won’t know that it’s not at the edge of the workspace and it will still clip.

Maybe, and this is speculation, the incorrect implementation of soft limits for G2/G3 also has a bug causing the two motors to move separately.

If you think this is plausible, a simple test is to place the workpiece at a healthy offset and jog to the workpiece and do G92 X0 Y0.



Ok, so I went digging in the code and found what I think is a bug regarding G2/G3 and soft limits. I’ve submitted a patch. Here is the pull request:

Here is a video showing the problem. (Assuming this is the same problem you’re facing but not sure.)

Even with the bugfix, hitting the soft limits is still bad. Your cuts will deviate from what the CAM is trying to do. But with the bugfix, at least your tool won’t suddenly lurch into negative coordinates.


I just did a quick test and this seems to have solved it!

I homed the machine, jogged (not moved by disabling the stepper motors) the bit to within the work piece, reset coordinates using the custom commands menu on the LCD, and started the gcode.

The solution makes sense to my original workflow because the frame component was an afterthought (thus the negative components). Therefore, I turned off the machine once the engraving was done, and turned back on at the workpiece zero and simply started the frame code.

My subsequent test, I did not bother to home because… well, it was a test and I didn’t know better.

As for the motors moving in opposite directions, that may have just been my impression because of the slanted cut, and me trying to figure out possible issues. It did not happen again.

Thank you!!

Dang you are my hero. Solved a problem and squashed a bug!

1 Like

Thanks for the marlin edit last night! Awesome, I really think collectively MPCNC users have made a pretty solid impact on Marlin firmware. I am sure they can get tired of all of use trying to bend 3D printing firmware to fit our needs but they really seem to be more perceptive and open now. Thanks again for being in the Crew.

I am doing the initial tests on the firmware update. We are something like 800-900 commits behind. I will flash and run all my printers this morning and hopefully tonight test some CNC’s. I tweaked the junction deviation and arc length, I think that was the only issue. If you can think of anything else let me know.

Sorry I know it isn’t the right thread but it kinda fits.

1 Like

The joystick code still hasn’t been accepted into mainline Marlin. I’m not sure why. It is finished as far as I’m concerned. I’ll give it a nudge and see if they will accept it into the main branch.

Yeah I am not sure how the things get noticed, but I have seen extremely tiny changes not get pulled for a very long time.

Just an update, and to call this solved.

Prepared the attached using Blender and FreeCad (GRBL post-processor and lots of G2/G3 commands) and ran with the proper workflow (i.e., home then jog to position) and it worked like a charm!

On a separate note, I have to say that I’m very happy with Marlin on the CNC - having the LCD and SD is a major plus for me!

Thanks again Jamie and Ryan for helping resolve this.

Does the firmware here on the V1 Eng. site have all the updates to date or do you typically wait for the commits to be applied before you upload here?

Kind of a tricky question. The official release is still Marlin 1.9, we have been on 2.0 for a long time. I try to update periodically but it moves fast. As for features I do not like to add them to the firmware unless they are in Marlin or we need them specifically (dual pin swaps, laser delay).

1 Like