You are right, it’s not grbl32. It’s a forked version of grbl-Mega-5X which is a forked version of the regular grbl for arduino boards. grbl-Mega-5X provides 5/6 axes support for Arduino Mega2560 boards.
The fork initiated by @johnboiles makes use of the additional axes to replicate the trick you did on Marlin for dual endstops. It works specifically on RAMBo boards as far as i know.
Does grbl32 support dual endstops on the MPCNC ? Can you point me to the available instructions ?
I can work on a draft instructions page if that makes sense, but the question was more about a new forum category instead of this growing thread.
Yeah, GRBL_ESP32 does it a little differently. It homes to one end until the sensor triggers, then it homes each stepper individually, thereby allowing you to chain two switches on one pin for your endstop. Then you only need XMin and YMin pins. Marlin does it with each stepper associated to its own endstop pin (hence dual endstops), but the end result is the same: both sides of the axis are within one microstep of each other, relative to their endstop switch positions. (note the qualifications, they are important; dual endstops/auto-homing is not a simple panacea for out-of-square builds or initial starts)
The version of Grbl in this thread is very specific to MPCNC + RAMBo + dual endstops. It’s not vanilla grbl-Mega-5x, I’m not sure anyone wants to have 5+ axes on a MPCNC except for dual endstops ?
I don’t know, maybe just a broad “Grbl” can help more people.
That’s a strange one. I don’t have a RAMPS board so I can’t confirm the code in ramps-updated is working. My memory is a little fuzzy now but looking at the Git history it looks like the ramps-updated branch is just @enducross’s work applied on top of the grbl-Mega-5x repo. I didn’t make any additive changes there – I just used that as a base to then go on to add RAMBo support in the mpcnc-rambo-support branch. Looks like development in grbl-Mega-5x has continued since I pulled in their code so it might be worth looking through their commits since I started my fork and seeing if they’ve made any changes that would have fixed this.
Still, hard for me to imagine what in the code would be causing this on your RAMPS board, but not on the RAMBo boards (which use nearly the same motion control code).
Thanks @vicious1 and @kvcummins, I was not aware of this esp32 version. Long list of features, looks very promising.
However it doesn’t support setting an offset on the endstops like we do on Marlin or this version of Grbl. I’m not complaining about it, I’m just adding this for reference. See https://github.com/bdring/Grbl_Esp32/issues/687
Nothing beats a well-placed endstop… If it was difficult to move the endstops on the MPCNC, I’d agree that this would be an issue. But with the design we are working with, it’s simple enough to manually adjust the endstops to properly square them up.
I have been doing some deep digging into motion_control.c. What happens is that G0/G1 function perfectly but G2/G3 cause the gantry to twist. All four motors cause the gantry to rotate clockwise for G2 (go figure). I have it whittled down to being sourced in mc_arc(). Once I understand the coding and how numbers get created, I can see what is going goofy. I will drop in some code to print out its calculations when running G2 and see what is happening since there appears to be three motion components going on here - one linear, one sine and one cosine. FYI - this is the same fight I have with my 3D printer and Marlin with G2/G3 as well.
My opinions here, not saying one is better than the other. Just saying why I personally prefer Grbl for CNC/Laser. I have several 3d printers on Marlin and I’m happy with it.
Marlin: Basic 3d printer features worked well for me. However when I tried to use “fancy” CNC features, the experience was deceptive. For example I went to debug Marlin code because spindle/laser PWM was not working. I spent hours figuring out why. Turns out the feature was broken a long time ago and nobody noticed. I think this is literally the case : most users are 3d printers and don’t care when CNC features stop working. Code evolves at insane pace. I feel like living on the edge and doing poor man hacks : why use a spindle/laser command when you could just use fan control to set the PWM value ?
Grbl: Everything is dedicated to CNC/Laser, everything works as expected (as far as I am concerned). I like soft limits which prevent me from crashing my machine. I like having separate machine coordinates and workspace coordinates. Laser/Spindle control works well. I like smooth accelerations/decelerations. Code evolves at very slow pace. I feel empowered and confident.
I might be missing out, because I disabled soft stops. Probably ought to set that up.
I didn’t know that marlin doesn’t separate workspace coordinates from machine coordinates. I just set up switch for tool length measurement that depends on this. There we have it. Laziness justified! Thanks for your thoughts (and not saying either is better ).
Grbl_esp32 is (sorry folks) much more mature and has a lot of people dedicated to it. If you ask for help in the ~slack~ discord, the answers are good and quick. It is definitely worth a look.
I think a software/grbl category is good. Probably long overdue. Maybe I can write a sticky post to get people using the same terms so we can be specific about the core grbl boards, the esp32 version, and the rambo and ramps 5x versions.
You run Grbl_esp32 for your machine? I love the ESP* chips I have a bunch all around my house for various things. Where did you order your board? That’s definitely the direction I’d go if I were starting fresh.
Agreed, This does seem to happen a lot. It is the actual reason I ventured back into GRBL. Kinda want to spend more time with hardware than firmware. I agree can’t fault anything but fast evolution though. Once identified a PR gets merged quickly.
Sweet! maybe we can get this figured out and get a PR in. I have never even touched GRBL code but it really seems like this could be manageable for use to figure out and get something whipped up for Bart? Is the tough part implementing the M code?
Followup - motion_control.c is clear on the position data being generated. It is now onto planner.c. There is a section in there that sets the direction bit for the move based on some calculations. That is my next place to look. For example axis1 and axis4 get set to go different directions because a direction calculation is getting muffed. Progress is being made here. The fun part was getting properly formatted data to be echoed out the serial port back.
I have 5x on my ramps, and there is an offset for the endstops. $14x I think.
About the switch for tool length, and to work pretty well. I get to it with G53 x1 Y26 (the xy where it lives).
Edit : Julien pointed out below it’s $15x. Guess the ol’ memory ain’t what it used to be.
I have had a few. I use one of the two driver tmc boards in my zenxy prototype. I used the 2 driver without tmc in my camera slider and I have the “mpcnc” grbl esp32 board in my low rider. I bought them all from bart dring in tindie. He is a legend in open source cnc and he has out a lot into this particular project.
The real challenge is the IO. It has tons of processing, but not many pins. So the latest universal board has a port expansion chip too and can handle a lot of stuff.
The only trouble I’ve had is that some of the esp32 boards don’t work well with cncjs. I still have a v1pi on my LR and I couldn’t connect last time I had a project. Maybe it was just the usb cable? I have heard from one of the laser threads that it might be the uart chip on the esp board. Dunno.
Grbl_Esp32 looks like a good option for a fresh start. M code shouldn’t be a problem because Grbl uses $ vars for settings. Instead of doing M666 X1 you do $150=1. I guess there is no specific parsing code to write here. We can definitely have a look at the issue and submit a PR. I don’t have the hardware yet, but I’m going to order some boards from Bart.
Grbl version discussed in this thread (@johnboiles please pick a good name for it ) can still be useful for people with a RAMBo board. It’s not as feature rich because of the limited Atmega processor, but it works.
Unless they’ve really changed the structure of GRBL you can probably fairly easily port my patch over. It’d be nice, if possible to keep the same config value numbers.
sorry I’ve been absent here! I’m glad this has been useful to some of y’all!!
).
) can still be useful for people with a RAMBo board. It’s not as feature rich because of the limited Atmega processor, but it works.