@masterq Any idea how much of a performance hit (if any) we’re taking by incorporating this as macros rather than being included in the code itself?
I have no measurements about this, but at the pi 4 I can not see any difference on the CPU load. I think these Macros are pretty slow, but it don’t care, because if the maximum iterations are about 50 per second and this should take about no CPU time
But for being sure it needs to be proofed with measurements
I’m very sorry I have no environment for testing with dual extruder, so I can not support dual extruder
This zhop code was working well for me, but I’ve run into some problems with some prints recently. When printing a simple cylinder, The initial layer top/bottom segment progressively overshoots past the wall line as it performs those tiny retraction sequences at the end of top/bottom lines. The error seems to accumulate with each top/bottom line with a retraction at the end.
I’m not sure if it might be a bed_mesh related issue or some strange math issue with a very short travel distance. Any idea what could be going on?
Hello thank you a lot for testing and reporting,
I’m not fully sure that I completely understood the problem. Can you maybe provide more support Material for the issue? (Video, gcode, diagram or symbolic picture)
Can you make one more experiment to ensure that you are not are losing silently steps somewhere?
- lower z-acceleration by factor 10
- lower z-velocity by factor 4
- retry the print
- post the results
As soon I find some spare time and I understood the issue completely, I will use time on finding a bugfix.
I did print many cylinders with different size and I could not reproduce the issue. G2 and G3 enabled ([gcode_arcs] defined).
So it looks like this:
You can see it prints the perimeter fine but goes way off the side as it fills it in. It also starts berrying it into my print bed so I have to cancel it. It’s off on at least two axes.
I use a delta printer, so I run with an insane zhop speed (250mm/s) because it’s not a problem for deltas. Works fine with cura’s shop. Unfortunely I don’t want to take on another source of uncertainty, so I probably won’t try to mess with settings for now. Mine were:
Here is the initial layer gcode in case it’s of interest as well.
print_layer_0.gcode (51.6 KB)
Thanks for providing all that information!
Ofc I understand that delta printer are a special case. Maybe the ZHop height of 2 mm is the key information that makes the issue visible. I use something like 0.2 mm. I will try this height and check if I can reproduce the problem. What I really wonder about is that you had no issues with other prints. As you are not using ARC function, so it should be the same thing.
It is still possible that issue is caused by lost steps, which only occurs on special positions or direction changes. These kinds of issues are no myth, and they really appears, and I could observe them often specially on systems with lead screws (Vibrations, dirt or irregularities on the screws can cause this). I think the suggested test could be really worth it for you and your printer
I have not worked with delta Printers, possibly somebody else can tell us if lost steps on one lead screw would result in issues like shown on your picture.
I think it’s possible if one of your lead screws are located in round about the direction showed by the arrow. If the lead screw is less retracted than it should (lost steps), it would print into the bed a bit longer on the upper side and a bit more on the left side (what is round about what I interpret from the picture).
In every case I will try 2 mm Z-Hop and report back and many thanks for providing the data.
Please report back if you find more information!
Have a nice day, with nice prints
One thing to note when reproducing is I’m using a 0.8mm nozzle, for which with typical slice settings you tend to get retraction sequences at the end of top/bottom lines.
Interesting theory about the lost steps, I will have to check this. It’s true that that arrow does point directly to one of the towers. I’ll have to test with slower zhops. It’s odd though that I know the same zhop settings enabled in Cura works just fine for the same model. Could your implementation be disobeying the configured kinematic acceleration limits?
There is no easy way to violate the machine settings regarding acceleration additional the acceleration settings are completely untouched by this feature. So it is very unlikely, as if the acceleration limits are disrespected, the root cause should be in the Klipper kinematics. Can you maybe also post the first layer of the gcode with slicer retractions, it could be interesting to see if they are handled in another way?
Maybe there is a more easy way to check this out (while printing). Set 3 Settings to a very low value:
- accel to decel
- z-hop speed
The web interface allows to easily adjust the settings of acceleration while printing. I would start with a very low value on the start and increment it later. Possibly also accel to decel values are important.
I did check a lot now, I did not find any potential problem what could cause this issue. That on the software/firmware side many things are checked, makes the lost steps to the most likely explanation. For continuing my research I need your confirmation, that no steps are lost.
Thanks a lot for supporting the development!
Best Regards and happy printing
Thanks for your help! I’m thinking this must be a printer issue because I’ve now run into what I believe is the same root-cause issue with cura zhops. I’m thinking my belts are getting a bit loose and/or dirty and occasionally a tooth is slipping with the the sudden up-down motion. A nema 17 missing a step should be audible I believe? These are powerful steppers running at 1.5 amps, I highly doubt they’re slipping.
Ok nice we found the solution.
It’s really hard to hear if steps are lost while acceleration!
It’s a trap!
After I found my maximum velocity and acceleration I divide everything with 2. Upcoming issues are just too nasty and takes tons of time and there are so many factors that can cause problems