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.
We are now in Software/GRBL
3 Likes
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.
2 Likes
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.
Edit: this is the commit
1 Like
I think grbl-mega-5x is a fine name for it. It would be nice to merge development with fra589’s original fork. I think most of the features make sense there as well.
2 Likes
Let’s open an issue to discuss this with fra589.
What I know is that fra589 merged a PR of mine where I pulled upstream changes from Grbl project. Your code may require some changes because of this. We will have to meet his requirements too.
Do you want to lead the effort of having your code merged into grbl-mega-5x ? I can help you if needed. I can lead the effort too. Let me know what works best for you.
1 Like
Just a reminder that @buildlog is a member here, too. So maybe if he pops his head in, he’ll see a mention… 
1 Like
I found the mistake! I was finding that sys_position and pl_position did not have matched axis[0] and axis[4] for X1/X2 steppers and the same for Y1/Y2. These values are needed to make the G2/G3 functions track correctly. The gantry was being twisted because X1/Y1 were getting the proper values and X2/Y2 were out in la-la land because their planner starting positions were whack to start with. So, I tracked down the section that sets the positions after homing in limits.c. I added a switch/case setup to copy over the proper values. I did a test run on G2 and it was a sweet thing to hear!!!
Here is the snippet of code with the change:
int32_t set_axis_position;
// Set machine positions for homed limit switches. Don't update non-homed axes.
for (idx=0; idx<N_AXIS; idx++) {
// NOTE: settings.max_travel[] is stored as a negative value.
if (cycle_mask & bit(idx)) {
#ifdef HOMING_FORCE_SET_ORIGIN
set_axis_position = 0;
#else
if ( bit_istrue(settings.homing_dir_mask,bit(idx)) ) {
set_axis_position = lround((settings.max_travel[idx]+settings.homing_pulloff)*settings.steps_per_mm[idx]);
} else {
set_axis_position = lround(-settings.homing_pulloff*settings.steps_per_mm[idx]);
}
#endif
#ifdef COREXY
if (idx==AXIS_1) {
int32_t off_axis_position = system_convert_corexy_to_y_axis_steps(sys_position);
sys_position[A_MOTOR] = set_axis_position + off_axis_position;
sys_position[B_MOTOR] = set_axis_position - off_axis_position;
} else if (idx==AXIS_2) {
int32_t off_axis_position = system_convert_corexy_to_x_axis_steps(sys_position);
sys_position[A_MOTOR] = off_axis_position + set_axis_position;
sys_position[B_MOTOR] = off_axis_position - set_axis_position;
} else {
sys_position[idx] = set_axis_position;
}
#else
//sys_position[idx] = set_axis_position;
switch[idx] { // added switch/case to copy over the home positions from x1 to x2 and y1 to y2 the home positions
case 0: // x1
case 1: // y1
case 2: // z
sys_position[idx] = set_axis_position;
break;
case 3: // x2
case 4: // y2
sys_position[idx] = sys_position[idx-3]; // copy frm axis stpr 1 to axis stpr 2
break;
}
#endif
FYI, I forked the codebase and added this snippet to it. Many more changes to come.
2 Likes
For reference, I opened an issue on grbl-Mega-5x to discuss if/how @johnboiles 's work could be merged : https://github.com/fra589/grbl-Mega-5X/issues/170
2 Likes
About the homing code snippet. I may recind this after I try an experiment. Amazing what one come up with when in a steaming hot shower. If this test works out, the code may be pulled and a warning proviso put elsewhere. Call it evolution.
1 Like
No matter what I do, I can’t get my Y axis to home in the correct direction. It homes away from the endstops. I’ve tried $23 = all manner of things, and it only seems to invert one stepper on the y axis, not both. Any suggestions?
That doesnt seem right. It’s a bit mask, so it should do something. I’m going to assume you know how the bit mask works and how to get the numbers to punch in for it. Does the normal travel work correctly? What happens when you just flip the stepper motor plug around?
Well, here’s my grbl settings now:
I’m homing in, from my perspective, the bottom right hand corner of the machine.
I actually managed to do a lengthy pen plot yesterday with these settings. Today, after turning the machine off, neither axis nor homing works. It seems like I have to change $3 and $23 almost at random. Now, the Y axis moves, but trying to home it causes the axis to twist. If I flip the plug, then homing works and moving doesn’t. It’s moving one stepper in the wrong direction during homing only.
It absolutely seems to be random.
Further edit, I changed my settings to this: https://pastebin.com/EPghXM4y
See, here I changed $3=1. That should invert Y. Now both X and Y jog properly. X homes properly. Y homes in the wrong direction. So I should set $23=2, which should invert the Y homing direction. I do so and now the Y axis twists. $23 inverts only one stepper.
Is it y1 or y2 that needs to be flipped?
Neither, from what I can see. grbl seems to be completely ignoring $23 now. If I invert Y with $3=2, there is no difference between $23=0 and $23=2 (which should invert Y during homing), if I run G28.1 Y0.
Now, if $3=0, so Y is not inverted, then the Y axis twists. $3 unequivocally inverts just one stepper. Setting $2 =2 also does nothing. I have no idea what’s going on. $23 = any number, from 0, to 9, to 27 is completely ignored.
Ok, I’m gonna revisit the bit mask so we can maybe figure out what’s supposed to be happening. Again, apologies in advance if you already know this, and let’s just hope it helps someone else, then. Since we’re on the dual endstops thread and you seem to have independent control of each y stepper, I think it’s safe to say each motor is on a separate driver. So what you really have is not just y invert, but y1 invert, right?
The mask let’s you take a single byte and assign multiple parameters. In this case, it’s some leading zeroes, then a combo of 1s and 0s for on/off, with the last 5 digits being for y2, x2, z, y, x. It’s read right to left (unless I’m mistaken… been a long time since I looked at this).
So if you want to flip y it’s 00010(ignoring the leading 0s for clarity). In binary, that = 2. It’s not hard to calculate, but there are hundreds of pages that explain it better than I’ll be able to type up here.
If you want to flip y2, it’s 10000 = 16.
If you want to flip y2 and z it’s 10100 = 20.
Use a 1 to flip that motor, calculate.
I had a similar frustration setting mine up, and I remember being really confused by the behavior, like the settings would change and the machine behavior wouldn’t, or the machine would change with the same settings.
Once I saw how the bit mask works, the machine started behaving the way I expected and the rest of the setup took minutes. Hopefully it works out the same way for you and it turns out to be some combination of settings that were inadvertently getting set together.