Added a paragraph about flash loop protection on some motherboards. It has been noted that not all people know about the need to change the bin filename on some stock boards or other methods that may hinder progress.
Signed-off-by: James Hartley <james@hartleyns.com>
The docs aren't particularly clear that if you generate a mesh in our start g-code, you can just use it without additional commands. This is causing issues with support on r/klippers
Signed-off-by: Rowland Straylight <rowlandstraylight@gmail.com>
Add a new G-Code command that can register a manual_stepper as an
additional axis on standard G-Code G1 commands.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Add a new add_extra_axes() to support adding additional axes. Once
called, toolhead.get_position() will return a list object with more
than 4 items, and toolhead.move() requires the same size list.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
It's not valid to alter the extruder position from a call to
set_position(), so don't allow callers to attempt that.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Make it more clear that stepper_load_next() has three separate code
paths - one for each of the optimized stepper_event_X() functions.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
In practice the host will not schedule any steps immediately after a
direction change (due to acceleration limits and the host
"step+dir+step filter"). However, there is also no harm in enforcing
a minimum duration in the mcu.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Commit 8faed8d9 made it possible to utilize stepper_event_full() while
utilizing tmc "step on both edges" optimation. That commit would
ensure a minimum step pulse duration, but it did not ensure a minimum
duration between step pin and dir pin changes. Commits 0d27195f and
554ae78d optimized the gpio handling on stm32h7 chips, which could
potentially cause a very small amount of time between step pin and dir
pin changes.
Enforce a minimum time after a step pin update before updating the dir
pin.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Move up the freeing of the stepper_move struct and setting of
s->position in stepper_load_next(). This simplifies the code and
will make it easier to add more logic to this function.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
As per #6923 this PR adds the fact that this config works for the late revision CR-ERA_V1.1.0.3 board as well.
Signed-off-by: James Hartley <james@hartleyns.com>
It has been noted that there are 3 possible boards with 2 possible configs, which we have both of, but this one does not state that it is for the 4.5.2 early kickstarter version. Which was causing some confusion.
Signed-off-by: James Hartley <james@hartleyns.com>
* tests: Added a regression test for generic_cartesian kinematics
* kinematics: An intial implementation of generic_cartesian kinematics
* generic_cartesian: Refactored kinematics configuration API
* generic_cartesian: Use stepper instead of kinematic_stepper in configs
* generic_cartesian: Added SET_STEPPER_KINEMATICS command
* generic_cartesian: Fixed parsing of section names
* docs: Generic Caretsian kinematics documentation and config samples
* generic_cartesian: Implemented multi-mcu homing validation
* generic_cartesian: Fixed typos in docs, minor fixes
* generic_cartesian: Renamed `kinematics` option to `carriages`
* generic_cartesian: Moved kinematic_stepper.py file
* idex_modes: Internal refactoring of handling dual carriages
* stepper: Refactored the code to not store a reference to config object
* config: Updated example-generic-cartesian config
* generic_cartesian: Restricted SET_STEPPER_CARRIAGES and exported status
* idex_modes: Fixed handling stepper kinematics with input shaper enabled
* config: Updated configs and tests for SET_DUAL_CARRIAGE new params
* generic_cartesian: Avoid inheritance in the added classes
Signed-off-by: Dmitry Butyugin <dmbutyugin@google.com>
Increase the internal nominal clock from 8Mhz to 12Mhz - this improves
support for higher chip frequencies.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
The rp2040 operates at a fast internal clock with a relatively slow
external timer and dividing down could result in a too small delay.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
