Make the output of M105 more similar to Repetier.
Make the text-print pert of M105 an extra function to make it reusable. `print_heaterstates()`
Use `print_heaterstates()` in M019, M190 and M303
- For better encapsulation add inlines for each prepare_move type
- Move controllerFan vars inside the function as statics
- Some formatting cleanup
- Rename `ClearToSend` as `ok_to_send`
- Add `M111` as a standard option to set the debug level
- Implement `DEBUG_ECHO` in `process_commands`
- Other debug levels (e.g., `DEBUG_DRYRUN`) need more work
- Include the current Z when raising the axis after and between probing
- Add `sync_plan_position_delta` for parity with `sync_plan_position`
- Clean up and clarify `M48`, `dock_sled`, and others
Z_DUAL_ENDSTOPS is a feature to enable the use of 2 endstops for both Z
steppers - Let's call them Z stepper and Z2 stepper.
That way the machine is capable to align the bed during home, since both
Z steppers are homed.
There is also an implementation of M666 (software endstops adjustment)
to this feature.
After Z homing, this adjustment is applied to just one of the steppers
in order to align the bed.
One just need to home the Z axis and measure the distance difference
between both Z axis and apply the math: Z adjust = Z - Z2.
If the Z stepper axis is closer to the bed, the measure Z > Z2 (yes, it
is.. think about it) and the Z adjust would be positive.
Play a little bit with small adjustments (0.5mm) and check the
behaviour.
The M119 (endstops report) will start reporting the Z2 Endstop as well.
- Use named axis indexes, `X_AXIS` etc.
- Replace `block.steps_A` with block.steps[A]`
- Replace `A_segment_time` with `segment_time[A]`
- Add `A_AXIS`, `B_AXIS` for `COREXY` axes
- Conditional compile based on `EXTRUDERS`
- Add BLOCK_MOD macro for planner block indexes
- Apply coding standards to `planner.h` and `planner.cpp`
- Small optimizations of planner code
- Update `stepper.cpp` for new `block` struct
- Replace `memcpy` with loops, let the compiler unroll them
- Make `movesplanned` into an inline function
- Add BIT and TEST macros
- Add _APPLY_ macros to stepper.cpp to help with consolidation
- Consolidate code in stepper.cpp using macros
- Apply standards in stepper.cpp
- Use >= 0 instead of > -1 as a better semantic
- Replace DUAL_Y_CARRIAGE with Y_DUAL_STEPPER_DRIVERS
With this change a mechanical or optical switch may be used to check the
availability of the filament and when the filament runs out an M600
(filament change) command is issued. This is only done while printing
with an SD card.
This feature was requested several times (issue #679), but the requests
were not accepted since it was believed that this situation should be
handled at host side. However during an SD print the control is totally
on firmware and I think that during an SD print it should be handled by
the firmware.
The original code was posted at reprap forum
(http://forums.reprap.org/read.php?1,297350) by Lazymonk. I have only
corrected some bugs of the code and improved it by adding definitions to
the configuration.h in order to make it more standardized.
- Nonlinear auto bed leveling code (includes G29, G30, Z_RAISE_AFTER_PROBING). Cleaned it up to be a delta-specific AUTO_BED_LEVELING_GRID code path.
- Allen key z-probe deployment and retraction code. Cleaned it up and added safety checks.
- Moved sanity-checks to Marlin_main.cpp
- Applied to other configuration files
- Fixed formatting of ABL output
- Passing verbose level to probe_pt
- Miscellaneous cleanup
- Put CONFIG_STEPPERS_TOSHIBA into Configuration.h
For cartesian bots, the X_AXIS is the real X movement and same for
Y_AXIS.
But for corexy bots, that is not true. The "X_AXIS" and "Y_AXIS" motors
(that should be named to A_AXIS
and B_AXIS) cannot be used for X and Y length, because A=X+Y and B=X-Y.
So we need to create other 2 "AXIS", named X_HEAD and Y_HEAD, meaning
the real displacement of the Head.
Having the real displacement of the head, we can calculate the total
movement length and apply the desired speed.
Improvement to avoid reinitializing delay buffer with every print. Fixed
issues in buffer indexing and memory out of bounds due to floating point
imprecision. Simplified the code by avoiding conversion to standard
diameter and 1cu mm extrusion, which caused complications in determining
mm extruded.
This feature allows the printer to read the filament diameter
automatically and adjust the printer in real time. Added code to read
an analog voltage that represents a filament diameter measurement. This
measurement is delayed in a ring buffer to compensate for sensors that
are a distance away from the extruder. The measurement is used to
adjust the volumetric_multiplier for the extruder. Some additional g
codes (M404, M405, M406, M407) are used to set parameters and turn
on/off the control. g code M221 is updated. Pins for RAMPS1.4, RAMBO,
and Printrboard are identified for analog input. The configuration file
is updated with relevant user parameters.
FW retraction is extended onto swap retraction invoked by 'G10 S1'.
Bookkeeping of the retract state of all extruders allows for having one
extruder fw standard retracted while another extruder is swap retracted.
An LCD menu item for the swap retract and recover length was added.
Add digipot i2c control for MCP4451
Allow M907 to set i2c digipot currents in amps
Fix Makefile to allow Azteeg motherboards
Fix Makefile to allow Wire libraries only
Add beeper pin for Azteeg X3 Pro
Recommended for those who are using the Z Probe for Z Homing (as
Z-Endstop)
This feature has two changes:
1) Allow user to choose where the Z Probe will touch the bed when homing
all axis together (G28) by setting below defines:
Z_SAFE_HOMING_X_POINT
Z_SAFE_HOMING_Y_POINT
2) Prevents the user to perform Z Axis Homing when the Z Probe is
outsite bed.
Enables two stepper drivers to be used for the Y axis (useful for
Shapeoko style machines)
Each Y driver can be stepped in either the same way or in opposite
directions, accounting for different hardware setups (leadscrew vs. belt
driven)
Enables two stepper drivers to be used for the Y axis (useful for
Shapeoko style machines)
Each Y driver can be stepped either the same way or in opposite
directions, accounting for different hardware setups (leadscrew vs. belt
driven)
Reviert previous change of #if BLAH_PIN > 0 to #if defined(BLAH_PIN) &&
BLAH_PIN > -1. Unfortunately some times pin 0 is used. For my sins I've
gone through and replaced all unsafe checks of #if BLAH_PIN > -1 with
the safe version.
SERIAL_ECHOPAIR implies, eventually, two calls to MYSERIAL.print. One
of these has FORCE_INLINE for a per-character loop, and both involve
constructing a method call rather than a simple function call.
Produce better and smaller code by providing three specialised
functions serial_echopair. This saves 672 bytes of program memory
(with EEPROM_SETTINGS and SDSUPPORT enabled).
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
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 a new home_pos[] which includes the adjustment. We also have to
adjust the uses of [XYZ]_{MIN,MAX}_POS similarly - see below.
To allow axis_is_at_home to be written as a function taking an axis
index rather than a macro taking an axis letter, we provide
constant arrays in program memory containing the values of
[XYZ]_{MIN,MAX,HOME}_POS from the compiled-in configuration.
This is done with some helper macros to deal with the declaration
(XYZ_CONSTS_FROM_CONFIG) and definition of the inline function which
does the program memory access.
We also introduce the overloaded function read_pgm_any, whose
instances are produced with DEFINE_PGM_READ_ANY, which allows the
access functions to automatically produce the correct type.
The type- and pointer-massaging code in the access function boils
down, when compiled, to a simple program memory access.
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 ?
The documentation in Configuration.h describes these limits as:
// Travel limits after homing
Since this is a file containing physical limits, and actual suggested
values for these configuration parameters appear to include a certain
amount of slop, I've taken the view that these should be regarded as
nominal physical distances from the limit switches, and that the
permissible travel should be unaffected by M206.
So for example with the (rather unrealistic)
#define X_HOME_DIR -1
#define X_MIN_POS -20
#define X_HOME_POS 0
#define X_MAX_POS 100
no matter the setting of M206 X, the machine would be permitted
to move from 20mm "beyond" the limit switch trigger point in
the negative X direction and 100mm away from the limit switch in
the positive X direction, for a total travel of 120mm.
With M206 X-10 that would be considered to correspond to X coordinates
-30 to +90. With M206 X+10 that would be considered to correspond to
X coordinates -10 to +110.
fixes#200 (in ErikZalm/Marlin).
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
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>
