MPCNC, Arduino Uno, CNC Shield and homing

Well, it’s more than a simple config setting, since you’re tossing the entire industry’s convention out on its ear by having home be top-left, rather than bottom-left.

Let me guess, you’re a programmer, right? Old school, at that. I remember those left-handed graphics days… Phong-shading a polygon skull in Java before AWT or Swing… Palette-shifting as animation… Good times… But, this is the modern world, and the modern world is right handed! And it’s a positive world! So your 0,0 is bottom left, and everything is in the positive X,Y space! At least, in machine terms. You may fiddle with the workspace a bit, and get into negative workspace, but machine space is always positive! Yes! :smile:

2 Likes

It looks to me like you’ve got the right homing options specified, but it is always possible the documentation you’re working from has a glitch. Have you tried other options for the homing direction mask?

Which version of GRBL are you running? There’s a bunch of new (to me) parking configuration options in 1.1H. I was poking around in the config.h in the early hours this morning, and it caught my eye but my build isn’t to the point where I was ready to set any of that yet.

It is helpful to decouple “where I want the machine to go to be out of my way” and “where do I want to measure my coordinate system from.”

Parking allows you to set coordinates to which the machine knows to return when told to park itself. This can be a convenient location to complete a tool change, or to ensure the gantry and tool move out of the way at the end of a job, or where to go if the “safety door” is opened (which can also be triggered by the pause switch available on the CNC shield)…

2 Likes

UGS runs in Linux give it a look CNCjs is good to I ilke it a lot but the wizard may give you a leg up.

Another thought - do you have a limit switch on Z? I had to play around with the homing sequence when I put the same shield you’re using in my K40 laser. The normal homing sequence tries to move Z out of the way first, and there was no Z axis in the laser.

1 Like

This sounds like you’re trying to have a dual-endstop setup, which is only possible with the RAMBO board and five stepper drivers.

You can certainly start every job from the same position by touching the tool to a known spot and issuing a G92 X0 Y0 Z0 to tell the controller that this is “Home” and that wouldn’t require any endstops.

The convention here is use endstops for the MIN locations, not the MAX position, and furthermore, all endstop switch status is ignored during machining and only used during a G28 homing cycle.

Do you have a build for this I am looking a K40 and am interested

The K40 has been gathering dust for a while, so I was going to update it to the version I will be putting on the MPCNC in a few (hopefully) days.
I should be able to get my $$ setting dumped later today.

I was setting up for using Lightburn, which insists the origin be in the lower left corner, but the limit switches in the machine were (and still are) X Min, Y Max, just like what Max is trying to accomplish. I got there, so I know it’s possible, but it was long enough ago that I can’t recall the path I took to get there.

Yes I feel that one I forget to much sometimes If you get back to it let me know I was looking to do what you are soon

I’ve had end stops on my mpcnc from the beginning. I still don’t use the auto square firmware. I use them to get a known x y 0. Hard stops on the other end.

I don’t want to hijack this thread too badly. I’ll put my remembrances together and post another thread or send them straight to you.

1 Like

@kvcummins haha yeah you got me :joy:
I honestly just figured thats not a problem, because the docs say there is the X- Y+ Z+ homing setting… maybe there is more to it, maybe the doc is faulty at that part, or or or :smiley:

@ttraband I have not yet tested other homing directions no, but I will… and try to figure out how I get it to home my way I guess. Its the latest GRBL version, 1.1h that is, and I never used GRBL before, coming from 3D printers :slight_smile: Oh and I removed the Z homing within the config.h in GRBL before uploading, so in theory, according to the documentation that shouldnt be a problem.

Anyway I gave up for today, looking further into that later I think, I really do want to get that going, but I guess for the very first projects and to test out things its not all that important :slight_smile:

I’m going to dig into the configuration running on my K40 a little later this afternoon. It’s homing to X Min, Y Max, which is I believe what you’re attempting. It’s running Grbl1.1 but I don’t recall what letter. I’ll share what I dig up.

2 Likes

Wow. You guys really went off the rails there. :smiley:.

If your machine has a limit switch in the negative direction, the homing direction mask can invert the axes’ direction.

So it sounds like you got it right. I would have expected a 6 to be right though, because homing to positive seems inverted to me.

There is also a status message you can get to tell you the state of the endstops.

I have also learned that if you completely turn off homing, it doesn’t require a reset/unlock at startup, IIRC. If you choose to go that route. I used grbl on a shield with cncjs for a while and I really liked it without endstops and I used the heck out of workspace coords.

The hard stops some people were talking about is that once the machine starts, the two X motors move in lockstep. So before enabling them, it is good to push the machine against some chunks (of something) in the corner that forces it square. Then enable the motors in that position and move the machine with the motors after that. Jog to your start origin and set work coordinates.

Cnc.js and grbl have good sync and the workspace offsets are awesome.

1 Like

I just checked my Grbl ESP32 ZXY table and it homes to -X,-Y and it has $23 set to 3. That seems odd to me, but I don’t make the rules :).

Is it possible something got flipped when you did this?

@jeffeb3
Im not sure anymore at this point lol… but since I want it to home top left, that should be X- and Y+ ?! Hence my $23=1 Setting in GRBL… 6 would be X+ Y- Z-.

There was indeed a message in the Console log, Im not 100% sure anymore about the text, but it was Error 8, homing fail.
My plan was to use 3D printed “square checkers” on the X and Y axis before I turn on the machine, so get in position to use the square checkers to make sure it is “100%” square, turn on → motors lock position → home. Of course that was just my plan and idk if that really is the best solution :slight_smile:

As for your homing to X- and Y- on #3 I dont see a problem with that, assuming the GRBL docs are correct!

As for Z-homing, I followed the docs for that as well, which should be (and is, just checked again):
#define HOMING_CYCLE_0 (1<<X_AXIS)
#define HOMING_CYCLE_1 (1<<Y_AXIS)

default is:
#define HOMING_CYCLE_0 (1<<Z_AXIS)
#define HOMING_CYCLE_1 ((1<<X_AXIS)|(1<<Y_AXIS))

Okay so I just tested things…

limit switches connected to: Y+ and X-
GRBL set to $23=6 (which should be X+ Y- Z- according to docs)

and it finally moves into the right direction for homing, it doesnt work however because, it touches the switch and stops, then sloooowly moves away again, but after that it drives straight into the switch again with no mercy :thinking:

I guess that is no one step further but not actual success :smiley:

Any ideas?

1 Like

Yes. That seems right to me.

I mean, you should be able to see the state of the endstop switches before homing, to make sure you have them the right way around. Looks like you can add 16 to the $10 (the default might be 3, so $10=19, and then ?. It should show LIM=000, which is none triggered. If you push the X, ? should say LIM=100.

Sounds good. Just don’t forget to unhook the square checkers before homing :slight_smile: .

Looks good to me.

I’m trying to think of something to try that is simpler to try. Maybe the X endstop needs to be plugged into the minus side?