pop

refresh

refresh (create temporary patch)

goto

pop

goto

sink

pop

goto

pop

refresh

refresh (create temporary patch)

goto

pop

hide

pop

refresh

refresh (create temporary patch)

pop

pop

pop

pop

pop

pop

pop

pop

pop

refresh

refresh (create temporary patch)

pop

external modifications

Modifications by tools other than StGit (e.g. git).

pop

goto

repair

pop

pop

pop

refresh

refresh (create temporary patch)

refresh

refresh (create temporary patch)

pop (CONFLICT)

pop

pop

pop

refresh

refresh (create temporary patch)

pop

pop

refresh

refresh (create temporary patch)

new

pop

refresh

refresh (create temporary patch)

pop

pop

pop

pop

pop

refresh

refresh (create temporary patch)

refresh

refresh (create temporary patch)

refresh

refresh (create temporary patch)

refresh

refresh (create temporary patch)

pop

repair

pop

pop

pop

pop

M206: always use homing ("homeing") offsets

Previously the parameters set in M206 would only be used if a G82
command was sent with specific axis home values.  This limits its
usefulness.

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the first stage of this, make M206 affect every
home command.  The values set using M206 are now added to the
configuration variables [XYZ]_HOME_POS.

This is achieved by replacing all uses of [XYZ]_HOME_POS in the code
by [XYZ]_HOME_POS_A which is a macro which includes the adjustment.

A question arises: if the M206 offset is set, should this adjustment
to the home position shift or change the possible range of movement
permitted by the software endstops ?

I have taken the view that the software endstops are a backstop safety
feature which is not necessarily entirely accurate, and that reducing
the scope of movement is not desirable.

I have therefore implemented it so that negative values for M206
increase the total range of movement, whereas positive values leave it
unchanged.

So for example with
  #define X_MIN_POS 0
  #define X_HOME_POS 0
  #define X_MAX_POS 100

M206 X-10 would permit the machine to move from the endstop
(considered X=-10) 110mm in the positive X direction (considered
X=+100).

M206 X+10 would permit the machine to move from the endstop
(considered X=-10) 100mm in the positive X direction (considered
X=+110).

fixes #200 (in ErikZalm/Marlin).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

refresh

refresh

refresh (create temporary patch)

refresh (create temporary patch)

Refresh of motion-control-max-min

pop

pop

pop (CONFLICT)

pop (CONFLICT)

pop

pop

M206: always use homing ("homeing") offsets

Previously the parameters set in M206 would only be used if a G82
command was sent with specific axis home values.  This limits its
usefulness.

Really, we should have a way to adjust the XYZ homing of a machine in
the eeprom.  So as the first stage of this, make M206 affect every
home command.  The values set using M206 are now added to the
configuration variables [XYZ]_HOME_POS.

This is achieved by replacing all uses of [XYZ]_HOME_POS in the code
by [XYZ]_HOME_POS_A which is a macro which includes the adjustment.

A question arises: if the M206 offset is set, should this adjustment
to the home position shift or change the possible range of movement
permitted by the software endstops ?

I have taken the view that the software endstops are a backstop safety
feature which is not necessarily entirely accurate, and that reducing
the scope of movement is not desirable.

I have therefore implemented it so that negative values for M206
increase the total range of movement, whereas positive values leave it
unchanged.

So for example with
  #define X_MIN_POS 0
  #define X_HOME_POS 0
  #define X_MAX_POS 100

M206 X-10 would permit the machine to move from the endstop
(considered X=-10) 110mm in the positive X direction (considered
X=+100).

M206 X+10 would permit the machine to move from the endstop
(considered X=-10) 100mm in the positive X direction (considered
X=+110).

fixes #200 (in ErikZalm/Marlin).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

refresh

refresh

refresh (create temporary patch)

refresh (create temporary patch)

Refresh of motion-control-max-min

software_endstops: use *_MIN_POS and *_MAX_POS for arcs

If [XYZ]_HOME_POS and [XYZ]_MIN_POS aren't 0, these corrections are
wrong.  Use the same logic as in Marlin.pde:prepare_move: ie, clamp to
[XYZ]_{MIN,MAX}_POS.

While we're here, put this cut-and-paste code in a function
clamp_to_software_endstops.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

software endstops: use *_MIN_POS and *_MAX_POS for arcs

If [XYZ]_HOME_POS and [XYZ]_MIN_POS aren't 0, these corrections are
wrong.  Use the same logic as in Marlin.pde:prepare_move: ie, clamp to
[XYZ]_{MIN,MAX}_POS.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

new

new

software endstops: use *_MIN_POS and *_MAX_POS for arcs

If [XYZ]_HOME_POS and [XYZ]_MIN_POS aren't 0, these corrections are
wrong.  Use the same logic as in Marlin.pde:prepare_move: ie, clamp to
[XYZ]_{MIN,MAX}_POS.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

pop

pop

refresh