Grbl mega ramps

Ok, I know, I know, ramps ramps. But I wanted to mess around with grbl mega on my primo. Didn’t realize there was a difference between the 1.6 and the 1.6+, so I had to solder up my drivers. Oops. As far as I can tell that’s all I have to do, and the pinout is supposed to be the same.

So, I got my pair of x motors to both move. Then I got them to move in the right DIRECTION. Started with just one of them homing, but I fixed that too.

Now I’m stuck at getting the X2 to obey its endstop. X1 behaves well. I’ve tried all 6 endstop pins, but he just keeps marching. I’ve verified that the switch has continuity at the board connector when triggered and is open when not.

Ideas?

1 Like

There were similar problems for @heath, IIRC. We went through a bunch of stuff in the grbl mega thread. I can’t remember what we looked at. You can query the state of the endstops. Similar to M119, but I think there might have been a bug where the invert mask on the endstops or the homing direction or the stepper direction wasn’t propogated through everywhere, so you had to wire them in a way that would make the setting 0, and then the logic for dual endstops would work. I can’t remember now though.

1 Like

If we’re thinking of the same thing, wasn’t that for trying to get the stops to work normally closed? That will be a second step for me, since I’ve wired mine normally open so I only have to tackle one problem at a time.

Got some time to dig through the cpu_map after work.Looks like the endstop is assigned to D42 which is in the AUX2 group. Y2 goes to D44, same group. Works fine over there, but I don’t need x max or y max, so I might try to remap that

Edit: having some trouble finding the pins file…
EditEdit: Nevermind, it’s more “downer” the cpu_map

Well, once I figured out the whole “port” thing, it was super easy. I moved the max values for axes 1/2 to the min assignments for 4 and 5. Swapped the mins to the max because the compiler got mad when I tried to comment that part out.

1 Like