@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
Best Regards
I’m very sorry I have no environment for testing with dual extruder, so I can not support dual extruder 
Hello,
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).
Best Regards
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:
Retract_length: 2
Retract_speed: 30
Unretract_extra_length: 0.1
Unretract_speed: 15
Zhop_height: 2mm
Zhop_speed: 25000
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:
- acceleration
- 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.
1 Like
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
Best regards
1 Like
Hi guys,
what is a good value for the Z-Hop speed?
Cura seems to use 5. I would have set it to 5 for now, 100 seems to me crassly high…
Greetings Stephan
It really highly depends on your printer. But the main problem is that this are different units.
Cura specifies the speed in mm/s
G1 takes it arguments in mm/min
And 5 mm/s are 300 mm/min so a value of 100 mm/min is already carefully chosen.
I did some modifications to my printer, and I’m able to run at 2000 mm/min == `33.3 mm/s’, with high acceleration and without vibrations.
Please also note that the maximum speed only applies if it is lower or equal the printer limits and if the acceleration is high enough to reach this speed on the z-hop distance! Higher acceleration can cause lost steps or vibration.
Sadly I can not help you further than this as I’m not able to inspect or make tests on your printer. But I wish good luck and happy 3D Printing
Best regards
MasterQ
Oh thank you very much for the quick help,
that explains my irritation ^^. I will make a few test prints and start at 300 mm/min, with cura it worked well.
Kind regards,
Stephan
Hi Folks. Just in case, I submitted a PR for native firmware retraction support includig zhop:
firmware_retraction: Support nozzle lifting on G10 by flopana77 · Pull Request #6239 · Klipper3d/klipper (github.com)
The PR enables nozzle lifting (zhop) when retracting using G10 command; fully configurable at runtime; in absolute or relative mode. In addition, it introduces three different zhop movement styles (standard, ramp and helix) suitable for different use cases. It clears retraction reliably to prevent nozzle crashes and other unwanted behavior after changes of the printing state (start, cancel or finish prints from virtual SD Card as well as via GCode streaming).
If you could review, this would be very much appreciated
Cheers Florian
1 Like
how can i fix this Invalid speed in ‘G1.1 F0 X127.455 Y116.513 Z0.5’
F0
Maybe you have retraction distance greater than 0 mm and speed = 0. If you want to disable firmware retraction don’t set the speed to zero but set the distance to 0.
Or there is a problem with the Goode you use. Hard to say without more details.
Good luck
G1.1 is the name of the original G1 firmware move. It has been replaced to be able to respect the z-offset if z-hop is active. The z offset is added, and all other parameter are parsed to the original method (G1.1). Here the klipper error handler is active and the error is thrown.
1 Like