Ongoing Dimensional Accuracy (DA)/Measuring Belt Stretch

This is somewhat of a continuation of x and y off by 1%. There, I realized I was cutting parallelograms–say I programmed two adjacent 100mm squares. When I cut them and hold them on top of each other, they line up well, but when I rotate 1 90°, the lack of orthagonality becomes apparent.

I happened upon these realities when I began attempting to cut a peg board. I made holes in a cross shape so the board could be used both horizontally or vertically, but the widths of the two cuts across the board were generally 1/4" or so off from each other.


Pegboard pattern I attempted to replicate, but my hooks either couldn’t fit in the hole or wouldn’t slide down over the groove…

As I was reading through maslow.cpp with my coffee this morning, I believe I understood that, when tensioning, maslow sets TL and TR belts to their anticipated lengths, and then tightens BR and BL.

The issue I’m seeing is that maslow moves substantially when BR and BL are tensioned. I mounted a measure on my board and ran tension belts. In a casual measurement, maslow moves roughly 7/32" down from the position set by the top belts when the bottom belts are tensioned. Here’s a video. I believe this displacement is due predominantly to the TPU/steel belts stretching. Because firmware (if I’m understanding it cortectly) calculates maslow’s position from the place it expects maslow to be according to it’s top belts, and not where it ends up after being fully tensioned and subsequently displaced, it seems error is being calibrated in to maslows position, regardless of frame size.

I know that frame/bolt rigidity can be a sensitive topic, so I tried to see if I could measure belt stretch more directly so it could be quantified. I was anticipating something in the range of a micron of stretch per mm of belt.

I attached two sets of two plates about 180mm apart on the top right belt, near the anchor point. I measured the space between the two plates. Unmounted/laying on my desk, the plates were 178.87mm apart. When mounted but not tensioned, the spacing measured 178.87mm. When tensioned, I measured 179.08mm.


Because the difference was relatively small, and the blocks I had installed weren’t rigid by the nature of the measurement being taken, I thought it might be worthwhile to try and measure a longer sample. Of course the accuracy of my instruments at larger scales dropped substantially from my calipers. I chose my laser measure which has a stated +/- 1/16" error.

I unhanged, retracted, extended, hanged. When I press tension belts, maslow first moves up to set top belt lengths, then tensions bottom belts. Working quickly, and after several attempts, I was able to measure the top belt lengths after being set both before and after tensioning the bottom belts, arriving at these results:

TL

Untensioned: 5’ 7 & 4/32”

Tensioned: 5’ 7 & 11/32”

TR

Untensioned: 5’ 7 & 9/32”

Tensioned: 5’ 7 & 13/32”

These numbers do show elongation in keeping with the overall movement of maslow that I filmed–roughly 7/32" down, but are also close to the margin of error of the instrument. It would be better to make a larger sample of them, but I think time might be better spent beginning to correlate varying amounts of stretch to tension current measurements.

I suspect factoring in belt stretch may be a boon to dimensional accuracy, but getting it ‘right’ may be tough. Factors include stretch due to gravity, varying stretch at different tension currents, and the reality that the ‘distance’ being measured by maslow’s belts as they move through the encoders would therefore be changing under different tensions as well. The stress-strain curve would be linear in the elastic region, so as long as that’s not being exceeded, it should be calculable…

4 Likes

I would suggest that you also play around with retraction current (and possibly
calibration current)

Bar has been seeing that since the 4.1 arms need less force to move, he can use
lower current limits, and that seems to produce more accuracy

David Lang

3 Likes

I think that this is excellent research! I love the technique of adding blocks to the belt and measuring the difference between them! I will have to play with that too.

Re: computing position from just the top belts…you are right that there is code to do that, but it is only used once at the beginning of the calibration process to get a rough estimate of the frame size. When the machine is moving and cutting all four belts are treated equally and are just set to the correct length for their target position.

I played around a little with computing the tension in the belts and trying to compensate for stretch there a long time ago, but I wasn’t able to see an improvement. That doesn’t mean it’s a bad idea, just that my implementation didn’t work. The code to compute the tension should still be in there because it’s something that I’d like to revisit.

In my X and Y off by 1% original post, I tried measuring the offset as the machine jogged away from center, but jogging is a little different than cutting. Since your pegboard has a grid based layout, can you maybe measure the offset of each cut as it moves from the origin point and map out how it deviates from the design? (millimeters please!)

What I found, is the problem gets worse at the edges, which is on par with @dlang 's cool mapping tool. By moving my corner mounts out on the X axis, clipping the ears, and running a super large calibration, I was able to get the machine down to a 2mm deviation about 1" from the edge of the work piece.

BTW, looks like a super cool design! Would love to see more pics.

2 Likes

Also love that someone else is also working on this! :fire:

2 Likes

For sure it’s really interesting… @dlang I did some exploration with calibration current today. It makes sense that the less the bottom belts pull on the top ones, the closer they’d be to their assumed position. It seemed like my cut quality may have been adversely affected, but I’m not sure. I went down first to 900, which seemed to have no impact, and then to 600, at which my bottom arm failed to retract fully. 750 was about the lowest I could functionally go.

I was delighted though that my “frame flex measurements” went up quite a bit. For me, that’s a pretty strong indicator that “measuring frame flex” is picking up a good bit of belt stretch as well. I want to try and think more about this to see if I can imagine a way to use a series of these to correlate belt stretch to motor currents maybe… It would be clutch to have a lis2dw onboard and it could be wired to I2C since there’s not a lot of extra pins and at least one interrupt pin wired. Then the ‘bump’ pulling Maslow out of position could hopefully be detected. In even my brief testing, I noticed that different arms/motors seem to have a different sensitivity to the calibration current setting, and it would be nice to let the accelerometer handle evening that out, although I know that it opens a can of worms as well…

I had been deterred from doing builds of the project since I usually work in Visual Studio Code and the visualstudio.md document seems to say it won’t work, but I’ve been delighted to find I can easily build and flash right from the project, which is awesome. It might be nice to remove or edit the document so others aren’t deterred?

My two biggest objectives I think at this point are to

  • to tension BL and BR at the same time during calibration and homing moves, in order to rule out their effect on creating the parallelogram effect
  • explore working in a stretch factor a little more… I made, flashed, and tested an attempt a few minutes ago. It was exciting to see that my two flex numbers equalled out for the first time [MSG:INFO: Flex measurement: TLBR: 2.360 TRBL: 2.294] but the calibration squares I cut were still about 3mm long in the x and 3mm short in the y.

@kyleschoen can’t measure the pegboard I cut it into stools for people and gave it away…

I also found some missing movement in the z axis… When I bottom out, and then go up again, I have a missing 1.67mm in z height. This may be due to my clipped ears—I can see some flex in ear that attaches to the stepper before the rest of the router carriage begins moving…

3 Likes

Will Puckett wrote:

I was delighted though that my “frame flex measurements” went up quite a bit.
For me, that’s a pretty strong indicator that “measuring frame flex” is
picking up a good bit of belt stretch as well. I want to try and think more
about this to see if I can imagine a way to use a series of these to correlate
belt stretch to motor currents maybe… It would be clutch to have a lis2dw
onboard and it could be wired to I2C since there’s not a lot of extra pins and
at least one interrupt pin wired. Then the ‘bump’ pulling Maslow out of
position could hopefully be detected. In even my brief testing, I noticed that
different arms/motors seem to have a different sensitivity to the calibration
current setting, and it would be nice to let the accelerometer handle evening
that out, although I know that it opens a can of worms as well…

note that frame flex and belt stretch are pretty hard to separate from each
other. you have to have a very stiff frame, or have the frame againat the ground
and watch the anchor points to see if they pull up from the ground to tell if
there is a difference. cameras are good at detecting even slight movement.

the problem with trying to map curren to belt tension is that the resistance to
turning is so variable from arm to arm and for a given arm, it varies over time.

It would be fantastic if you can figure something out

don’t let the guy saying it can’t be done interrupt the person doing it :slight_smile:

I had been deterred from doing builds of the project since I usually work in
Visual Studio Code and the visualstudio.md document seems to say it won’t
work, but I’ve been delighted to find I can easily build and flash right from
the project, which is awesome. It might be nice to remove or edit the document
so others aren’t deterred?

My two biggest objectives I think at this point are to

  • to tension BL and BR at the same time during calibration and homing moves, in order to rule out their effect on creating the parallelogram effect

interesting, it may be worth doing a parallelagram check like the flex check

relax tension
pull very tight on one diagonal
snug up on the other diagonal
relax tension
pull very tight on the 2nd diagonal
snug up on the first diagonal

what is the difference between the two

This is easier to do with a flat frame than an upright frame.

  • explore working in a stretch factor a little more… I made, flashed, and
    tested an attempt a few minutes ago. It was exciting to see that my two flex
    numbers equalled out for the first time [MSG:INFO: Flex measurement: TLBR: 2.360 TRBL: 2.294] but the calibration squares I cut were still about 3mm
    long in the x and 3mm short in the y.

@kyleschoen can’t measure the pegboard I cut it into stools for people and gave it away…

I also found some missing movement in the z axis… When I bottom out, and
then go up again, I have a missing 1.67mm in z height. This may be due to my
clipped ears—I can see some flex in ear that attaches to the stepper before
the rest of the router carriage begins moving…

Interesting. this may be worth exploring more (anchor the carriage in place
somehow and see how much flex there is in the ears, and if the two ears coupled
together are that much stiffer than the one)

some questions to consider exploring

is the carriage sticking on the smooth rods? is it bottoming out against
something before the leadscrews bottom out? is this different when the machine
is against the wall vs against the floor?

when you touch off with a bit, do you have the same flex? or is this only when
squaring up the machine finding the Z stop point?

David Lang

1 Like

I did film an anchor the other day. I haven’t done an overlay video yet, but the flex was very minimal.

I disassembled yesterday and put a new plate on so I have ears again. I was definitely missing steps without them—cutting into the spoil board, or not getting low enough to start cutting at all. After re-ear-ing, I measured the missing z movement again and it’s down to about half of what it was without the ears: down to 0.83mm from 1.67mm. I had been having issues where I wasn’t quite cutting through the workpiece, and it seems like this is the culprit. Perhaps it could be addressed with a piecewise function?

I haven’t tested my Z accuracy, but I suspect your Z issue doesn’t have anything to do with the ears. It’s just a hollow tube that the lead screw hides in.

I do think that in some cases an arm could end up above the end of the lead screw and then contact it while plunging, so I might pop some automotive hose on the end to prevent that.

It does seem like there’s not much going on in the tube, but when it’s attached top and bottom, it seems to remove a lot of flex in the ears…

1 Like

Would it be worth measuring pull force on each arm or anchor point? I’m imaging like 4 luggage scales, or fish scales. One mounted in line at each anchor point. This might help determine how similar or disparate arms are pulling simultaneously on same shared current setting.

My theory is there is probably a reasonable stretch factor that could be approximated based on force applied and length of belt in use. But we need some way to measure force applied and stretch observed. If only we had Mattias Wandel’s force machine.

Dano

1 Like