Backlash and Slack Compensation [SOLVED]

[Jet]

I tried new belts/pulleys from amazon today. 25% reduction in the backlash, but doesn't solve it.
I've also tried deflecting various plates, surfaces, cable chains etc. manually to see if I can reproduce, no visible deflection of anything during movement.

So, it appears I have 2 types of backlash, the usual one (due to the gear), which is removed with the regular slack compensation, and a 2nd type that appears similar to backlash and is removed with slack compensation, however it requires 45mm of slack compensation on every move to fix. (which has to be inversely, i.e. from the right not the left, to not effect the the origin area, i.e. negative).

I.E. In CNC.cs, changing: SlackCompensationDistance from 0.4 to -45.0 removes the 2nd type of backlash.

Looking at this more, I'm beginning to think that the problem is the drive arrangement on X and Y axis. I.E. Take the X axis, the stepper is on the right hand side of the axis. I thinking this would cause an imbalance of tension in the belt and therefore offset the head, depending on the direction of travel leading to inaccuracy. For example, when the head is in the center of the X axis, the distance to the gear is 25% length on the right and 75% on the left.

Also, pulling centrally with similar pressure on both belts after both direction moves results in less inaccuracy (0.02mm).

Different tightness of the belt makes no difference unless the belt is ridiculously loose.

I've noticed many other CNC machines put the stepper on the head on the X axis, and on the carriage on the Y axis (e.g. inventables X-Carve), i.e. as the belt is fixed and the gear is on the moving part, there's no imbalance of tension in the belt depending on direction of travel.

However, conversely, if that was the case, everybody would be having this issue, not just me...., unless there was a change in belt quality at some point which resulted in more stretch (somewhat supported by getting less error with the replacement belt).

The test for it is simple, with Slack Compensation enabled, move the head to the center of the X/Y axis, put a dot on a piece of paper, similar to the homing mark, under the camera and measure it with the Measure button.

Move Left 100mm and Right 100mm, measure dot.
Move Right 100mm and Left 100mm and measure dot again. Difference between the measurements is the error. I'm down to 0.064mm now with the new belt.

And wth 45mm of slack compensation, that changes to 0mm error, but 45mm isn't practical.

One other person has this problem, anyone else noticed it?

[Stefan]

I ran this experiment this morning with my now almost fully setup Liteplacer (still need to setup vision for the part tapes). When I jogged to the right and back 100mm I had to micro jog the machine 0.02-0.03mm back to the left to get into the same spot. When I jogged to the left and back I had to micro job the machine about 0.02-0.03mm back to the right to get into the same spot. So the cumulative error I suppose would be something about 0.05mm. Note that in both cases I was using the mm hashmark of a ruler for the test, and that the cross hairs of the image was still very much in the hashmark itself (hence the small 0.02-0.03mm difference).

Since I was curious as to whether I need to care about this I looked at the part dimensions for an 0402 passive component (frankly I don't use anything below 0603 in my designs since I've up until now always hand assembled). The dimensions for a 0402 part is 1.0 mm × 0.5 mm. So assuming you have the long side of the part aligned with the Y axis, a 0.05mm error is a 12% error.

I then realized I should look instead at individual pads of the 0402 component. The pad size for one of the two pads on an 0402 component according to Kicad's standard library is 0.4mmX0.6mm. A 0.05mm placement error is 1/8th of the short side of a 0402 pad. This is better than I can do hand placing by far, and I can reliably hand place a 0402 populated RF circuit (although I want to kill myself while doing so).

What this suggests to me is that this 0.05mm error is too low to matter for the components the Liteplacer is sold as being able to place. In addition, since the parts are always being brought to the board from the same direction, the error is probably more like 0.03mm at most in practice.

Also, as for why this is happening, it seems possible it is due to the belt moving on the pulleys. You go one direction the belt might move up on the pulleys, you go the other direction, it might go down on the pulleys. When you put a new belt on it probably had a slightly different width, so it might be riding up or down slightly less than before.

If I did need to improve this I would almost try putting the belt under a little pressure using the drive pulley on the stepper motor. Perhaps if the pulley kept the belt against one of its sides the belt wouldn't be able to ride up or down. This is a complete guess though, so I'm sure there are many reasons it wouldn't work.

[JuKu]

[Jet] Take the X axis, the stepper is on the right hand side of the axis. I thinking this would cause an imbalance of tension in the belt and therefore offset the head, depending on the direction of travel leading to inaccuracy. For example, when the head is in the center of the X axis, the distance to the gear is 25% length on the right and 75% on the left.

My thinking is that the free pulleys would balance the tension on X. Apparently, this doesn't fully happen. On Y, this is more valid: The belt from the carriage to the pulley can be very tight and the rest of the belt could be loose. This is why I recommend doing the belt tightening with pulleys loose, moving the bar manually a couple of times to even out the tension and then tightening the pulleys.

[Jet] I've noticed many other CNC machines put the stepper on the head on the X axis, and on the carriage on the Y axis (e.g. inventables X-Carve), i.e. as the belt is fixed and the gear is on the moving part, there's no imbalance of tension in the belt depending on direction of travel.

There would be imbalance still. For any looseness on the belt, the motor will first take up the looseness (slack) and tighten the belt, and only after that, start to move the machine. And the same to other direction. A good reason for the CNC machines to have the belt that way is that the belt is much easier to protect from dust and chips. The reason I have the belts this way is to reduce the mass that the machine needs to move, allowing faster accelerations and reducing vibrations.

-----

Ok all that doesn't solve the issues, just rambling about the design.

[Jet ]...unless there was a change in belt quality at some point which resulted in more stretch (somewhat supported by getting less error with the replacement belt).

This is certainly possible, although I haven't got feedback that would point to this. I need to re-belt my machine to use the belt I have in stock now. (That gives only one data point. It would not prove anything about belts I shipped a few months ago, but might give a hint.)

[Stefan] ... I had to micro jog the machine 0.02-0.03mm back

This is very close to what the current design can do even in theory: The pulley and belt give 40mm movement on one rotation. 0.9 deg/step is 400 steps per rev, so one step is 0.1mm With 8x microstepping, you in theory get 0.0125mm resolution. But microstepping is not 100% accurate. In our case, there are no forces pushing on the gantry, unlike on CNC machines. Still, we can expect that microstepping only gets close to the theoretical point. The 0.02 -0.03mm is about +- 1 microstep. (FYI, I'm currently experimenting with 4x microsteps. The machine moves faster, and I don't see much difference in accuracy.)

[Stefan] it seems possible it is due to the belt moving on the pulleys. You go one direction the belt might move up on the pulleys, you go the other direction, it might go down on the pulleys.

You might have something here. This idea warrants closer inspection. I don't have Jet's issue, but if I can make that appear by forcing the belts to move, bingo.

[Jet] pulling centrally with similar pressure on both belts after both direction moves results in less inaccuracy (0.02mm)

Ha! Even though I don't know what the problem really is and why this makes it almost disappear, this might be solvable. Putting these on the inactive parts of the belt (back section on X, low section on Y) might give the desired effect. The distance from idler to idler is longer than the range of movement, so there should be a safe spot for this: https://www.robotdigg.com/product/41/Ti ... ner-Spring These are available everywhere (Ebay, Amazon, 3d printer shops), the search term is "6mm Timing Belt Tensioner Spring".

[Stefan]

This is very close to what the current design can do even in theory: The pulley and belt give 40mm movement on one rotation. 0.9 deg/step is 400 steps per rev, so one step is 0.1mm With 8x microstepping, you in theory get 0.0125mm resolution. But microstepping is not 100% accurate. In our case, there are no forces pushing on the gantry, unlike on CNC machines. Still, we can expect that microstepping only gets close to the theoretical point. The 0.02 -0.03mm is about +- 1 microstep. (FYI, I'm currently experimenting with 4x microsteps. The machine moves faster, and I don't see much difference in accuracy.)

That's what I kinda figured, thank you for the anaylsis!

I wonder if due to the improved camera resolution folks are able to actually see the accuracy of the machine now, whereas with the lower resolution you couldn't actually visualize it.

I tried out a portion of the Hello World job last night and I'm quite happy with the results! I took a quick picture of it this morning. I'm 90% sure that the parts would be even more centered if I hadn't performed the nozzle calibration with the A axis not in the home position, but then homed the A axis before placing.

[Jet]

[Stefan]Also, as for why this is happening, it seems possible it is due to the belt moving on the pulleys. You go one direction the belt might move up on the pulleys, you go the other direction, it might go down on the pulleys. When you put a new belt on it probably had a slightly different width, so it might be riding up or down slightly less than before.

I did notice that with the 2 idlers by the stepper on the X axis, that travel in opposite directions results in the belt going up one pulley and down the other. I thought that could be a cause like yourself, although I also considered that they would balance each other out when I saw visibly one was going up and one down. But to be sure, I moved the stepper gear upwards, forcing the belt to the top of the pulleys in both directions. But unfortunately it didn’t make any difference.

[JuKu]My thinking is that the free pulleys would balance the tension on X. Apparently, this doesn't fully happen. On Y, this is more valid: The belt from the carriage to the pulley can be very tight and the rest of the belt could be loose.

I didn’t notice much of a difference between X and Y btw, the error is about the same.

I’ve been looking at this, where they mention the 2 linear positioning driver types, which supports your design that there’s not much difference in the 2 methods, and as you said extra mass is always a concern.

http://www.gatesmectrol.com/mectrol/dow ... r=brochure

However I’m thinking 2 less pulleys and half the belt length, and less potential for belt movement, deformation of the structure etc., may lead to less of it, or fixing it (just considering X axis)

[JuKu]Ha! Even though I don't know what the problem really is and why this makes it almost disappear, this might be solvable. Putting these on the inactive parts of the belt (back section on X, low section on Y) might give the desired effect.

This one I tried a few days ago, (ordered some springs with the new belts from amazon). I tried the following on X, all of which made no difference, spring on the back long stretch. Spring on front section to the right of the carriage, spring on front section to the left of carriage. Spring on right and left front, and spring on back and left and right front. Also tried a few different tensions on the belt in unison with the springs, the error didn’t change.

[JuKu]This is certainly possible, although I haven't got feedback that would point to this.

lfkeyboards indicated he has a similar issue in this thread. What did that turn out to be in the end? Or was it unrelated?

What’s interesting is backlash compensation of 45mm solves it completely, which tends to point to the belt.

[Jet]

So what I’ve decided to do here, is with the slightly better belt, which gets rid of about 25% of error...

Set the slack compensation to 10mm, it doesn’t remove all of it, but it removes about 50% of the error, as 45mm to remove all is unworkable (from an operational / speed point of view)

So I now have 0.032mm of error on X/Y, this gives me a total of 0.064mm in total (as error occurs on the homing dot and on every move afterwards), which should be accurate enough to get reasonable placement on most of the smaller stuff.

Things I’ll look at later is stiffer or steel belting (I’ll have to look into the size of pulleys / gears as it can fracture the steel if too small).

I suspect the belt purely because a change in belt produced a small improvement in accuracy.

Even if mounting the stepper on the head improved things, it wouldn’t remove the issue completely and would increase mass, and even if that did reduce it, the same results could be achieved with a stiffer belt, purely because it’s a spring constant thing, and the less springiness, the smaller the problem because there’s less stretch in the longer end of the belt.
But the belt stretch is definitely a reality according to the mathematical modelling, but the reasonable priced belts from China are short on specifications and likely change from batch to batch anyway.

@Juhu, a future feature request would be to have a field somewhere to be able to change the slack compensation amount, including allow negative slack compensation... something to consider would be only negative compensation anyway, because the max limits of the axis are less used than the min limit areas, so it interferes less with homing, nozzle changes etc. when users experiment, and negative or positive both address the issue. Infact, if short on space, maybe instead of the tick box for Slack Compensation, a number field with 0 meaning no compensation.

Now back to testing component placement again, hopefully now it will be good.

[Halt]

I have been working on this machine for months trying to get it to accurately place 0402, I am balls deep into rewriting some of the TinyG firmware and also been contributing to OpenPnP to make liteplacer work on there. I can not figure out why i have such high inaccuracies as you do. I bought my machine back in April and probably have over 800+ hours trying to set it up / coding to work right. I am thinking it has to be these belts as well, They are stretchable like rubber bands.

[Jet]

So I tried a different X axis setup with some 3D printed parts. 2 bearings and stepper located on the head, and one piece of belt the length of the x axis,
with it fixed at one end and adjustable tensioner at the other end. So belt is fixed, and stepper works it's way along the belt.

Surprisingly, it didn't make any difference to the inaccuracy (I would expect it to at least improve by 50% as it's half the length).

Still stumped,

[JuKu]

> I am thinking it has to be these belts as well, They are stretchable like rubber bands.

Really? The belts are supposed to show very little stretch. When I get back to office, I need to run some measurements. I have my old used belts that have been hit hard several times. I have some old belt that hasn't been used (too short piece) and of course, samples from last order. I'll report.

[Jet]

To verify it was 100% mechanical and wasn't the TinyG or Software.....

Built a teensy app to monitor the steps sent in the form of an accumulator, result was the steps are correct, there's no imbalance.
To outrule the driver, connected the X axis digital output to a gecko stepper driver (G251X). Made no difference.

So, that outrules the electronics hardware and software. Definately mechanical.