I think my whole life is.
1 Like
Finally it didnāt fix the problem. Iām stuck with the same problem as @heath
Will try the version proposed by @jeffeb3 to see if it make change for me.
I copied that from further up in this thread. There is a lot of talk about endstops up there.
Same problem with this firmware. Everythings works fines except homing on x axis. Both motor engaged but only one motor is driven. @heath Can you try to home by placing you x axix a few millimetres from the limit swith? So even with the problem, you can also confirm that homing is working correctly on Y axis.
I can confirm neither X nor Y axis homed ācorrectlyā the way I was doing it. But I just had a thought that homing each axis individually with $HX or $HY may behave differently than homing everything with $H (āhome allā). I never got far enough with a home all procedure to know if Y behaved right. I always killed the power when X started twisting from the one motor not moving and I assumed Y would do the same. In the morning, Iāll do as you suggest and let the full procedure finish.
@cinosh07 I couldnāt stop thinking about it and couldnāt wait until in the morning. What I discovered is when I do a normal home with $H, the Y axis does indeed home correctly as desired. If I twist the axis out of square before powering it on, and then home ($H), each motor will stop when its respective limit switch is triggered (and then bounce back). However, only one motor (the front one) moves on the X axis. The rear X axis motor is engaged and does not move.
Homing the axes individually (with $HX or $HY), the X axis behaves exactly the same. But with the Y axis, both motors stop and bounce back together if either end stop is triggered.
So it looks like you and I are facing the exact same issue.
1 Like
Unless the X2 thinks it is triggered, this seems like a software bug. Now that you have a config that works, what happens if you go back to a stable version of the maim grbl 5x?
@jeffeb3 Well this is not an easy thing finding the latest stable version. Thatās whatās iām trying to figure out. By look at the threads of this post, itās seem that the Rambo version is the most up to date. The one that people seem to be happy with. But when i try with this version for ramp 1.4 i cannot get it compile. I got error. But it compile ok with rambo board selected.
I lost 
Iāve ordered a gbrl_esp32 board for my MPCNC. But with covid, Canada Post is putting in quarantine all package for at least a month. Plus they are a month late in delivery. So i will not getting it until the end of summer. I really prefert Grbl over Marlin for CNC. My other CNC is Grbl. I would like use same software on both.
Thatās why iām struggling to fix that issue. I did a lot of comparison between version of the firmware. Itās seem that the development stopped with the rambo board working, leaving ramp 1.4 not working.
Iām trying to figure out whatās missing to 1.4 to compile correctly. But for now, no luck.
The rambo has different pinouts, so I wouldnāt expect that to work.
I was thinking the main fork: https://github.com/fra589/grbl-Mega-5X would be more actively developed.
I have a grbl esp board, and I just configured it for the lr. I havenāt tested it yet, and I donāt use endstops. But it seems like a good solution. If you have your esp32 board already, you can compile it with the simulated hardware and play with it. I have been using one on my zenxy for more than a year and it works well.
In the meantime, you can definitely use the cnc without endstops.
I get that this is frustrating. But the basic assumption is that 3 drivers will work in grbl (with serial wiring). 5 drivers/auto squaring works in Marlin. 5 drivers in grbl is not solid ground, with the exception being grbl_esp, which has active support and development.
I am honestly not sure how grbl_esp32 handles auto squaring, because both X motors share the same endstop. My guess is it moves both until one touches. Then it backs them both off and tries one at a time until they are both set.
@jeffeb3 with this board tindie{dot}com{slash}products{slash}33366583{slash}grbl_esp32-mpcnc-cnc-controller-ver-122{slash}
Auto Square is suppose to work
Yeah. I have a v1.0 board, and judging from the documentation for the latest one, regarding wiring the endstops NC, both X endstops are on the same pin. Pins are critical real estate on the esp32, so Iām not surprised. I think there must be a trick in the software, like the dance I just mentioned, to use one pin to square two motors.
FWIW, Bart has a slack set up, and there are a few active users that really know what they are doing. I have asked a few questions there more often than not, Bart responds the same day. If you donāt know Bart, look him up. He has been working in open source cnc for a while, and has had a big impact.
A little more experimenting this morning and what I have realized is that when homing, X1 advances to the limit switch. X2 does not advance. However, X2 does retreat in sync with X1. Then X2 will stop again as X1 creeps toward the limit switch. So every homing operation twists X a little bit more as X2 only moves further away from the limit switch.
Using G0 commands, both X motors operate normally in both positive and negative directions.
Just to see what happened I used to last āofficialā grbl-Mega-5X repo, but replaced the config.h file with the (almost) working one. It compiled and flashed, but the only limit switch that acted right was Z. Two of the X and one Y limit switch were seen as triggered. Holding the switch down to trigger it for real made no change.
Iām about ready to throw in the towel.
For my part, iām giving up. Will wait for the new board
Iām giving up. Sticking with Marlin. Darnit.
I tried various things. Someone told me Marlin could only handle 1/4 microstepping and my 1/32 microstepping was the problem. So I set the jumpers to 1/4 and changed the steps/mm in the settings. No change.
I swapped cables and stepper drivers. No change. (Problem stays with the pin on the board.)
Iāve tried a dozen different versions of grbl-mega. I tried learning the code myself to try to diagnose the problem, but itās so much more confusing than Marlinās code.
Unfortunately, Iām done. Itās not worth buying a whole new controller to me.
Hey guysā¦ I just finished my LR2 and had success with getting homing to work with limit switches at all motors. I too went through a lot of headache with getting this to work, but you can make it happen.
First, Iād like to see what your config.h looks like; most importantly what you have N_AXIS set to (should be 5) and also the AXIS_n and AXIS_n_NAME defines. Finally, Iād like to see what you have after #elif N_AXIS == 5 // 5 axis : homing.
Next, I would get everything working with $3=0 (absolutely no direction invert mask). I had a LOT of trouble with one motor going the wrong way and my experience is that putting values in this register causes weird stuff to happen when an axis has more than one motor. The simple solution to this is to set $3 to 0, and reverse the connectors until all motors & axes go the correct direction with regular G-codes.
Then, try to home. You can use $23 to set the proper direction for homing on a per-motor basis. When I say āon a per motor basisā, this relates to the AXIS_n* defines in config.h. So on my LR2, my config looks like this:
#define AXIS_1 0 // Axis indexing value. Must start with 0 and be continuous.
#define AXIS_1_NAME āXā // Axis names must be in X, Y, Z, A, B, C, U, V & W.
#define AXIS_2 1
#define AXIS_2_NAME āYā
#define AXIS_3 2
#define AXIS_3_NAME āZā
#define AXIS_4 3
#define AXIS_4_NAME āZā // Letter of axis number 4
#define AXIS_5 4
#define AXIS_5_NAME āXā // Letter of axis number 5
(I snipped out the extraneous lines). So my output ports look like this XYZZX. The bits in the $23 mask register correspond to each: X1=bit0, Y=bit1, Z1=bit2, Z2=bit3, and X2=bit4. Using that, you can invert the proper motor for homing.
As far as limit switches go, I used shielded cable after having read horror stories about limit switches and noise induction from the motors. Mine are normally closed and work great. Itās a bit of a pain to figure out which set of pins goes with which switch (and be mindful of having the wrong switch paired with the wrong motor in a single axis; this will give you yet another headache). In any case, you just need to trigger the switches manually and query GRBL with a ā?ā and youāll get it figured out. I would not recommend the approach of taping switches closed because when GRBL reaches the end stop, it will try to do a pull-off and it expects the switch to change state within a certain time period. When it doesnāt, it will just enter the ALARM state.
Thatās all I have for now. Iāll monitor this thread to see if you guys have any questions/success. Just know that while itās Itās definitely a headache inducing process., what you want to do CAN be done.
1 Like
Could.u upload the config h here ?
I have not tried having no direction invert mask (setting $3=0) and flipping the physical connections where needed. I will try that when I get a chance. Maybe today, maybe in 2 weeks, I donāt know. Everything else I am certain is correct, but will provide the asked for files next time at at my laptop. For now Iām back on Marlin with everything working getting caught up on projects.
1 Like