Arcs on Marlin and Dual End Stops

So I’ve run into my first issue with my MPCNC (dual end stops, Rambo, Marlin, all stock from V1).

I’ve run the crown test, with a pen and a bit - no issues. I did a full 3D carving (~8hrs milling, attached) with no issues either… until I went to cut the frame. Specifically, on the corners of the frame the steppers went crazy, trying to pull the bit in opposite directions - or at least that’s what it looked like because both X and Y axis were off after the bit passed the corner. Luckily the arc was small and I was able to shut it off quickly. As such, I ended up cutting the frame out separately, as seen in the photo attached.

I inspected gcodes I had successfully run, including the Test Crown 12mm/s and the 3D carving base file and both only had G0 and G1 movements, i.e., all linear and no arcs. However, the frame file had G2 movements at the corners (e.g., G2 X187.065 Y-2.455 Z-1.500 I-1.585 J0.000 K0.000 F480.000).

The issue seems to be with the G2 command. I can only assume and speculate this may be related to how Marlin translates the G2 movement to the steppers that leads them to behave erratically.

Has anyone else experienced this or can anyone confirm successful G2 command on a dual end stop MPCNC?

Thanks!

Victor

What software/post processor were you using? and can you post the full gcode?

My gcodes are generated using FreeCad, GRBL post-processor. I’ve attached the full gcode for the frame.

03_frame_1-8_tst.gcode (10.6 KB)

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

Ryan,

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
#if ENABLED(JUNCTION_DEVIATION)
#define JUNCTION_DEVIATION_MM 0.005 // (mm) Distance from real junction edge
#endif

Yup

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: https://www.v1engineering.com/forum/topic/strange-movement/

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.

 

2 Likes

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: https://github.com/MarlinFirmware/Marlin/pull/15156

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.

2 Likes

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.