GRBL running on Ramps

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!

@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.

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

3 Likes

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.

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

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

I want to take a stab at this last feature then Iā€™ll make a thread!

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)?

@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).

1 Like

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

1 Like

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!

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).

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.

Orā€¦ Did I configure something wrong? Should bottom left corner not be negative?

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 Like

@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 Like

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

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.

Ā 

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.

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