Belt stretch & sag. Maslow’s model treats the belts as perfectly stiff, but
IRL they’re springs. On a vertical rig gravity exaggerates the mismatch: TL/TR
belts have to fight sag, BL/BR get a free assist. Net result is a “bow-tie”
pull toward center. Should be doable to compensate for this in the software
(needs a spring constant variable).
perfectly stiff (no stretch) and 0 weight (no sag)
Result of Maslow’s calibration routine is the width/height of the frame, but it hides the fact that all frames are slightly trapezoidal/skewed. @kyleschoen, if you could share anchor-to-anchor distances (all 6, including diagonals), that could help diagnose this. Software could compensate using 5 of these measurements, bypassing the current calibration routine.
no, the result of calibration is the coordinates of the 4 anchors, one at 0,0
one at 0,y1, one at x2,y2 and one at x3,y3
Frame flex. Not something that software can compensate easily (I think it’ll become complicated & hard to grasp the effects).
If we can know the belt elongation factor, we can test the frame under different
tensions and figure the difference from what the belts account for is due to the
frame flex
Direction-dependent error. The left-to-right vs right-to-left discrepancy
feels like a belt-stretch artefact. Possible to correct in code, but
complexity ramps fast (depends on friction, bit size etc), so I’d leave it
until 1-3 are nailed.
My proposal would be to tackle the list in order, leaving #4 for dessert.
Instead of hacking firmware every round, maybe there exists some “g-code
deformer” tool that pre-warps toolpaths to cancel the bow-tie and compensates
for skew? It’ll be easier to iterate, and we could use the results as
inspiration for a future firmware update.
we need to get a better model of the error before we can program in correction
(either in the firmware or in an external tool)
Didn’t do the math but - assuming the deformation is symmetrical (all belts having a nearly identical stretch), taking the belt elongation factor + belt angles should be enough to model the bow tie effect, right? At least for a horizontal setup. But I don’t know how much of a problem this really is. It seems to be pretty visible in the top y deviations in the table.
Ah ok, nice! @kyleschoen I think you said that you entered the frame measurements manually (not using the calibration tool), did you take skew into account?
Do you think measuring belt force is going to be repeatable enough (motor variance, ADC drift, temp, dust, spool lenght, arm friction, …)?
Didn’t do the math but - assuming the deformation is symmetrical (all belts
having a nearly identical stretch)
This will not be the case, the forces will balance out, but each belt will have
different force (depending on the angle) and different stretch (depending on the
force and length)
Ah ok, nice! @kyleschoen I think you said that you entered the frame measurements manually (not using the calibration tool), did you take skew into account?
we have several calculators/spreadsheets that take the 6 measurements between
anchors and calculates the positions)
Do you think measuring belt force is going to be repeatable enough (motor variance, ADC drift, temp, dust, spool lenght, arm friction, …)?
I don’t think we cam measure the force with the current hardware, but I think we
can make a good stab at calculating it.
Yes, I put the dimensions and diagonal measurements into CAD to get the skew. My frame is surprisingly square the calibration numbers were fairly far off from the manual measurements.
I’m out of town this weekend, but will pick the project back up when I’m home. I was going to try loading a belt and measuring the stretch, but that will need some setup.
@kyleschoen Maybe the calibration routine does inadvertently (by detecting somewhat off anchor positions) compensate for belt stretch. Did you have similar X position deviations before (i.e., when using automatic calibration instead of manual measurements)?
Previously I didn’t test it as throughly as I have in this post, but it was pretty consistently -6mm off at 1200 from the origin on the X axis with the machine calibration settings. I tried entering in the manual measurements since @hendrik 's research in his post seemed to show that was more accurate.
If the drive motor was turning the spool directly, this would make sense to me; because the drive motor is driving a fixed-diameter cog, there must be other factors at play. Can you explain how the amount of belt on the spool affects force/current?
Im leaning towards something like this. After calibrating with the calibration force up high, the anchor positions were off, some by up to 20mm from my manual measurement but my machine has been performing well. I wonder if having the calibration force up high compensates for belt stretch by pulling them very tight. Would be curious for someone to try this on a vertical setup
If the drive motor was turning the spool directly, this would make sense to
me; because the drive motor is driving a fixed-diameter cog, there must be
other factors at play. Can you explain how the amount of belt on the spool
affects force/current?
when the belt wraps more than once around the spool, the 2nd layer is the
thickness of the belt further out from the center. when winding up the full
spool, this is over an inch of change between the beginning and end.
Seems to me like belt stretch is a product of force and higher force would only make the problem worse, unless there’s a different amount of force while running than with calibration.
Stretching is going to elongate the belts so if it stretches 1%, and the machine pulls 1000mm of belt in, that means it’s going to be 10mm short of what it thinks it’s done. This could be why the machine is always behind where it’s suppose to be since the direction of movement is where the most force is being applied and causing stretch.
Again, belt stretch seems like a pretty simple thing to measure, not sure why it hasn’t been done yet (right?) considering all the talk about it. Hopefully this week I’ll be able to mount a belt to something very rigid, put a load on it, and measure the stretch.
Laying at down flat made the biggest difference for me, which seems like a pretty good indiator that gravity is in play with the vertical accucracy issues…
question remains if Kyle used that. I don’t mean to pry, just curious.
