(PR #138)
When the ISR does not finish in time, the timer will
wrap in the computation of the next interrupt time.
This hack replaces the correct (past) time with a time not far in the future.
Currently we use the probe exclusively as a device to find the build platform(bed).
For the currently supported setups this means, we use it as a additional min-endstop.
A triggered when not deployed probe disturbs the homing process for max-endstops.
Rename ENDSTOPPULLUP_ZPROBE to ENDSTOPPULLUP_ZMIN_PROBE
Rename Z_PROBE_ENDSTOP_INVERTING to Z_MIN_PROBE_ENDSTOP_INVERTING
Rename Z_PROBE_ENDSTOP to Z_MIN_PROBE_ENDSTOP
Rename DISABLE_Z_PROBE_ENDSTOP to DISABLE_Z_MIN_PROBE_ENDSTOP
Rename Z_PROBE_REPEATABILITY_TEST to Z_MIN_PROBE_REPEATABILITY_TEST
Rename Z_PROBE_ENDSTOP to Z_MIN_PROBE_ENDSTOP
Adjust comments accordingly
Remove Z_MAX check for the probe in update_endstops().
Using an delta related idea of @clefranc from #61,
extended to the general change for all setups.
Tested with Prusa i3, max-z-endstop and permanently triggered z-probe.
Worked for @clefranc's delta.
to warrant watching is set or reset.
Make setTargetBed() in _lcd_preheat() dependant of TEMP_SENSOR_BED.
Use disable_all_heaters() in lcd_cooldown() and abort_on_endstop_hit.
I.e., when acceleration * steps per mm > 2,000,000.
This was done by changing MultiU24X24toH16 to take a 32b bit operand.
Removed the claim that stepper.cpp uses the Leib algorithm.
Updated documentation in Configuration.h.
Cleaned up and commented some code relating to Z_PROBE_ENDSTOP.
Separated Z_MIN_ENDSTOP and Z_PROBE_ENDSTOP completely.
Documented some additional areas that should be addressed if Z_PROBE is
fully separated from Z_MIN or Z_MAX.
Fixed a documentation error in sanity checks. Servos start at 0 not 1.
- Fix `prepare_move` function not calling `adjust_delta`
- Add more shorthand for plan_buffer_line.
- Fix wrong `federate` usage, assuming they are all mm/m
- Minor `stepper.cpp` cleanup
- Add some documentation to planner and stepper headers
- Patch up RAMBO pins with undefs
- Add `sync_plan_position` inline to set current XYZE
- Swap indices in `extruder_offset` to fix initialization values
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
When one hit "Stop Print" option in LCD menu, the command buffer was not
cleared. The printer keep moving until the buffer has been emptied.
Actually I could not clear the command buffer as well.. I don't know
why, it doesnt work as expected.
I need to implement a routine inside Stepper ISR to handle such
situation.
The Check Endstop logic must be:
if (current_block->steps_x != current_block->steps_y || (TEST(out_bits,
X_AXIS) == TEST(out_bits, Y_AXIS)))
if (TEST(out_bits, X_HEAD))
not
if (TEST(out_bits, X_HEAD) && (current_block->steps_x !=
current_block->steps_y || (TEST(out_bits, X_AXIS) == TEST(out_bits,
Y_AXIS))))
Same applies for Y axis.
- 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
- 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
Tosh stepper drivers need to be driven slower, so the stepper code
was interleaved to separate the pin HIGH from the pin LOW. This adds
enough instructions to make it work, without needing nops.
also, removed some trouble for compilation with corexy.
I think that babystepping is only possible in z for a delta tower.
not sure if it would be usefull to step individual motors on a delta, i don't own one
It is a realtime control over the head position via the LCD menu system that works _while_ printing.
Using it, one can e.g. tune the z-position in realtime, while printing the first layer.
Also, lost steps can be manually added/removed, but thats not the prime feature.
Stuff is placed into the Tune->Babystep *
It is not possible to have realtime control via gcode sending due to the buffering, so I did not include a gcode yet. However, it could be added, but it movements will not be realtime then.
Historically, a very similar thing was implemented for the "Kaamermaker" project, while Joris was babysitting his offspring, hence the name.
say goodby to fuddling around with the z-axis.
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.
Scott Lahteine