Thanks for the tip!!! I will add that to my search.
Did not change things a bit. The problem appears to be “sourced” in motion_control.c in the mc_arc() subroutine. Even in Marlin on my 3D printer, I had the same unresolved issue with G2/G3. This will be a fun one to solve but first I have to coax out some data from the program as it runs.
Hi, as this thread gets some traction, can we create a dedicated category for the Grbl + dual endstops firmware and contribute by creating new threads inside ? @jeffeb3 maybe ?
I use this firmware and I like it. I find Grbl more satisfying than Marlin for CNC or Laser use case. The dual endstops feature is really clever too. Grbl + dual endstops is theorically the ideal combo for me. 100% I would not install Marlin again, except in case of horrible unresolvable issue with Grbl.
As many of us comes from 3d printing, using Marlin as the default firmware makes a lot of sense, and starting simple without dual endstop makes sense too. I am not saying Grbl + dual endstops should compete with the default firmware, but I think it’s a good option for more experimented users and it deserves its own category.
1 Like
I was going to weigh in on a separate category, but it turns out I can’t support my opinion very well, so I won’t, lol.
I’m curious about why you like grbl so much more than marlin. I jumped on board back during the arc calculation kerfuffle. Turns out I don’t really miss the mini display because I prefer to run from an old computer (which I think I could do either way). I hate clicking through 8 screens to get set up and start a job, so there goes the biggest advantage (imo) of marlin. Configuring them is about the same to me, and once set I don’t really worry about it.
Probing worked the first time I set it up in grbl, which was nice (from xy). But I think the arcs have straightened out now and marlin supports most (all?) of the things grbl does.
I don’t intend to go back to marlin either (probably because I’m lazy), but like I said, I’m curious about your reason.
We can sidestep the arguing over what is best. Do what makes you happy.
I may have the permissions to make a new category, but I will defer to @vicious1. In my opinion, if you’re willing to stick around and help @jlirochon, then it would be more than worth it to focus the questions about grbl 5x at one section in the forum.
I don’t think anyone was advocating for arguing over what is best. I certainly wasn’t, and I should hope you don’t think i was, either.
Just sounded to me like someone had good reasons to like grbl better, and I’m curious why. Not so I can change his mind, but so I can coopt his reasons and justify my admitted laziness.
So this is different that the way grbl32 does it correct?
We can put up an instructions page for sure, but I have very little experience with GRBL and am not confident enough to do so. I have a grbl32 board that is working but I need more time before I write any instructions beyond what is already there for it and seems very clear.
This is a fork of the main grbl code, with code updates to work in 5 axis and for the rambo board. It is completely separate from the grbl_esp fork that bart wrote.
I think the ask is just another section in the forums, not a page in the docs.
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.
Yes, he has it worked out in a slightly diffrent way that we do it in MArlin but seems good. https://github.com/bdring/Grbl_Esp32/wiki/Motor-Ganging-and-Axis-Squaring this is the wiki but I think the info is in a few places.
We can do a separate section no problem. In software, so GRBL or more specific, GRBL5X?
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)
1 Like
Thanks
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.
1 Like
Hey y’all 
sorry I’ve been absent here! I’m glad this has been useful to some of y’all!!
2 Likes
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).
1 Like
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.
1 Like
Hi @turbomacncheese, Thanks for asking !
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.
2 Likes
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 
).
1 Like
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.
4 Likes