It does! A little jankily but the coordinates are correct.
1 Like
Excellent!! 
What is janky about it? Is one of the belts still too loose?
Im not totally convinced that there is some magic limit at 18 points. I think that maybe there was something about the way that point 18 was computed before given your input frame dimensions and whatnot that was tripping it up. (No idea what that would be yet). It might be worth trying more than 18 points, maybe even 9x9 or something close to the full pattern to see if the issue keeps happening.
What is the full pattern size?
Just the way it was moving looking at the arms. The bit could have been centered, but I wasnāt cutting. I plan on running some more point tests, but will be out of town for the weekend.
1 Like
Itās a made up number, but itās 9x11.
Giving this some thought it might be better to adjust the offset to something more relatively accurate based on the anchor points.
So if Iām thinking correctly
Maslow_calibration_offset_X: 609.6
Maslow_calibration_offset_Y: 787.4
1 Like
Yeah, those values look good to me. You might even want to go slightly larger so that you arenāt right on the edge of the sheet.
So I downgraded to 0.64.0 release and ran the calibration. The calibration completed.
Maslow_vertical: false
Maslow_calibration_offset: 790
Maslow_tlX: 2.6842595714664252
Maslow_tlY: 2780.6847670229113
Maslow_trX: 3647.0799008289955
Maslow_trY: 2819.868597821353
Maslow_blX: 0.0
Maslow_blY: 0.0
Maslow_brX: 3666.691905313304
Maslow_brY: 0.0
So I suppose itās time to cut something now.
3 Likes
So Iāve made things worse? Thatās not the direction that we want to move in
@pdw125 Can you see if this fixes the issue that you are seeing too?
Well @bar, something seems to be wrong. I jogged the machine after āhomingā. Homing defined as : pulling pins, retracting, extending all the way, and taking slack.
So sitting about -700mm in the X axis, there was a lot of slack on the bottom right. As far as I could tell it did move X- and no movement in the Y direction.
So I hit take slack again before defining home and sending a test file. I didnāt quite get the recording right away as on my phone if Iām out of the app the video record stops so Iām a little delayed. The gcode should have moved the machine roughly 200mm in both the x and y direction then start cutting a square pocket followed by a circle.
Despite taking up all the slack prior to running it did not do as expected, I suspect this is due to too much belt being released.
Test.nc (6.0 KB)
1 Like
Yes, thatās way too much belt being extended which does imply something is wrong with the calibration results.
It seems to think that the lower right anchor point is much closer than it really is. A quick way to test the calibration is to move the machine around using the arrow buttons which will confirm that as it is moving we are keeping good tension in all of the belts.
If the calibration process is working correctly, the thing to do might be to run it twice back to back and confirm that we find the same numbers for the anchor point locations.
Yes which I initially noticed extra slack
1 Like
Yeah, I think that the first thing we need to do is to figure that out.
This might be a silly question, but this is after entering the values found during the calibration process in the config file and restarting, right? Is it possible that the new values for the anchor points might not be in effect?
I hit restart fluidnc, but didnāt power cycle the machine.
1 Like
Letās try and see if a full power cycle fixes it?
Did full power cycle and downloaded the maslow.yaml to make sure. It was the same values from the completed configuration.
I picked another random point to start near the lower left. Belts went slack again. Definitely, didnāt cut a circle or a square lol.
1 Like
Yeah, I wouldnāt turn the router on until weāve got the belt tension figured out 
We should be able to move the machine around using the arrow buttons and see that the belt tension stays the same everywhere.
Is it possible to run the calibration process twice in a row and confirm that we are getting the same numbers each time? That should tell us if itās working normally
Iām try and sneak out tonight to run a few back to back.
1 Like
We used to have a big print out of that meme on the wall
It might be worth doing a smaller run with fewer points to make it go quicker
Even a 4x4 would be good feedback and those take just a few minutes although Iām not sure how consistent the results would be with so few data points
The more that I think about this the more that I think our issue is something outside the calibration process. If the process got all the way through and gave us an answer with a decent fitness, but then when we put those numbers into the config file we got extra slack in one belt, what does that tell us?
When the belts are retracted using āRetract Allā they will print out an offset number which will let us know how much different the zero position is from the last time they were extended. We would expect that number to be close to zero unless the machine was turned off with the belts extended.
Next time you run calibration, at the end can you retract the belts fully and check what that offset value is? Maybe there is something funky going on with the encoder position values?