I always use 3000 on mine without issue.
I’ve used laser @2500 for working speed in vector also.
-S
That way you are taking two variables out of the equation at once. My first suspect is the actual backlash compensation implementation. It also looks like that code got some changes that I am not sure have gotten into the SM fork.
(didn’t check at all)
I don’t think it’s the speed per se, more the backlash implementation code going wrong at the higher speeds.
But then again, let’s just see what your test results deliver. Maybe it has nothing to do with it.
I did try the laser myself for the first time yesterday. But that will be the last time for a while too. Need to get the my air outtake to a better level first, 
Yes, I prefer to group variables into tests. It’s faster, generally, to binary search through a group, than linear searching. In this case, not a difference with only 2, but it’s my preference.
Looks like the issue has been isolated in the latest test. Thanks everyone for the suggestions, next steps are to bring the machine back up to the latest firmware and isolate and patch.
My next theory is the backlash compensation must not be a non-integer multiple of the magic number, which for this machine I believe is 0.04mm? More testing required…
2 Likes
Glad to hear you’re making progress!
Do you know how to derive how many full steps there are on this machine? I’ve seen conflicting information (or maybe it’s not conflicting, but I don’t understand).
400 steps/mm in the firmware.
2mm pitch leadscrew??
The machine seems to not respond to steps smaller than 0.02mm.
A thread I saw someone said the driver is microstepping at 1/16.
Some other work done identified the pins controlling the driver microstepping config actually was full stepping?
Not sure how to combine all this into a number. What’s the correct multiple for backlash compensation to not step in partial steps?
If 400 steps/mm is correct (it should be), then that would mean each step is .0025mm. If the machine isn’t responding below ~.02mm, is that implying 1/8 microstepping, and thus the leadscrew is actually 4mm pitch? So minimum motion should be roughly 0.02mm?
Several things I don’t understand about this. If each step is 0.0025mm, why does the machine not respond to 0.01mm motion commands every time - appears to move every other time. Is this a Marlin feature where small movements are ignored? Could that be the source of the issue?
I see there is a minimum segment time in Marlin - that probably isn’t related here, but might be related to another issue I’m having…
This is new for me too, so I’m just writing out my thoughts. When you’re referring to the pitch, do you mean the lead of the screw? But I would assume they are the same in this case. (What is the difference between pitch and lead when referring to a screw?). I don’t think that number actually matters for this reverse calculation (other than a sanity check)
I came to that number as well. But I’m not sure I’m following with the rest. So I’m writing it out to make sure we’re saying the same 
I assume the steps/mm are the microsteps and not full steps; correct?
the travel of one step is 0.0025mm as mentioned above.
1/8 microstepping thus means 0.02mm travelled per full step
with a standard stepper motor that does 1.8 degrees per step, we thus come to a lead on the screw of 4mm (the pitch could still be 2 if it has two starts, don’t know for sure if that’s the case).
I was browsing through the forum trying to find some pictures. Looking at this one: Linear Module defective and FW 1.8.0.0 Feedback - #6 by Edwin and trying to guess without a lot of reference (only reference I’m guessing about are the pcb’s that I assume have a more or les standard thickness of +/- 1.8mm)
Based on that picture, It does seem to have a lead larger than 2mm pitch. So a 4mm lead and 2mm pitch could actually be the case. (At this point I don’t have a compelling reason to open one of the modules to check )
So we seem to come to the same numbers independently, but I don’t understand that statement? Can it only do full steps for some reason? because:
I would assume it can make movements that small?
Probably there are hardware limitations I’m not aware off (I’m a software guy, not a mechanical/electronics engineer)
In conclusion, I guess I’m mostly rephrasing the same questions you have 
But based on that picture it does seem plausible that the lead screw has a lead/pitch ratio of 2.
1 Like
A full step is 0.04mm. A single step (@1/16 microstepping) is 0.0025. It is a 1.8° Nema 17 syepper motor with an integrated leadscrew (pressed in and epoxied to the rotor) of 2mm pitch - 4 start which has a lead of 8mm. Add to that the low quality leadscrew which has a mechanical variation in lead over it’s entire length, combined with axial play in the stepper motor itself and you get a hobby level machine.
Now if you home the X, or Y for that matter, during your job, you don’t know which microstep triggered the inaccurate mechanical limit switch. This means you could be a couple of microsteps out of sync with the previous motion before the axis was homed. You would have to go to closed loop control to mitigate some of the inherent faults in the machine and maybe change out the leadscrews and nuts to a quality 2mm pitch single start Misumi brand screw.
tl;dr a full step is 0.04 mm and it is a hobby level machine with inaccurate components.
Yea, I guess I understand that, but not how that can cause backlash compensation to loose steps.
0.11mm would be 44 steps, which is an integer multiple of the microstep. I’ll change it to 0.12 just so it’s also an integer multiple of the full step, see if that does anything.
EDIT: 0.12 as the backlash still exhibited the error. So the problem is solely backlash, and not speed or anything else. Also integer multiples of 0.04 do not matter. Retrying with 0.02 backlash just for a test.
4 tests completed at varying backlash, all other settings identical:
0.02mm, 0mm (disabled):
0.12mm and 0.11mm
I think there are very interesting conclusions to be drawn here. 0.11mm and 0.12mm are much more different than I would expect.
0mm and 0.02mm are different slightly. Just for reference, here is the correct pattern:
and 0mm (left) and 0.02mm (right)
It’s worth mentioning that there is slop in the X axis of approximately 0.11mm, which is what I was attempting to correct with backlash compensation. However, without any firmware fixes it seems like better performance is had by disabling all backlash compensation.
On the 0.12mm test the minimum and maximum deviation between the overlays ranges from 0.5mm to 2.0mm. It’s interesting how fast it diverges over time.
Final, correct, project:
Next steps would be disassemble the x axis and correct the slop, and disable all backlash compensation globally, as it causes unknown divergence. Until that can be corrected, I feel backlash compensation should not be recommended to be used.
The small difference from 0 to 0.02 compared to the large difference between 0.11 to 0.12 is interesting and work diagnosing.
I’ve looked at the source relating to the backlash compensation implementation and I haven’t yet identified any candidates that would explain this behavior.
@Brent113, is there a way that this could be converted into a universal test that could be run on devices around the world?
I daresay that the results are likely to be different which may help.
I’m also wondering if there’s a way to extract the current version numbers and output those from within a running G-code file.
I’ve not yet dug into the language description for G-code, so variables may not be a thing. (Extracting data remotely and generating G-code on the fly might be several levels of complexity too high.)
That does lead me to contemplate an external tool that communicates via a serial port to run a whole suite of calibration procedures.
Some time ago, I had a somewhat similar problem with y-axis drift on my Snapmaker 1. It turned out to be some slippage in the shaft coupler between the y-axis stepper motor and the y-axis threaded rod. Tightening the set screws on the coupler solved the problem.
Some of the slop may be inherent in the way the lead nut is shaped. If the pitch diameter of the lead nut is a bit larger than that of the lead screw, there’s inherent backlash. This remains true even if the pitch of both the nut and screw were perfect. This may be compensated by using a pair of lead nuts, one bearing on one thread face and the other bearing on the one opposite it, on the other side of the groove. For light duty, spring-loading is acceptable. For heavier duty, the distance between faces is adjustable.
The most common way of measuring pitch diameter is the three-wire method. It requires wires of accurately-known diameter. Gaging the pitch diameter of an internal diameter is much more complicated. Here’s an article to give an idea why. It may well not be worth trying to diagnose the existing lead nuts by measurement.
This looks like one of those cases where the easiest fix may be to replace the lead nut with a more accurate one. The pitch diameter of the lead screw can be measured accurately, and a nut machined to match. An alternative is to add a spring-loaded second nut, which would decrease the total travel. Other configurations are also possible. On the other hand, once you’re making new lead nuts, you have to wonder whether you’re still working on the right problem, or even the right machine.
Hey, could this also be important for 3d printing and your calibration thread?
There’s an absolute value function in add_backlash_correction_steps. If the total error is greater than this, there’s no problem. If it’s not, this will send the residual error negative, which is probably wrong. This could occur in the code where there are lots of direction changes with small total travel before the next direction change. All those wiggly map lines are ideally suited for this condition to arise.
1 Like
So that’s not a project for the upcoming rotary module then?
I’m not sure I follow what you’re saying the here, but I looked at that section closely.
Ignoring the preprocessor #ifdefs that aren’t included, and the final residual_error assignment because the variable is not static, it’s this:
xyz_long_t residual_error{0};
const float f_corr = float(correction) / 255.0f;
LOOP_XYZ(axis) {
if (distance_mm[axis]) {
const bool reversing = TEST(dm,axis);
if (TEST(changed_dir, axis))
residual_error[axis] += (reversing ? -f_corr : f_corr) * distance_mm[axis] * planner.settings.axis_steps_per_mm[axis];
int32_t error_correction = residual_error[axis];
if (error_correction) {
block->steps[axis] += ABS(error_correction);
}
}
}
Steps are always positive because stepper direction bits are stored in a different var. I think this makes sense. I’m not really seeing how error will creep in.
Since residual_error[axis] will be a constant as none of its dependents change except when a new M425 command is issued the number of steps being added to each block SHOULD be the same.
The only thing I can think is if there’s a float error when the floating point math is converted into the residual_error long where positive values are rounded one way and negative values rounded the other inducing a difference.
Another possible source of error could be related to what looks like to be an assumption in how the backlash extra steps are actually handled. One would think those extra steps would be injected at the start of the block’s motion to take up all the backlash at the start, but it appears they are evenly spread over the entire block.
This doesn’t really explain how error accumulates, but it is a good reason to only use small values for backlash compensation. 0.02mm only adds an extra 8 steps, any error would be hardly noticeable.
I think I’m going to close this chapter and move on though. I disassembled the X axis linear module and tightened an eccentric cam that had loosened, and that resolved the excessive backlash issue. After testing the backlash is back to the factory stated 0.02mm, and that seems to work fine with software compensation.
With testing there is a noticeable difference between 0, 0.02 and 0.04, and 0.02mm is the best
So are you saying that backlash compensation is already set to .02mm? i thought that i had read that backlash compensation was disabled by default?
or are you saying snapmaker had made a recommendation to you to apply this backlash compensation?
should i fiddle with this or not? i have not yet.
That’s correct.
I’m referring to the machine specification https://support.snapmaker.com/hc/en-us/articles/360046836553-What-re-the-repeatability-max-travel-length-backlash-of-the-linear-modules-of-three-models-
To compensate for that backlash you can enable compensation. But it’s relatively small and you don’t have to.
1 Like