GRBL running on Ramps

New Home Forum Software / Firmware Development GRBL running on Ramps

This topic contains 120 replies, has 26 voices, and was last updated by  Brett Le Roux 13 hours, 38 minutes ago.

Viewing 30 posts - 91 through 120 (of 121 total)
  • Author
    Posts
  • #105325

    Tim
    Participant

    This seems like really useful work would you be willing to fork the original project on github and add your mpcnc code so this can be found and worked on more easily by the community?  I’m only at the start of my cnc build but based on my experience with smaller cnc machines grbl seems like a superior firmware for the machine and this kind of work makes the mpcnc and lowrider much more appealing to a wider audience with the extra flexability.

    #106200

    John Boiles
    Participant

    @alexp thanks for the info! You’re running a RAMPS board correct? I think I’ll need to figure out the right pins for my RAMBO board as well. Not sure how similar the pinouts are. I’m hoping to pick this up again soon!

    #106207

    Jeffeb3
    Participant

    You also need to set the digipots for the current on the rambo board. I think the pinouts won’t be bad, but they use the port variables, IIRC. So you’ll need to do a little homework to find the right pins.

    #106358

    John Boiles
    Participant

    @alexp: it was kind of hard to understand your changes with the code formatting on this forum. Is this what you did?

    https://github.com/johnboiles/grbl-Mega-5X/pull/1

    #106359

    John Boiles
    Participant

    @jeffeb3 yeah I looked for a bit today and got a bit confused by the way the GRBL code lists pins. I’ve started trying to map out the different pins though. Any sense on what’s the worst that could happen if i set the wrong pins?

    #106361

    Jeffeb3
    Participant

    Any sense on what’s the worst that could happen if i set the wrong pins?

    Without looking at the datasheets for the various parts, I’m not really sure. There’s always a chance you’ll let the magic smoke out, but I doubt that’s possible. You could toast the atmega if, for example, you tried to set an endstop pin high and it was shorted to ground. There might also be a combo that could break a driver, but that seems less likely.

    Can you just get it right the first time? 🙂

    #106516

    Pablo Casaña
    Participant

    bad luck today. keep loosing posts. Now even the complete post that was already there vanished after edit 🙁

    So again the post which was before the other:

    I have 2 end-stops in NC mode.

    If I use $5=0 I get alert xyxy, I can the trigger each endstop and the alert for it goes away.

    If I use $5=1, I get alert xyzxy why that? shouldn’t this be only z as i have zmin zmax not connected?

    If I use a2 jumpers and close zmin zmax (signal – ground) I keep getting XYXY and this does not change when triggering any of the endstops.

    So there seems to be more to do than this.

    What exactly was the necessary adaption in limits.c in this case?

    Hi Alex, Its easier change your endstops to NO than change the firmware.

    To import my MPCNC settings you have to work with UGS platform 2.0. I work with this program 6 mouths ago and works pretty well.
    Upload the last version #78315 and follow the instructions.

    #106517

    Pablo Casaña
    Participant

    Based on Pablo’s comment “last version was published 4 mouths ago” and his code from #74877. I’m pretty sure he was starting from fra589/grbl-Mega-5X version ec53762. If anyone wants to see his changes I made a commit for them in my fork.

    I also took a stab at rebasing on top of fra589/grbl-Mega-5X:edge to pick up the handful of changes to that repo in the last 6 months. My current (untested) branch is here. Now to see if I can hook it up to my Rambo!

    I John, great idea! Thankyou for your work, I don’t know how works Github to upload o modify something so thankyou.

    There is another post with all problems solved, with this version I have been working 6 mouths ago.

    Good luck with your Rambo modification.

    #106608

    Alex
    Participant

    Hi all,

    sorry, I have had a huge workload on other projects and was offline for a few weeks.

    I documented my changes in the tutorial. John, I think your changes on github are correct.

    Status uptdate from my side:

    I’m happy to be running on grbl with bCNC as frontend.

    Opted for blender-cam (instead of freecad) because I’m usually do my constructions in there (mesh based). COnversion to freecat (shpae based) does not work well for larger meshes.

    Blender-cam is great and offers grbl output- Start reading here

     

     

    #106821

    John Boiles
    Participant

    I’ve mapped out all the pins in a spreadsheet (see column E ‘Grbl (proposed)’). If someone had some time, I’d love a second set of eyes to verify it against the RAMBo schematic to check my work. In the spreadsheet I also compare against the Marlin RAMBo pins as an additional check.

    Now on to looking at how to set the digipots and mircostep setting.

    #106964

    John Boiles
    Participant

    Ok it sorta works! Motors move correctly (after flipping some stepper connectors), but homing does not yet work. I made three commits:

    One commit to add the pins for the RAMBo board: https://github.com/johnboiles/grbl-Mega-5X/commit/091a5ad65905d409e3900f9ff33c8b2b8b446fbd

    One commit to add support for digipots: https://github.com/johnboiles/grbl-Mega-5X/commit/598eff46d0c8957fc9b53c9f7470bcfe28387ef2

    One (janky) commit to add basic microsteps: https://github.com/johnboiles/grbl-Mega-5X/commit/dca34c9a26c09a684c8a5943b582ff9130f37bf1

    These are alltogether in my mpcnc-rambo-support branch if anyone wants to try them out. Please feel free to leave comments on the commits on GitHub if you are able to review my code.

    Next up, I need to get homing working!

    #107207

    John Boiles
    Participant

    @alexp so homing definitely works for you? I’m trying to understand what could be causing my homing to fail since movement is working correctly and I’ve added your INVERT_MIN_LIMIT_PIN_MASK code. Since movement works now, I am struggling to understand what else could possibly be different between our machines.

    #107300

    John Boiles
    Participant

    Ok it’s working now! I just ran a test crown. I had a bug in my pin assignments and I needed to set some Grbl settings. I’ve also made the microstep setting code not janky! So now, starting with a working RAMBo dual-endstop setup from Marlin, you can install the code from my branch, and then set a few settings in Grbl, and it all just works! Here are the settings I set:

    Reverse the homing direction for x and y axes (bitmask 11011 = 27)

    $23=27

    # Reverse the X1, Z, Y2 Axes (makes it work without swapping stepper connectors when switching from Marlin) (bitmask 10101 = 21)

    $3=21

    Back off from endstops a little bit more after homing (if needed)

    $27=3

    The final thing to do, I think, is to add a setting like the X_DUAL_ENDSTOPS_ADJUSTMENT setting from Marlin, that can capture the offset to adjust a single stepper to make sure the axes are perpendicular. I bet I can hook something in where setting $27 (“Homing switch pull-off distance”) is used

    2 users thanked author for this post.
    #107344

    Jeffeb3
    Participant

    John, this is huge. Good work.

    I would suggest posting another thread about it and then Ryan can easily link to it from firmware and ymwe can field rambo specific questions there.

    #107377

    JDGreen
    Participant

    Thank you for digging into this.

    I can’t wait to give it a try.

    I have a dual endstop RAMBo MPCNC that I use all the time.

    I have been looking forward to running it with BCNC vs OctoPrint

    #107387

    John Boiles
    Participant

    If anyone tries my firmware, make sure to comment out CPU_MAP_2560_RAMPS_BOARD and uncomment CPU_MAP_2560_RAMBO_BOARD in config.h

    Maybe I’ll make a change to make this the default for my branch

    • This reply was modified 3 weeks, 6 days ago by  John Boiles.
    #107389

    John Boiles
    Participant

    I want to take a stab at this last feature then I’ll make a thread!

    #107391

    JDGreen
    Participant

    John – Thank you again for developing this solution for the RAMBo…Just to make sure I understand properly, does your version support dual endstops (autosquaring)?

    #107402

    John Boiles
    Participant

    @jdgreen yes, my version supports Grbl on RAMBo with dual-endstops. I’ve kept all the pins consistent with Marlin so that you can swap between the firmwares without moving any cables.

    It currently just homes to all 4 endstops and does not apply any correction to correct for out-of-square endstops. I’m working on adding support for per-endstop offsets so it can automatically square itself after homing (similar to the {X,Y}_DUAL_ENDSTOPS_ADJUSTMENT / M666 settings in Marlin).

    • This reply was modified 3 weeks, 6 days ago by  John Boiles.
    1 user thanked author for this post.
    #107679

    John Boiles
    Participant

    Ok I finished support for endstop offsets and I created a new post for folks to try it out.

    1 user thanked author for this post.
    #109739

    Andy
    Participant

    Hey guys

    Thanks for this awesome work! I am running my MPCNC with this version of GRBL and CNC.JS (ugs for sending the settings-file). Everything works fine.

    But I would like to operate my machine with soft limits enabled ($20=1). When enabled, at startup I run into problems with my Z axis. It is possible, that I can’t move it up, because of the soft limits.

    Now one solution could be to install a limit switch on z axis (which I would like to do) and home Z after startup. In this version of GRBL, the homing sequence doesn’t home the Z axis. So I tried to re-enable Z homing along X and Y. Therefore I changed the homing sequence in config.h into this:

    #elif N_AXIS == 5 // 5 axis : homing
    #define HOMING_CYCLE_0 (1<<AXIS_3) // Home Z axis
    #define HOMING_CYCLE_1 ((1<<AXIS_1)|(1<<AXIS_4)) //HomeX
    #define HOMING_CYCLE_2 ((1<<AXIS_2)|(1<<AXIS_5)) // HomeY

    After reflashing the Arduino with the updated config.h, there was no change. This doesn’t seem to change anything in the homing sequence, it’s still first homing X, then Y, Z doesn’t move.

    Could anybody help me modify the files, so Z-homing is enabled?

    Thanks!

    #109740

    Jeffeb3
    Participant

    FWIW, in Marlin, we added the ability to have soft stops for X and Y and disable them for Z, otherwise, it wouldn’t go down into the workpiece (Z < 0).

    #109741

    Andy
    Participant

    So you think I should try to disable soft limits for Z instead of homing Z?

    When I start up and do homing, GRBL sets all machine coordinates to negative max travel (in my case -640 and -370, which would be the lower left corner). Z remains at 0. That means, I can’t move Z up, just down in negative direction. With Z homing enabled, the Z axis would go all the way up.

    #109743

    Andy
    Participant

    Or… Did I configure something wrong? Should bottom left corner not be negative?

    #109744

    Jeffeb3
    Participant

    I don’t know enough about grbl to say, I was just suggesting another possible solution. I am still 1000 miles away from this branch of grbl.

    1 user thanked author for this post.
    #109783

    John Boiles
    Participant

    @nextnix: bottom left should indeed be negative. The top right of your machine is 0,0 in Grbl. I saw somewhere in their doc that they do it that way because that’s what traditional CNC machines do. It would be great to have a max travel endstop on the Z axis! I haven’t set that up on mine though, so you’re on your own as to how to add that. Please update us here if you get it working! Soft limits would be a great thing to support.

    1 user thanked author for this post.
    #109795

    Andy
    Participant

    Thanks Jeff and John. I keep trying and report back, if I make any progress.

    #109805

    Andy
    Participant

    Found the solution: I was changing the wrong file. If you want to try this yourself, then make shure to change the config.h in arduino library folder from this:

    #elif N_AXIS == 5 // 5 axis : homing
    #define HOMING_CYCLE_0 ((1<<AXIS_1)|(1<<AXIS_4)) //HomeX
    #define HOMING_CYCLE_1 ((1<<AXIS_2)|(1<<AXIS_5)) // HomeY
    //#define HOMING_CYCLE_2 (1<<AXIS_3) // Home Z axis

    to this:

    #elif N_AXIS == 5 // 5 axis : homing
    #define HOMING_CYCLE_0 (1<<AXIS_3) // HomeZ
    #define HOMING_CYCLE_1 ((1<<AXIS_1)|(1<<AXIS_4)) //HomeX
    #define HOMING_CYCLE_2 ((1<<AXIS_2)|(1<<AXIS_5)) // HomeY

    Now it is working! Homing sequence first homes Z (all the way up), then homes/autosquares X and Y.

    $20=1 soft limits enabled, so you cant jog the machine out of its range.

     

    #110162

    Pablo Casaña
    Participant
    Hi, this is a good idea as long as you have a endstop at the top of the z axis. 
    Working in negative coordinates is completely normal, it is assumed that where you do the homing it
     will be 0.0 (then all along the machine is negative). 
    The reason to comment Z limit line is beacause I haven´t got z limit switch. 
    With GRBL you have to change your working mind from 3D printer to CNC, beacause cncs works in different way.
    An example, after I do homing (x,y), I look for the stock zero (G92) then, near that point I look for the Z 
    zero with a z probe, beacause my table isn´t perfectly leveled and we have different bits with different 
    sizes.
    To be more profesional,I save that z probe position (G28.1) and then when you have to work with another 
    bit you only have to press G28 do a new Z zero.
    I hope you undertand me.
    • This reply was modified 2 days, 17 hours ago by  Pablo Casaña.
    #110171

    John Boiles
    Participant

    @nextnix could you share with us how you have the zmax endstop mounted on your mpcnc?

    • This reply was modified 2 days, 16 hours ago by  John Boiles.
Viewing 30 posts - 91 through 120 (of 121 total)

You must be logged in to reply to this topic.