Rounding Error

[ehtnevets]

klippy.log

I'd been burning a few gallon of midnight oil to figure this out. When using Adaptive Layer Height using Slic3r (v1.3.0 latest build), it generates Z layer height with 2 decimal point (i.e. I see G1 Z1.960 . When Z-lift is used the error accumulate faster at lower height than when not in use. At certain height, the nozzle starts rubbing the print and eventually breaks the print.

I started noticing this after checking out s-curve-exp/scurve-smoothing. I thought it was just this version but reverting back to main branch didn't help. Turning off adaptive layer height on Slic3r helps.

Searching around with rounding error topic didn't turn out anything relevant to my problem so I thought I'd post this to see if my analysis is correct. My Z-axis resolution is enough to support 2 decimal point.

[ehtnevets]

Oh yea, I entered 10 for Z full steps/mm in slic3r so slic3r only generates Z-height in .1 increment. The printer prints perfectly. Sanding the top layer, my Z-height measurements are within +/-.1mm of the drawing.

Liking Klipper w/ s-curve again.

[jakep82]

Your max z velocity and z acceleration are pretty high for a leadscrew. Are you sure it's not just losing steps?

[ehtnevets]

It's half the original numbers from the old factory firmware and been printing fine with those. I thought about losing step problem from to high resolution setup (I started from microstep 32) but didn't think of the speed since I had never had problem with that speed with Marlin. I'll try with half of the current one.

I know it's odd with rounding error from just 2 decimal point but symptoms point to that. Especially the rubbing starts at the layers where slic3r generate less than .1 z-height increment.

[jakep82]

You indicated that enabling Z hop makes the problem worse. To me that indicates you're probably losing steps. You might also want to verify that your Z motor isn't overheating at 1.2 amps.

See this FAQ answer for why Marlin Z velocities don't translate to Klipper. I use a max Z velocity of 10 on my printer.

[jakep82]

I know it's odd with rounding error from just 2 decimal point but symptoms point to that. Especially the rubbing starts at the layers where slic3r generate less than .1 z-height increment.

Also note that printing at sub 100 micron layer heights requires an extremely well tuned printer, and it's very hard to achieve good results with FDM. Any tiny bit of overextrusion will result in the nozzle scraping the part.

[ehtnevets]

Also note that printing at sub 100 micron layer heights requires an extremely well tuned printer, and it's very hard to achieve good results with FDM. Any tiny bit of overextrusion will result in the nozzle scraping the part.

I should word it correctly. I didn't try to print sub 100micron. Slic3r was just using .04mm factor (from 25steps/mm entry). The actual layer is set to a minimum .2mm.

You indicated that enabling Z hop makes the problem worse. To me that indicates you're probably losing steps. You might also want to verify that your Z motor isn't overheating at 1.2 amps.

See this FAQ answer for why Marlin Z velocities don't translate to Klipper. I use a max Z velocity of 10 on my printer.

Z Motors are just as warm as the rest. I'll try the slower acceleration because I don't think Klipper has enough time to reach the maximum speed hoping just .4mm.

The odd thing is that when using .1mm stepping factor even with hoping Klipper doesn't exhibit the problem.

[ehtnevets]

@jakep82 thanks.

It's a misstep. Klipper probably trying to violently signal bang the steppers to accelerate at 250mm/s2 in .4mm.

why using .1mm factor layer height didn't show this problem. It is probably the higher rate of missteps due to combination of stepper mechanical and stepping signals when using non .1mm factor.

[KevinOConnor]

I'm not sure what is being reported here, but it does not sound like a Klipper issue. Klipper does not "round" coordinates - it finds a precise step position for each request and moves to that position at a precise time.

-Kevin

[ehtnevets]

I've doubted from the very beginning that it's rounding error. As @jakep82 pointed out the Z-axis was losing steps. Something I found out though this happens only with layers in .04mm multiple (from slic3r adaptive layer). Fixed layer or .1mm multiple are ok.

[ehtnevets]

I'm not sure what now. I slow z-speed down to 10. I think this [printer] max_z_velocity limits all G1 Z speed. G1 Z18.2 F7800 will not cause any problem. I specify travel speed at 130.

The bulging layers are random in high. They look like comppressed layers and my overall Z-height on the print is shorter than the drawing. More bulging (compressed) layers makes shorter printer (lower Z-height).

[ehtnevets]

I think there is some conditions that make klipper tries to move Z axis at that 130mm/s. I'm hearing different Z axis noises. I truly never have problem with Z axis skipping with the original electronics with Marlin v1.xxx and the new SKR1.4 kit with Marlin 2.xxx. It's true that Marlin can't pulse the stepper fast enough to cause skipping. But being able to pulse so fast that every now and then causes skipping even told not to pulse so fast is a problem.

[jakep82]

Klipper will not move your Z axis faster than the max_z_velocity defined in your config. It still appears to me that you're missing steps because your max_z_velocity and/or max_z_accel values are too high, or you have a mechanical issue causing missed steps at a certain height. You may also be at the edge of the thermal limits for your stepper driver which can lead to missed steps.

[ehtnevets]

Thanks again. good to have assurance that klipper will not try to move z beyond the 2 limits. I'm at 10mm/s and 30mm/s2. I'll half that. No problem with heat. A little warmer than the enclosure (unheated).

I never like stepper let alone open loop.

Has there been a request to have Klipper drive closed loop steppers via USB. It's just like having multiple MCUs. In fact, those low cost closed loop stepper controllers are arduino base.

[jakep82]

I'm referring to the driver on the control board, not the motor. If you don't have good active cooling on your control board, you are potentially pushing beyond the thermal limits of the 2209 driver at 1.2 amps.

See this PR for info about closed loop mechaduino servo steppers. A test branch exists, but it hasn't been updated in a while.

[ehtnevets]

ok, I'll check my 2209. It could be, since it's been very hot lately in my office.

[ehtnevets]

the Z-axis doesn't move much beyond 1mm height.

[pluuuk]

You can use a DUMP_TMC command and check if the drivers are overheating by reading the DRV_STATUS line.

[ehtnevets]

Thanks.

So, I got myself a case fan and TMC5160s trying to overkill the current load problem. After retuning s-curve and PA, I sent a quite big 4hr print job. 2hr later, the Z stuck at a height while the printer spewing plastic on the same layer, around 8.5mm high, over and over.

This part I was printing was not big, just a lot of holes and overhangs that need to be supported. Z-lift is set to 0 so no Z-hoping.

I think it's the USB camera is interfering with the octoprint. I'm not going to waste material printing cubes anymore to prove my point but, without USB camera, so far I've been printing reliably. I'm ok without the camera.

Klipper is on RPi 3B+. I think it's fast enough.

[jakep82]

Without a log of the print that failed, it's not possible to offer any more advice. If the printer is consistently sticking at a particular height, that would point toward a mechanical issue.

[ehtnevets]

Random heights.

[KevinOConnor]

I'm going to close this as it looks like the conversation has concluded. It does not appear there is an issue with Klipper here.

-Kevin