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>
There is no reason to use a higher internal PLL frequency. This
change also makes it possible to enable higher clock frequencies on
the stm32h723.
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
