Calibration attempts

[James_Presnail]

So I tried a couple things tonight.

First thing, I reflashed the firmware via USB to rule any issues with that out. I started with 1.23 and I set my maslow yaml with my specific variables (40mm belt end and my anchor point z offsets different by 5mm because my belt ends are thicker, so the belt sits 5mm higher off the ground)

I brought out my laser level, and squared the Bl TL and BR corners (see pic). I bought a tape measure in metric, and measured very precisely my anchor points, and put them in the maslow YAML as well.

kinematics:
MaslowKinematics:
tlX: 24.000000
tlY: 3769.000000
tlZ: 95.000000
trX: 4353.000000
trY: 3773.000000
trZ: 51.000000
blX: 0.000000
blY: 0.000000
blZ: 29.000000
brX: 4372.000000
brY: 0.000000
brZ: 73.000000
beltEndExtension: 40.000000
armLength: 123.400002
beltToothSpacing: 1.998800
encoderTeeth: 22.000000
maxSegmentLength: 5.000000
fixedZ: false

1st 1.23 calibration attempt failed

I then ran calibration, and the calibration failed. Attached is serial log called 1st attempt serial log failed, and video attached called first 1.23 calibration attempt failed.

Then, since it failed, i tried Bars new firmware with the belt stretch, and it failed the same too. video attached is (2nd 1.23 dirty? belt stretch attempt failed)

The belts never travel tight. (but they did when i used 1.17 firmware and a smaller grid)

For Bars new firmware, this was my edited yaml kinematics

kinematics:
MaslowKinematics:
tlX: 24.000000
tlY: 3769.000000
tlZ: 95.000000
trX: 4353.000000
trY: 3773.000000
trZ: 51.000000
blX: 0.000000
blY: 0.000000
blZ: 29.000000
brX: 4372.000000
brY: 0.000000
brZ: 73.000000
beltEndExtension: 40.000000
armLength: 123.400002
beltAxialStiffness: 178900.000000
sledWeight: 86.328003
calibrationPullForce: 156.960007
beltToothSpacing: 1.998800
encoderTeeth: 22.000000
maxSegmentLength: 5.000000
fixedZ: false

2nd 1.23 dirty belt stretch attempt failed

2nd serial 1.23 with belt stretch failed calibration.log (16.5 KB)

1st attempt 1.23 calibraton failed serial.log (18.3 KB)

[ian_ab]

I am sure you have checked this, I had a similar result when I had not set the Z heights corresponding to the order of the arms. As a desperate suggestion, try setting the Z heights in the yaml file to 10, ignoring the actual height. See if it fails at the same point.
As the belt lengths are so long on your setup, I wonder if putting a rigid extension on each arm might reduce the effects of belt stretch. I put a 1 metre aluminium extension on each of the belts on mine (sorry I didn’t go to 1.5 metres).

[bar]

If you already have excellent measurements like that you can also skip the process entirely and just enter them manually. I made a little tool to help with that here:

Maslow Manual Anchor Locator

[bar]

Looking at the data from the failed runs It is pretty clear that those top right and bottom left corners are for sure the issue area…I wonder why that could be?

There are two possibilities, either something is going on physically to make the measurements there inaccurate, ore there is something going on in the software to throw off the calculations in a way that messes up those corners

[James_Presnail]

I think it is worth noting.. that in my corners, the “corner Measurement” it doesn’t just move ‘linear’ly’ in between taking a measurement. For instance, in the bottom left red measurements above, point #38 is not on a corner, so the maslow travels down the X axis direction for a little bit, then goes up the Y axis a little bit to get to the #39 measurement. I’ve found that odd. It doesn’t do that in 1.17. And it does that in most of my corners there.

[James_Presnail]

Yes I know.. but I’m just trying to help. And I enjoy the trouble shoot.

[bar]

@James_Presnail

I’ve found that odd

Yeah, I think that is a great observation, that is weird.

One possibility that comes to mind is maybe 1.17 and the latest version are measuring the points in different places. Maybe the new version is pushing out closer to the anchor points, does that seem like it might be happening?

@James_Presnail

Yes I know.. but I’m just trying to help. And I enjoy the trouble shoot.

I really appreciate that, it is super super helpful for tracking something like this down that I can’t reproduce yet

[James_Presnail]

Well… I really think tis software not hardware. (unless my PCB/ESP32 can’t handle the new computations on board)

Today running 1.23 (with belt stretch feature) It passed generally passed, with not great anchor locations compared to my measurements. Very slack belts as it moved around points… so slack that they were completely on the ground (not in the air), and also the corners didnt get measured, it kinda travels on both axis’ and doesn’t measure the corners… And then I got a failed 1.23 when something werid happened and belts didn’t retract… by trying different things (changing work space and calibration grid size, number of measurement points, retraction force, z offsets to 10(ians suggestion)… anyway i never got a good sense it was calibrating properly. It doesnt travel around the waypoints with tight belts or measure the corners…

So i then reverted to 1.17 to see if it was potentially hardware, but then it calibrated smoothly. All belts are under good tension during travel, and the corners are measured nicely. But i dont love the 1.17 measurements as I feel good about the manual measurements. jpeg attached

So I truly think its software. But not sure where to look/ help. Here are some serial logs

Im still not sure why it fails on the larger workspace

1.23 1000 square calibration with stretch 1200 retracton force.log (26.6 KB)

1.23 800 square smaller than workspace test z offsets setback to actual.log (17.4 KB)

1.17 instant success belts tight when calibrating always..log (20.7 KB)

1.23 1000 square failed with belt stretch 750 retraction.log (21.8 KB)

[James_Presnail]

also interesting that I put all the measurement data from 1.23 into the Maslow Calibration Data Parser and the grid is so wonky… and then if you put the data from 1.17 into the parser, it “looks good”

1.17

VS

[James_Presnail]

The 1.17 grid pattern also look parrallel to the x and y axis… but the 1.23 looks rotated a few degrees “clockwise”

[bar]

Yeah that is super weird. I agree that it’s 100% a software thing because you can get good results by going back to 1.17

It seems to me like the issue here has to do with how we are taking the measurements more than about the math is being done on those measurements once we have them.

At right around 8:48 in the first video you can see a really good example of the machine taking a “measurement” where it doesn’t pull the lower left belt tight at all which means that measurement is going to be totally wrong (like using a tape measure without pulling it tight)…the question is why could that be happening and what is different vs 1.17.

Do you always see the same behavior even when starting fresh with a new maslow.yaml file? What is happening with that file when you are switching versions, are you replacing it or keeping the same one for both?

[ian_ab]

When I ran the new version with LM it also had slack trailing belts on the last iteration, before tightening them prior to moving on. Not slack enough to cause a problem, but the trailing belts sagged down.

[James_Presnail]

I always see the same behavior with 1.23.
When changing firmware, I always delete the maslow.yaml from the file folder in fluid NC and then I upload the appropriate one and then tweak any values that I need to edit. I also always do the same and replace the appropriate index file.

I was thinking about adding a new anchor in my top left… adding a new anchor -30mm on the x axis so that my frame would be more square. And when I said that out loud, I realized that is possibly why the coordinated grid on the 1.23 parser data shows the grid rotated clockwise, because the left side waypoints are parallel to a line that is drawn between BL and TL anchors… But in the 1.17 parser grid view i showed in the picture, the grid is parallel to a 90 degree angle through the BL anchor.

AM I making sense?

[ian_ab]

@James_Presnail

I always delete the maslow.yaml from the file folder in fluid NC

It is possible to have multiple yaml files, you just need to change the name in Flash settings and restart FluidNC e.g.

[wouldchuck]

I have some time this week to run callibrations on different frame geometries. is there a particular version that would be helpful to get data from at the moment?

[bar]

I would love feedback on this guy: Interstitial Firmware Releases - #973 by bar

[wouldchuck]

Uploaded that firmware. here are my measurements and the run log my measurements may not be perfect but should be close for checking. No visible frame movement.

Maslow-serial(40).log (26.1 KB) Wrote the diagonal distance down wrong it should be 4894 not 2894

[wouldchuck]

Should I be clearing the yaml every time?

[wouldchuck]

Its definitely leaving belts slack as it measures near the edges. and retract all is leaving one or two out every time. if i keep running it eventually it seems to get them all. There is no tension on the ones it is not retracting.

I’m going to run this calibration again. it got hooked on a corner for a bit. But it won’t retract any more. Going to cycle the power and try again.

Maslow-serial(42).log (31.8 KB)

[wouldchuck]

still won’t retract after restarting, extending belts for a bit then cycling power retracting again. the motor is connected because it worked for extending.

Maslow-serial(43).log (4.0 KB)

I extended all then retracted and this time it left out a different one and won’t bring that back. sigh. I have tried stopping, it with both stop buttons, restarting both hard and soft. Weird. Going to reload the firmware and try again.
Ok got them to all retract after several rounds of extend all and retract.