Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
jack-zande opened this Issue Jul 4, 2016 · 7 comments

Comments

Projects
None yet
4 participants
@jack-zande
Copy link

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

This comment has been minimized.

Copy link

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
.

@jack-zande

This comment has been minimized.

Copy link
Author

jack-zande commented Jul 4, 2016

Hello there,

I am new about GRBL v0.9j. If I am not wrong you mean to change the code in GBRL v0.9j.

I have found to files LIMITS.C and LIMIT.H, which also handles the homing cycle position.

I am not sure what to change about this. See the attachment.

Greeting Jack


Van: jahnj0584 notifications@github.com
Verzonden: maandag 4 juli 2016 12:25:48
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

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
.

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/435#issuecomment-230344824, or mute the threadhttps://github.com/notifications/unsubscribe/ALlSEkqudXGP_ENdHQqc2gmjYqkKnnOAks5qSV48gaJpZM4JEjnL.

// The active cycle axes should now be homed and machine limits have been located. By
// default, Grbl defines machine space as all negative, as do most CNCs. Since limit switches
// can be on either side of an axes, check and set axes machine zero appropriately. Also,
// set up pull-off maneuver from axes limit switches that have been homed. This provides
// some initial clearance off the switches and should also help prevent them from falsely
// triggering when hard limits are enabled or when more than one axes shares a limit pin.
#ifdef COREXY
int32_t off_axis_position = 0;
#endif
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==X_AXIS) { 
      off_axis_position = (sys.position[B_MOTOR] - sys.position[A_MOTOR])/2;
      sys.position[A_MOTOR] = set_axis_position - off_axis_position;
      sys.position[B_MOTOR] = set_axis_position + off_axis_position;          
    } else if (idx==Y_AXIS) {
      off_axis_position = (sys.position[A_MOTOR] + sys.position[B_MOTOR])/2;
      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;
  #endif

}

}

@jahnj0584

This comment has been minimized.

Copy link

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."

@jack-zande

This comment has been minimized.

Copy link
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.

@winder

This comment has been minimized.

Copy link
Owner

winder commented Jul 4, 2016

Thanks @jahnj0584

@winder winder closed this Jul 4, 2016

@chamnit

This comment has been minimized.

Copy link

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!

@jack-zande

This comment has been minimized.

Copy link
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.