-
-
Notifications
You must be signed in to change notification settings - Fork 19.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce line_to_axis_pos() for use in homeaxis() #4342
Conversation
I've tested this PR just now, but this is danger than previous one... A branch that it's used for test: |
@esenapaj |
@esenapaj |
Context:
When I have the nozzle at Z5 ( When I have the nozzle at Z6.50 ( I would expect both of them to finish at Z5 and Z never being lift above 5 during the process. Issuing |
@jbrazio The complete G28 sequence for a !DELTA, homing to z-min, with a probe should be:
|
PS: I use an induction probe. |
Wasted a day by looking into My code. The endstops are not initialized as expected. #4306 is under suspicion. Workaround: I'm too tired now to find the problem. Up since 24 hours after 3h of sleep. More later. |
Thank you for your hard work. Case 1:
#define ENDSTOPS_ALWAYS_ON_DEFAULT is enabled |
Case5 and Case6 (same result):
#define ENDSTOPS_ALWAYS_ON_DEFAULT is enabled |
Case 7:
#define ENDSTOPS_ONLY_FOR_HOMING is enabled |
…ate = 0.0) and use it in `homeaxis()` instead of `do_blocking_move_to_axis_pos()`. `do_blocking_move_to_axis_pos` was wrong because it performed subdivided, delta-corrected moves for x- and y-axis. The first common move for delta homing is like quick_home but for 3 towers. Fix two warnings.
Sorry for the mess. Let's have a new try. The endstops have been under suspicion because without the synchronizes the G28-function is ready before the moves have finished. The endstops are switcht off again at the end of the function, but the moves in the planner buffer are still running. |
@@ -1613,9 +1613,20 @@ inline float set_homing_bump_feedrate(AxisEnum axis) { | |||
inline void line_to_current_position() { | |||
planner.buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], MMM_TO_MMS(feedrate_mm_m), active_extruder); | |||
} | |||
|
|||
inline void line_to_z(float zPosition) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that line_to_z(z)
does not update current_position[Z_AXIS]
. It's called only in run_z_probe
for the probing moves (where it doesn't need to update current_position
). The current_position
is set from stepper.get_axis_position_mm(Z_AXIS)
at the end.
Please let this fix many issues. |
About G28 of DELTA, I've confirmed that problem is solved by this PR. |
For f*** sake. We need some way to have Marlin run in "simulation mode" where instead of controlling the hardware it just outputs what it would do. Then people without deltas will be able to test their changes instead of submitting code full of naive assumptions. |
@daid's software simulator required the firmware to be built in a certain way in order to work.. what we would really need is mod it to allow .hex loading.. anyone with the skillz for the job ? |
I'm thinking of something more along the lines of a simulation mode configuration option. All the low-level functions to control the hardware would be supplanted by functions that merely simulate everything. And then in this mode we would have a "monitor" that runs from #4364 is the general idea. |
But that we can accomplish with a RAMPS board without anything connected to it, set -keep dreaming João- |
If you can get MarlinSimulator to build on macOS (née OS X, née Mac OS X) you will be my hero. |
…_class optimisation: Timer constructor can be `constexpr`
Introduce line_to_axis_pos(axis_codes axis, float where, float feed_rate = 0.0)
and use it in homeaxis instead of
do_blocking_move_to_axis_pos()
.do_blocking_move_to_axis_pos
was wrong because it performs subdivided, delta-corrected moves for x- and y-axis.Hopefully a fix for #4338 (comment)
@esenapaj Would you pleas be so kind to test?