# Homing XYZ with \$H gives negative max travel XY in [machine position] #435

Closed
opened this Issue Jul 4, 2016 · 7 comments

Projects
None yet
4 participants

### jack-zande commented Jul 4, 2016

 Hello all, I have made my own CNC milling machine, using the following setup to control my machine: Arduino UNO (clone) GRBL V0.9j (flashed on the Arduino UNO) Universal g-code-sender V1.0.9 (Nov 11 2015) In order to move the steppermotors X, Y and Z correctly my settings in GRBL V0.9j are: \$3=2 (dir port invert mask:00000010) Z is normal, Y is only reversed, X is normal, last 3 bits. \$20=0 (soft limits, bool) \$21=1 (hard limits, bool) \$22=1 (homing cycle, bool) \$23=3 (homing dir invert mask:00000011) \$27=1.000 (homing pull-off, mm) \$130=200.000 (x max travel, mm) \$131=190.000 (y max travel, mm) \$132=95.000 (z max travel, mm) I am using X, Y and Z limit switches in both directions at the begin and end travel of X, Y and Z direction. Home switch X is at the left end travel way. Travel X is from left to right from 0 to 200 mm. Home switch Y is at the back end travel way. Travel Y is from back to front from 0 to 190 mm (Movable milling table in Y direction). Home swith Z is at the top end travel way. Travel Z is from top to bottom from 0 to -95 mm. Moving done is giving negative positions. \$3 = 2 (or binairy 0000_0010) > steppermotor directions All movements of the steppermotors are according to X, Y and Z directions according to FREECAD or CAD programs X,Y,Z planes. So the travel ways are correctly made with the \$3 command. \$23 = 3 (or binairy 0000_0011) > homing directions z,y,x (last 3 bits) To travel to home switch Z, no change is needed. To travel to home switch X, a change is made with the \$23 command to reverse its travel position to the left home switch X. To travel to home switch Y, a change is made with \$23 command to reverse its travel position to move the milling table to the back home switch Y. Using universal g-code sender V1.0.9 gives then he following outcome. Starting with all zeros of X, Y and Z in "work position" and "machine position". After \$H, the homing positions are in "work position": X= -199, Y= -189 and Z = -1. And for "machine position": X= -199, Y= -189 and Z = -1. Homing pull-offs are 1mm. Finding home switches gives the positions: X = -200, Y = -190 and Z = 0. ????????? ----- My surprise is, why not homing for X = 0, Y = 0 and Z = 0 ? ----- ??????????? Homing should give zero positions, I supose. All X, Y and Z steppermotors are moving correctly according to X, Y, Z plane in FREECAD or CAD (Left is -X and right is +X. Back is +Y and front -Y. Up is +Z and down is -Z). FUTHER INFORMATION: I can reset the "work position" to all zeros for X, Y and Z. with the [RESET ZERO] button. But not for the "machine position". Moving X, Y and Z steppermotors are correctly done with the machine controls. If I reset the Arduino UNO board with the hardware switch RESET then I can get zeros for the "machine position" after clearing the alarm with \$X to unlock the Arduino UNO board. Greetings Jack Zande

### jahnj0584 commented Jul 4, 2016

 There is a guide on the grbl wiki on how to recompile the code to make the homed position 0,0 and not -X,-Y. It's pretty basic and did it on my machine. IMO it should be standard that way. On Jul 4, 2016 2:47 PM, "jack-zande" notifications@github.com wrote: Hello all, I have made my own CNC milling machine, using the following setup to control my machine: Arduino UNO (clone) GRBL V0.9j (flashed on the Arduino UNO) Universal g-code-sender V1.0.9 (Nov 11 2015) In order to move the steppermotors X, Y and Z correctly my settings in GRBL V0.9j are: \$3=2 (dir port invert mask:00000010) Z is normal, Y is only reversed, X is normal, last 3 bits. \$20=0 (soft limits, bool) \$21=1 (hard limits, bool) \$22=1 (homing cycle, bool) \$23=3 (homing dir invert mask:00000011) \$27=1.000 (homing pull-off, mm) \$130=200.000 (x max travel, mm) \$131=190.000 (y max travel, mm) \$132=95.000 (z max travel, mm) I am using X, Y and Z limit switches in both directions at the begin and end travel of X, Y and Z direction. Home switch X is at the left end travel way. Travel X is from left to right from 0 to 200 mm. Home switch Y is at the back end travel way. Travel Y is from back to front from 0 to 190 mm (Movable milling table in Y direction). Home swith Z is at the top end travel way. Travel Z is from top to bottom from 0 to -95 mm. Moving done is giving negative positions. \$3 = 2 (or binairy 0000_0010) > steppermotor directions All movements of the steppermotors are according to X, Y and Z directions according to FREECAD or CAD programs X,Y,Z planes. So the travel ways are correctly made with the \$3 command. \$23 = 3 (or binairy 0000_0011) > homing directions z,y,x (last 3 bits) To travel to home switch Z, no change is needed. To travel to home switch X, a change is made with the \$23 command to reverse its travel position to the left home switch X. To travel to home switch Y, a change is made with \$23 command to reverse its travel position to move the milling table to the back home switch Y. Using universal g-code sender V1.0.9 gives then he following outcome. Starting with all zeros of X, Y and Z in "work position" and "machine position". After \$H, the homing positions are in "work position": X= -199, Y= -189 and Z = -1. And for "machine position": X= -199, Y= -189 and Z = -1. Homing pull-offs are 1mm. Finding home switches gives the positions: X = -200, Y = -190 and Z = 0. ????????? ----- My surprise is, why not homing for X = 0, Y = 0 and Z = 0 ? ----- ??????????? Homing should give zero positions, I supose. All X, Y and Z steppermotors are moving correctly according to X, Y, Z plane in FREECAD or CAD (Left is -X and right is +X. Back is +Y and front -Y. Up is +Z and down is -Z). FUTHER INFORMATION: I can reset the "work position" to all zeros for X, Y and Z. with the [RESET ZERO] button. But not for the "machine position". Moving X, Y and Z steppermotors are correctly done with the machine controls. If I reset the Arduino UNO board with the hardware switch RESET then I can get zeros for the "machine position" after clearing the alarm with \$X to unlock the Arduino UNO board. Greetings Jack Zande — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub #435, or mute the thread https://github.com/notifications/unsubscribe/AQlzDICCYpav4ok6f5qj5wIPc3s3F0Wfks5qSUdDgaJpZM4JEjnL .
Author

### jahnj0584 commented Jul 4, 2016

 https://github.com/grbl/grbl/wiki/Frequently-Asked-Questions#why-is-grbl-in-all-negative-coordinates-after-homing-or-it-so-annoying-and-not-what-im-used-to "For use cases outside of CNC mills or people annoyed about the machine being in negative space, there is a compile-time option that will force Grbl to set the origin to wherever the homing cycle ends. So, if you'd like a machine in all positive space, simply uncomment the HOMING_FORCE_ORIGIN option in the config.h file, set your limit switches at the negative ends of travel, and Grbl will be set the origin [0,0,0] upon homing completion."
Author

### jack-zande commented Jul 4, 2016

 Hello there again, I should try this recommended change in GRBL v0.9j and compile it and flash it to my Arduino UNO clone tomorrow. Uncommenting line in file config.h // #define HOMING_FORCE_SET_ORIGIN // Uncomment to enable. Should be easy to do. I let you, if the solution worked. Thanks in advance for the help. Greeting Jack Van: jahnj0584 notifications@github.com Verzonden: maandag 4 juli 2016 14:34:01 Aan: winder/Universal-G-Code-Sender CC: jack-zande; Author Onderwerp: Re: [winder/Universal-G-Code-Sender] Homing XYZ with \$H gives negative max travel XY in machine position https://github.com/grbl/grbl/wiki/Frequently-Asked-Questions#why-is-grbl-in-all-negative-coordinates-after-homing-or-it-so-annoying-and-not-what-im-used-to "For use cases outside of CNC mills or people annoyed about the machine being in negative space, there is a compile-time option that will force Grbl to set the origin to wherever the homing cycle ends. So, if you'd like a machine in all positive space, simply uncomment the HOMING_FORCE_ORIGIN option in the config.h file, set your limit switches at the negative ends of travel, and Grbl will be set the origin [0,0,0] upon homing completion." You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com//issues/435#issuecomment-230356406, or mute the threadhttps://github.com/notifications/unsubscribe/ALlSEsQYOrwiOjzfi3O8QX3USy2GKhpfks5qSXxJgaJpZM4JEjnL.
Owner

### winder commented Jul 4, 2016

 Thanks @jahnj0584

### chamnit commented Jul 5, 2016

 @jahnj0584 : I updated the Grbl FAQ about this question so that it's a lot more clear why Grbl sets the machine space in negative space and why it doesn't matter. For clarity, I'm pasting the FAQ answer below. When homing is enabled, Grbl sets all of the machine space in negative space. This may seem unusual to people who own 3D printers or newbies, but this is how it has been historically in CNC mills (and due to a misunderstanding how to use work coordinate systems and tool offsets. See below.) 3D printers have a single coordinate system, which is in all positive space. They can do this because it is additive manufacturing, rather than subtractive manufacturing. A 3D printer extruder has a fixed length and nozzle position, and the homing cycle can always reference the tip of the nozzle consistently. Thus, the print job can always start at the print bed from zero to positive-Z on the way up, and it's trivial to set X and Y to positive as well such that all axes are in positive space. However, a CNC mill is the opposite. It starts a job from the top of a piece of stock and mills out material on downward, or Z-negative. If you try to setup a mill in all positive space, like a 3D printer, it doesn't work, because you can no longer reference from the tool tip. The main problem is a mill accepts different tools with different lengths and can be chucked inconsistently along their lengths. Every time a tool is changed and touched off to the bed, the machine coordinate frame will change and not stay consistent to the actual machine travel. This is not ok, especially if you need to re-chuck a tool or change a tool for the next operation, because you have then lost your reference system. The only natural and consistent place to set a Z-axis reference point on a CNC mill is to place it at the top of Z-travel, such that Z is all negative and the tool tip is always relative to travel (using G43.1 tool offsets). If Z is always negative on a CNC mill due to referencing the Z-travel, rather than the tool tip, it's thought that the XY-axes should also be set in negative space. Either as a way to quickly show the operator which coordinate frame they are looking at, to have CNC machines with XY-tables toward the operator for quick setup, or to have gantry-style CNCs move the tool move away from the operator. The truth is no one really knows why machine space is all negative, rather than a mix of Z-negative and XY-positive. Even my two machinists friends, who have a combined 70 years of experience and have been around since the days of running the very first CNC machines with punch cards or tape reels, don't know why. Just keep in mind that Z-travel will almost always be Z-negative unless you happen to own a tool changer with pre-set tools, each with known offsets from machine travel (most don't because these are very expensive, precision add-ons). Regardless, how the machine coordinate system is setup (all positive, all negative, or a mix) is meaningless, because CNC mills (and other traditional CNCs) operate primarily in work coordinates systems, where work coordinate systems are simply programmable offsets of the reference machine coordinate system. Unless explicitly told to do so, all motion is performed in the active work coordinate system (Grbl has six G54-G59 and defaults to G54). They are incredibly useful, because their origins can be placed anywhere in the machine and used in many different ways (using the G10L2 and G10L20 commands). For example, since CAM programs generate g-code in terms of a part zero, typically at the top of a piece of stock to be milled, work coordinate systems can easily replicate a job in different areas of the machine with no additional CAM by simple altering the work coordinate offsets between each job. Because of all this, the machine coordinate system is there only to serve as a consistent and accurate machine position to ensure you are within the valid machine space (soft-limits). For use cases outside of CNC mills or people annoyed about the machine being in negative space, there is a compile-time option that will force Grbl to set the origin to wherever the homing cycle ends. So, if you'd like a machine in all positive space, simply uncomment the HOMING_FORCE_ORIGIN option in the config.h file, set your limit switches at the negative ends of travel, and Grbl will be set the origin [0,0,0] upon homing completion. However, keep in mind that if you have a mill, it's highly recommended that you reference the top of Z-travel, not the tool tip, for the reasons above. And remember that you can just as easily set your work coordinate system to operate in all positive space with the G10L2 and G10L20 commands!
Author

### jack-zande commented Jul 5, 2016

 Hello all, Today I have flashed the new changed config.h file of GRBL V0.9j to the Arduino UNO. // #define HOMING_FORCE_SET_ORIGIN // Uncomment to enable. Thanks all for your quick response. It works fine now. Greetings Jack Van: Sonny Jeon notifications@github.com Verzonden: dinsdag 5 juli 2016 08:13:34 Aan: winder/Universal-G-Code-Sender CC: jack-zande; Author Onderwerp: Re: [winder/Universal-G-Code-Sender] Homing XYZ with \$H gives negative max travel XY in machine position @jahnj0584https://github.com/jahnj0584 : I updated the Grbl FAQ about this question so that it's a lot more clear why Grbl sets the machine space in negative space and why it doesn't matter. For clarity, I'm pasting the FAQ answer below. When homing is enabled, Grbl sets all of the machine space in negative space. This may seem unusual to people who own 3D printers or newbies, but this is how it has been historically in CNC mills (and due to a misunderstanding how to use work coordinate systems and tool offsets. See below.) 3D printers have a single coordinate system, which is in all positive space. They can do this because it is additive manufacturing, rather than subtractive manufacturing. A 3D printer extruder has a fixed length and nozzle position, and the homing cycle can always reference the tip of the nozzle consistently. Thus, the print job can always start at the print bed from zero to positive-Z on the way up, and it's trivial to set X and Y to positive as well such that all axes are in positive space. However, a CNC mill is the opposite. It starts a job from the top of a piece of stock and mills out material on downward, or Z-negative. If you try to setup a mill in all positive space, like a 3D printer, it doesn't work, because you can no longer reference from the tool tip. The main problem is a mill accepts different tools with different lengths and can be chucked inconsistently along their lengths. Every time a tool is changed and touched off to the bed, the machine coordinate frame will change and not stay consistent to the actual machine travel. This is not ok, especially if you need to re-chuck a tool or change a tool for the next operation, because you have then lost your reference system. The only natural and consistent place to set a Z-axis reference point on a CNC mill is to place it at the top of Z-travel, such that Z is all negative and the tool tip is always relative to travel (using G43.1 tool offsets). If Z is always negative on a CNC mill due to referencing the Z-travel, rather than the tool tip, it's thought that the XY-axes should also be set in negative space. Either as a way to quickly show the operator which coordinate frame they are looking at, to have CNC machines with XY-tables toward the operator for quick setup, or to have gantry-style CNCs move the tool move away from the operator. The truth is no one really knows why machine space is all negative, rather than a mix of Z-negative and XY-positive. Even my two machinists friends, who have a combined 70 years of experience and have been around since the days of running the very first CNC machines with punch cards or tape reels, don't know why. Just keep in mind that Z-travel will almost always be Z-negative unless you happen to own a tool changer with pre-set tools, each with known offsets from machine travel (most don't because these are very expensive, precision add-ons). Regardless, how the machine coordinate system is setup (all positive, all negative, or a mix) is meaningless, because CNC mills (and other traditional CNCs) operate primarily in work coordinates systems, where work coordinate systems are simply programmable offsets of the reference machine coordinate system. Unless explicitly told to do so, all motion is performed in the active work coordinate system (Grbl has six G54-G59 and defaults to G54). They are incredibly useful, because their origins can be placed anywhere in the machine and used in many different ways (using the G10L2 and G10L20 commands). For example, since CAM programs generate g-code in terms of a part zero, typically at the top of a piece of stock to be milled, work coordinate systems can easily replicate a job in different areas of the machine with no additional CAM by simple altering the work coordinate offsets between each job. Because of all this, the machine coordinate system is there only to serve as a consistent and accurate machine position to ensure you are within the valid machine space (soft-limits). For use cases outside of CNC mills or people annoyed about the machine being in negative space, there is a compile-time option that will force Grbl to set the origin to wherever the homing cycle ends. So, if you'd like a machine in all positive space, simply uncomment the HOMING_FORCE_ORIGIN option in the config.h file, set your limit switches at the negative ends of travel, and Grbl will be set the origin [0,0,0] upon homing completion. However, keep in mind that if you have a mill, it's highly recommended that you reference the top of Z-travel, not the tool tip, for the reasons above. And remember that you can just as easily set your work coordinate system to operate in all positive space with the G10L2 and G10L20 commands! You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com//issues/435#issuecomment-230508222, or mute the threadhttps://github.com/notifications/unsubscribe/ALlSEpJlxpexETw6jMj8YcT4_aCgaoUuks5qSnSegaJpZM4JEjnL.