Arcs on Marlin and Dual End Stops

New Home Forum Mostly Printed CNC – MPCNC Troubleshooting – MPCNC Arcs on Marlin and Dual End Stops

This topic contains 22 replies, has 5 voices, and was last updated by  Ryan 2 weeks, 1 day ago.

Viewing 23 posts - 1 through 23 (of 23 total)
  • Author
    Posts
  • #111784

    Victor D.
    Participant

    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

    • This topic was modified 2 weeks, 6 days ago by  Victor D..
    #111787

    Clay
    Participant

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

    #111792

    Victor D.
    Participant

    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.

    #111799

    Victor D.
    Participant

    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.

    #111834

    Dalton Porter
    Participant

    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?

    #111840

    Victor D.
    Participant

    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.

    #111850

    Ryan
    Keymaster

    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 user thanked author for this post.
    #111853

    Victor D.
    Participant

    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.

    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

    #111855

    Ryan
    Keymaster

    Yup

    1 user thanked author for this post.
    #111856

    Victor D.
    Participant

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

    #111916

    Victor D.
    Participant

    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!

    #111934

    Victor D.
    Participant

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

    #111945

    Jamie
    Participant

    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 users thanked author for this post.
    #111956

    Jamie
    Participant

    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 users thanked author for this post.
    #111967

    Victor D.
    Participant

    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!!

    • This reply was modified 2 weeks, 5 days ago by  Victor D..
    #111996

    Ryan
    Keymaster

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

    1 user thanked author for this post.
    #112148

    Ryan
    Keymaster

    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.

    #112152

    Ryan
    Keymaster

    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 user thanked author for this post.
    #112195

    Jamie
    Participant

    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.

    #112201

    Ryan
    Keymaster

    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.

    #112347

    Victor D.
    Participant

    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.

    • This reply was modified 2 weeks, 2 days ago by  Victor D..
    #112350

    Victor D.
    Participant

    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.

    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?

    #112457

    Ryan
    Keymaster

    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 user thanked author for this post.
Viewing 23 posts - 1 through 23 (of 23 total)

You must be logged in to reply to this topic.