Z-probing changes Z height
Hi.
I have always had repeatability issues when probing using BL touch (and also with a clone) on my Core XY, to the extent I abandoned ABL and distortion correction. Some recent changes to what I print made it worthwhile for me to look at it again.
After much frustration, I went back to basics, checked all the mechanics and fasteners, removed the spring-loaded bed, and applied a dial indicator to the Z axis carriage. After a few small tweaks, eventually I had a Z axis that I was certain was accurate to better than .01 mm in 25 mm, repeated to much better than .01 mm over 100 cycles, had undetectable backlash, and with a home setting repeatability to .01 mm or better.
Despite this, the probe still would not repeat. Over a series of 30 G30 commands, with 3 probes per G30, at the same machine position, the probe measurement drifted down by 0.116 mm, which gives about .00128 per probe or about .004 per G30. A dial indicator on the Z carriage confirmed that the carriage had moved up this same amount. On re-homing the Z axis, the Z carriage position reverted to that before the series of G30 commands. This seems to say the Z axis position is actually changing, rather than any defect in the probe.
Note: I'm not saying the probe has no errors. The variation between any two G30 measurements can be +.005 to -.010, but the average change is -.004. Suggests the G30 operation itself is accurate to about .007 mm?
As a further test, I programmed a series of 50 Z axis move cycles emulating the probing motion (e.g., Z at 10 mm, G0 Z1 F120, then G0 Z10 F600). The Z carriage finished in the same place it started.
I tried several probe speeds and Z axis acceleration values, with no significant differences.
At this point, I realized the Z axis resolution is 798 steps per mm, or about .00125 mm per step, which is very close to the observed Z change at every probe cycle; probably not just a coincidence. It doesn't feel like a simple rounding artifact, or some timing issue, as that would likely show up as randomness rather than a steady trend. So I suppose I'm suggesting there is a bug that somehow loses (as in miscalculates) one -Z step every time the probe is triggered.
I'd like your comments, please, and any suggestions about how to deal with the issue, or maybe definite identification of the cause. As you will realize, it takes 75 probes to map a 5x5 grid for distortion correction, which means the last correction will be in error by about 0.1 mm, even if the probe starts off perfectly calibrated. This makes the distortion correction unusable. This, in turn, is making my distorted bed unusable for any print that uses a lot of the bed area.
Thanks!
I have always had repeatability issues when probing using BL touch (and also with a clone) on my Core XY, to the extent I abandoned ABL and distortion correction. Some recent changes to what I print made it worthwhile for me to look at it again.
After much frustration, I went back to basics, checked all the mechanics and fasteners, removed the spring-loaded bed, and applied a dial indicator to the Z axis carriage. After a few small tweaks, eventually I had a Z axis that I was certain was accurate to better than .01 mm in 25 mm, repeated to much better than .01 mm over 100 cycles, had undetectable backlash, and with a home setting repeatability to .01 mm or better.
Despite this, the probe still would not repeat. Over a series of 30 G30 commands, with 3 probes per G30, at the same machine position, the probe measurement drifted down by 0.116 mm, which gives about .00128 per probe or about .004 per G30. A dial indicator on the Z carriage confirmed that the carriage had moved up this same amount. On re-homing the Z axis, the Z carriage position reverted to that before the series of G30 commands. This seems to say the Z axis position is actually changing, rather than any defect in the probe.
Note: I'm not saying the probe has no errors. The variation between any two G30 measurements can be +.005 to -.010, but the average change is -.004. Suggests the G30 operation itself is accurate to about .007 mm?
As a further test, I programmed a series of 50 Z axis move cycles emulating the probing motion (e.g., Z at 10 mm, G0 Z1 F120, then G0 Z10 F600). The Z carriage finished in the same place it started.
I tried several probe speeds and Z axis acceleration values, with no significant differences.
At this point, I realized the Z axis resolution is 798 steps per mm, or about .00125 mm per step, which is very close to the observed Z change at every probe cycle; probably not just a coincidence. It doesn't feel like a simple rounding artifact, or some timing issue, as that would likely show up as randomness rather than a steady trend. So I suppose I'm suggesting there is a bug that somehow loses (as in miscalculates) one -Z step every time the probe is triggered.
I'd like your comments, please, and any suggestions about how to deal with the issue, or maybe definite identification of the cause. As you will realize, it takes 75 probes to map a 5x5 grid for distortion correction, which means the last correction will be in error by about 0.1 mm, even if the probe starts off perfectly calibrated. This makes the distortion correction unusable. This, in turn, is making my distorted bed unusable for any print that uses a lot of the bed area.
Thanks!
Comments
0.005mm skipped at each probe
Sorry, I try to see if it's known first, but I missed that one. I tried the dev version and found that in the middle of the Z carriage that there is now no apparent drift of the Z axis, so good, thank you. However, after replacing the bed on the carriage and testing the whole bed area I got some strange results that made little sense at first. I don't think it has anything to do with probing, so maybe it should be a new topic; however I will describe it here.I re-attached the dial indicator and found the Z axis was under-travelling. I'd previously changed the Z from 800 to 797.6 steps per mm to get accurate Z motion, so this was an unwelcome surprise. It seems I had adjusted the Z rate at the centre of the bed and was now measuring it at the front middle, so the Z step size was different across the bed. This is apparently impossible, so let me explain that I am using a three-motor Z axis arrangement, so I conclude the leadscrews on the three motors must not have the same pitch. Cheap parts....
I think I have it configured correctly. The Z axis is set to "Mirror motor signals to other stepper driver (FEATURE_TWO_ZSTEPPER)" and "Mirror motor signals to third stepper driver (FEATURE_THREE_ZSTEPPER)". For the motor-driven ABL, I have set up these same steppers as Extra Motors. The HW config must be right, as it works as expected. I originally set the steps/mm for these two to 800, the same as for the Z axis. When I was compiling the dev version, I changed this to match the new Z axis value, 798. I suspect this only has an affect when doing ABL or G201/2, so wasn't a factor in the Z motion issue, but maybe it does affects the normal Z motion?
So is there a way to specify different steps per mm for multiple axis drive motors? It's not an uncommon arrangement (e.g., my Prusa has two Z motors), so I have hopes.
Thanks,
Jed
Did you test if the 798 steps is for the complete rod - not only the rotation part at the beginning. I mean if the steepness is not constant but on average e.g. 4mm/rotation that you should ignore it. If it is constant the error will grow to 0.5mm at Z=200 and of course can not be ignored if the others do not follow.
I do in fact have a RADDS/Due setup, RAMPS did not seem able to handle the CORE XY when I tried it, can't remember exactly why. The V2 is new to me: is it available and where? I couldn't immediately find any download.
The 798 was calculated in the middle of the carriage at the top of the travel (Z = 0 to Z = 20) when wondering why a 1 inch gauge block gave a different Z height than a 0.1 inch gauge block. I also checked the area around the current Zmax at the front of the carriage as part of checking the homing repeatability, and that was accurate within less than .01 mm.
It really didn't occur to me at first that the three rods would be significantly different in pitch, as they were purchased at the same time from the same source. I would expect the pitch to be a bit off, and to vary along the length a little (even ball screws do that). Since then I did a few more tests effectively on each rod, and find that the pitch of the two front rods is undetectably close to 2mm, but the back rod is more like 1.985 mm. This was again at Z = 0, which as you say is where it matters most. I can't see any relative vertical movement of the three nuts as it moves, I'll need to somehow test what happens at different Z.
BTW, does Repetier have pitch error compensation? I work on industrial CNC machines and they all have it, as does EMC CNC (LinuxCNC) software, which I use on my Taig mill.
What does " pitch error compensation" exactly do - different pitch over z or adjustable resolution. As said in V2 there is a virtual drive STEPPER_ADJUST_RESOLUTION(name, driver, from, to) that can map a virtual higher resolution to different resolution which you can use here. It will have a remaining error of max. 1 step then due to rounding to steps.
Pitch error compensation is basically a table of errors versus axis positions. It is used to compensate for varying pitch of the leadscrew, rather than a constant pitch error (though it would handle that as a special case). LinuxCNC stores in a file a set of triples that give the nominal position (either measured by encoder feedback, or commanded), the "real" position going forward, and the "real" position going backward, so it also does backlash compensation which can vary with axis position. From my experience, the cheap hardware we use definitely has variable pitch and variable backlash (at any rate after the first couple of months of use). I saw significant improvement on my Taig mill.
Whether the increased accuracy is worth the effort of collecting the error data depends on how good the screws are and the desired results. In today's FDM world, probably not; the lead screws are not fantastic, but expectations aren't high either. The Peopoly Moai SLA printer does have a similar "calibration profile" for X and Y axes, which are not screws at all but motorized mirrors, with very large non-linearity. This is essential for that printer and it's expected accuracy. However, the compensation is part of the slicer, not the machine.
BTW, I measured the pitch of my three lead screws independently, and found the actual measured travel for a 25.4 mm Z move was 25.4, 25.38 and 25.38 mm, with steps/mm set to 796.33.
I also found that over 200 mm Z travel, the position difference between the 3 screws was no more than .03 mm at any point. This shows the screws are not constant in pitch (or we would have more than 0.15 mm difference over 200 mm), but the pitch does vary and the average pitch is pretty consistent.
Sorry, just my philosophical ramblings.