tcm0116
commented
6 years ago I just ran a test with some added debugging information added to FWRetract::retract() to display the X and Y stepper positions at the beginning and end of the function. As the X and Y positions aren't being modified by FWRetract::retract(), the stepper positions should be the same at the end of the function as they were at the beginning of the function. However, the log file snippet below shows a different story.
Recv: stepper.position[x] 9513
Recv: stepper.position[y] 10447
Recv: stepper.position[x] 9158
Recv: stepper.position[y] 10152
Recv: delta stepper.position[x] -355
Recv: delta stepper.position[y] -295
[...]
Recv: stepper.position[x] 9342
Recv: stepper.position[y] 10447
Recv: stepper.position[x] 9250
Recv: stepper.position[y] 10447
Recv: delta stepper.position[x] -92
Recv: delta stepper.position[y] 0
[...]
Recv: stepper.position[x] 9456
Recv: stepper.position[y] 11207
Recv: stepper.position[x] 9464
Recv: stepper.position[y] 11152
Recv: delta stepper.position[x] 8
Recv: delta stepper.position[y] -55
[...]
Recv: stepper.position[x] 9307
Recv: stepper.position[y] 11169
Recv: stepper.position[x] 9278
Recv: stepper.position[y] 11152
Recv: delta stepper.position[x] -29
Recv: delta stepper.position[y] -17
[...]
Recv: stepper.position[x] 7413
Recv: stepper.position[y] 11169
Recv: stepper.position[x] 7384
Recv: stepper.position[y] 11152
Recv: delta stepper.position[x] -29
Recv: delta stepper.position[y] -17This seems to jive with my original hypothesis that the re-computation of the stepper positions in
Planner::_set_position_mm() is likely the cause of the issue I was seeing.
The simplest fix would be to replaced the call to SYNC_PLAN_POSITION_KINEMATIC() with calls to sync_plan_position_e() and a new function sync_plan_position_z(). However, this has several downsides. First, it won't work for kinematic machines. Ans second, it really just masks the issue with re-computing the positions in Planner::_set_position_mm(), as the same issue could be occurring with the Z and E axes.
I think the better solution would be to replace the current method of adjusting the planner position with an approach that provides an offset to the planner in a similar way to how bed leveling works. This would eliminate the possibility of the stepper positions being incorrectly offset by allowing the planner to be away of the retraction offsets and the actual physical position of the machine at all times.
brucehvn
thinkyhead
studiodyne
github-actions[bot]
Description
Using firmware retraction appears to cause missing steps. I made several attempts at a print that consisted of multiple cubes while using firmware retraction, but each attempt resulted in the cubes becoming skewed towards the origin of the bed on my printer. I finally got the print to succeed by having the slicer perform the retraction instead of using G10/G11.
Steps to Reproduce
Expected behavior: The cubes are not skewed,
Actual behavior: The cubes are skewed.
Additional Information
I'm fairly sure this is due to the call to
SYNC_PLAN_POSITION_KINEMATIC()inFWRetract::retract(). My thinking is that the re-computation ofPlanner::positioninPlanner::_set_position_mm()is causingcurrent_positionandPlanner::positionto become out of sync, possibly due to rounding errors. I haven't looked into this hypothesis in detail, but it seems like a likely place for steps to get dropped.