The square was drawn at 100x100. A little less than a mm difference between width and height. The 90mm circle is ovaled by about the same which is visible if I turn the circle 90 degrees
I’ve seen in your hose thread that you have a horizontal frame, so that’s similar to my setup. I also have a small dimensional difference between x and y. Could you please measure:
the dimensions of the square (x and y)
the small and large diameter of the circle
are the small and large diameter of the circle aligned with x or y, or is the oval rotated? In the picture it seems to be aligned with an axis, correct?
So the absolute difference between x and y is larger in the big square than in the small square. Do you happen to know how if this in fact is a scaling issue rather than an offset? Or if results are better in the center of your work area; after all, this cut was right in the corner of the green area (Anchor Point Layout Simulator)?
The calibration process reports some “fitness” value when it finishes. The higher, the better. But at the end of the day what counts is whether you get accurate cuts. I ended up ignoring the automatic calibration and measured the frame myself. Now I’m curious to see what other people can achieve.
There is some weirdness for sure. Why is the difference on the circle approximately 3mm vs 1mm for the large square?
Is it a problem with the machine or the drawing? IE maybe the segment count on the circle wasn’t high enough.
Did the material move around on the spill board? I didn’t screw/clamp it down, it’s just jammed in between the over run boards.
I wasn’t really testing ultimate accuracy with this cut, just seeing if I could actually cut something out. I’ve had a heck of a time getting through the calibration process and then I had to do it twice because my initial anchors were visibly flexing.
This project will be back burnered for a couple weeks now but I’ll try to control the potential issues and do multiple cuts in different areas to compile some useful data when I can get back to it.
The circle question is a good one and I don’t have an answer. I’d love to understand it. My circles are also worse than my squares, but the large/small diameter axes are diagonal in x/y. Since the g-code uses G2 for the circles, I don’t believe the error is due to segment interpolation. My best guess is that Maslow is flexing and I’d like to stiffen it, but that’ll take several weeks.
Initially I had a scaling error with different scale factors in x and y, but that went away after I discarded the automatic calibration and measured the anchor point locations manually (described in the thread I linked to in my first reply). What I see now seems to be related to flex and backlash (I think!).
Maybe we have slight variances on the gear in the 4 belts. There is probably a way to isolate which direction and then which belts are moving more . But I can’t picture it in my mind.
In that thread the solution is “There was a gear just a little loosed in x axis that caused the whole problem.”, i.e. plain old backlash.
A belt pitch error would show as scaling and belt tension issue, which I do observe to some degree (about 1/1000). The exact diameter of the encoder pulley doesn’t matter, as long as the belt moves it without backlash, because the machine counts (fractions of) revolutions and knows how many teeth the pulley has. Motor gear revolutions are irrelevant, because the effective spool diameter changes all the time and therefore Maslow has to rely on the encoder feedback.
I’m curious if it would be worth rotating the Maslow 90deg. Basically set it up in letter layout instead of landscape. Then see if the oval cut orientation also rotates with Maslow or stays with long orientation.
Would that tell us if it’s a math issue with orientation or a hardware issue?
My frame is square so I can try that pretty easy. However it would be sensitive to either not exact same anchor points or a calibration change. So the results might not be meaningful.
Hmm interesting a square frame. I missed that detail initially , might still be worth a try, maybe someone else will see something…
I would recommend keeping a copy of your current yaml file and then run a new calibration after rotation of anchor. They try the circle cut not changing much else in the program.
I think the important would be to know if the oval keeps orientation with Maslow or with frame.
What about the ‘centeredness’ of the encoder magnet in the little plastic thingy. There is quite a bit of room for play, so perhaps the position that the magnet is glued throws off the readings ever so slightly.
What about the ‘centeredness’ of the encoder magnet in the little plastic
thingy. There is quite a bit of room for play, so perhaps the position that
the magnet is glued throws off the readings ever so slightly.
on my kit there was very little play, either the magnet in the plastic piece or
the plastic piece in the bearings.
Like David says: The fit of the magnet in the pulley and the pulley in the bearings in my kit was fairly tight. Of course there might still be an offset and there are other factors contributing to this, too, like PCB placement or even slight shifting of the sensor on the PCB during soldering. So let’s assume a 20-teeth pulley (I don’t know the actual size, but it’s the right ballpark). Then a 2.5° angular error translates into a periodic 0.28mm belt extension error.
Note that this is not cumulative, contrary to what ChatGPT suggests, because we know that with each full revolution of the pulley the belt is moved in or out by a certain number of teeth.
How large the periodic encoder error is, can be determined by @bar while extending or retracting the belts. With constant motor speed he should see a periodic modulation on the extended belt length with a cyclic duration of n*2mm where n is the number of teeth on the pulleys. In fact, once this modulation is measured, it could be corrected for in software and the correction values (amplitude and phase shift) stored in the maslow.yaml file.
Nevertheless, I believe that other factors contribute more to the cut accuracy. Otherwise, we’d see wobbly straight lines all over the place.
I played around with this a fair bit early on, but I found it didn’t make much difference.
What I was trying to do was to create a linearization function which would run the motor at a constant speed and then monitor the encoder position. If the motor is running at a constant speed but there is a periodic variation in the speed measured by the encoder then we know the magnet is misaligned and we can compute by how much and in which direction and correct for it.
In my testing I found that it was a very very small variation and not worth the extra complexity of adding a step to the calibration process.
