I configured some parameters that seemed large, which caused an unreasonable start_v and cruise_v to be computed in the flush of the LookAheadQueue function, leading to the possibility of a less than 0 distance and time being computed in the set_junction function
So I added a limit to the peak_cruise_v2 variable, which when added solves the problem
Limit by s=(vtvt - v0vt)/(2*a) equation
test.txt (2.3 KB)
This is my first bug report, so I apologize for any omissions.
Thanks for the report. Unfortunately, it is not clear from the report what this possible bug is or how it manifests.
Please add a clear and concise description of how to reproduce the issue, along with a klippy.log file that demonstrates it (based on the original Klipper sources without any additional modifications).
I also discovered this bug by chance. In fact, I borrowed this part of the code in my work and found this issue in my testing, so I cannot provide a log.
However, I can explain the issue with this bug: when a motion only has acceleration,no cruise no decel, we have a normal initial velocity start_v, but peak_cruise_v2 is not properly restricted, resulting in excessive cruise_v, which in turn causes the distance of the acceleration phase to exceed the target distance, resulting in cruise_d and cruise_t being less than 0
The solution I proposed is also to limit peak_cruise based on the current motion distance of the move, and then limit cruise_v
I can provide my stepper motor parameters（This not be a common configuration）:
[stepper_x]
step_pin: PE6
dir_pin: PE5
enable_pin: ! PC14
microsteps: 32
rotation_distance: 1000
endstop_pin: ^PF4
position_endstop: 0
position_max: 235000
homing_speed: 500
In my project, I use the same （Move → LookAheadQueue.flush → Toolhead._process_moves ）logic as in klipper, and I added a line of LOG before trapq_append
if(move->_is_kinematic_move) {
trapq_append(
_trapq.get(),
next_move_time,
move->_accel_t, move->_cruise_t, move->_decel_t,
move->_start_position.x, move->_start_position.y, move->_start_position.z,
move->_axes_r.x, move->_axes_r.y, move->_axes_r.z,
move->_start_v, move->_cruise_v, move->_accel
);
LOG_DEBUG("move start time %lf max_start_V2(%lf) max_smoothed_V2(%lf) start_pos(%lf %lf %lf) end_pos(%lf %lf %lf) startV(%lf)accelT(%lf)accelD(%lf) cruiseV(%lf)cruiseT(%lf)cruiseD(%lf) decelV(%lf)decelT(%lf)decelD(%lf)", next_move_time , move->_max_start_v2 , move->_max_smoothed_v2 , move->_start_position.x , move->_start_position.y , move->_start_position.z , move->_end_position.x , move->_end_position.y , move->_end_position.z , move->_start_v , move->_accel_t , move->_accel_d , move->_cruise_v , move->_cruise_t , move->_cruise_d , move->_end_v , move->_decel_t , move->_decel_d);
}
In a piece of random motion testing, I get the following logs
[DEBUG] move start time 272.140100 max_start_V2(25000000.000000) max_smoothed_V2(25000000.000000) start_pos(7647.000000 8538.000000 6159.000000) end_pos(5151.000000 2535.000000 2134.000000) startV(5000.000000)accelT(0.000000)accelD(0.000000) cruiseV(5000.000000)cruiseT(1.263923)cruiseD(6319.615183) decelV(3425.297623)decelT(0.314940)decelD(1326.733619)
[DEBUG] move start time 273.718964 max_start_V2(11732663.806655) max_smoothed_V2(5866331.903328) start_pos(5151.000000 2535.000000 2134.000000) end_pos(4339.000000 1692.000000 2215.000000) startV(3425.297623)accelT(0.299474)accelD(1250.000000) cruiseV(4922.668362)cruiseT(-0.015588)cruiseD(-76.733619) decelV(4922.668362)decelT(0.000000)decelD(0.000000)
move start time is the movement start time
max_start_V2 is the limit of Move’s maximum start speed.
max_smoothed_V2 is Move’s limited maximum smoothed velocity
start_pos is the 3D coordinates of the starting point of Move.
end_pos is the target 3D coordinate of the Move.
(startV, accelT, accelD) corresponds to the start velocity, acceleration time and distance of the acceleration phase.
(cruiseV, cruiseT, cruiseD) corresponds to the speed, time, and distance of the uniform motion phase.
(decelV, decelT, decelD) corresponds to the velocity, time and distance of the deceleration phase.
The logs from the above show that the cruise speed is overly greedy causing the distance of motion in the acceleration phase to exceed the distance of motion of the target, which in turn generates the wrong cruise_t and cruise_d
You still did not attach a klippy.log. Please do so to your next post.
This bug was found in my own project, so I have no way to provide klippy.log !!!
Since I use the same logic as klipper in my project, I think there is a risk that this could happen in klipper, too.
If you are interested in this, you can think about the logic to see if this could be a problem.
When you work on something that is not Klipper, why posting here?
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.