Everything's better under the C (a quick poke at the frame flex value)

Take this with a big pinch of salt as I had to do a bit of extrapolation, but it might yield some useful insight later. It was triggered by some thoughts around flex/stretch and me realising I have too much friction in my arms (similar to others have posted), which i’m looking at separately.

Random thought that occurred to me:

  • If we group all the flex/stretch together (belts, frame, Maslow unit) and just consider it ‘system flex’.
  • It’s probably all linear flex, or pretty close to it.
  • If that’s true, we can model it as y = mx + c
  • If so - we should be able to measure it, even if we don’t know the units properly.
  • What does c tell us? Is it useful?

Supposition:

  • If we can graph stretch/flex at different motor currents, we can extrapolate from the data and find c at 0.
  • Stretch is probably not 0 at 0 (which it should be(?) in a linear system with no friction/mechanical loss).
  • The magnitude of c might give an indication of how much friction / how bound up the arms are - possibly a better measure than ‘Does retraction start to happen at force 600/900/1200?’

Now, impetuous person I am, I just went and ran calibration a few times at different forces to get the ‘Frame Flex’ value and looked at what the code actually does after :laughing:

It’s one of the first things calibration does, and I stopped calibration after except the first time. That came back to bite me (more on that later).

Results:

force TL-BR TR-BL
600 5.276 4.185
900 3.669 4.829
1200 3.911 4.961
1500 6.17 2.526
1800 3.64 3.154

These are my raw results. I’m not sure what happened at force 1500, but I did repeat and got the same effect, so that’s interesting in itself.

A quick graph:

Yep, that’s interesting, clearly I had no idea what Frame Flex actually does - the graph looks like it vaguely trends downward but has an aberration at 1500.

Lets look at the code:

From (FluidNC/FluidNC/src/Maslow/Calibration.cpp at Maslow-Main · BarbourSmith/FluidNC · GitHub):

    if(measureFlex){
        howHardToPull = calibrationCurrentThreshold + 500;
    }

and

            if(measureFlex){
                float newLenTLBR = measurements[0][0] + measurements[0][3];
                float newLenTRBL = measurements[0][1] + measurements[0][2];

                float origLenTLBR = calibration_data[0][0] + calibration_data[0][3];
                float origLenTRBL = calibration_data[0][1] + calibration_data[0][2];

                float diffTLBR = abs(newLenTLBR - origLenTLBR);
                float diffTRBL = abs(newLenTRBL - origLenTRBL);

                log_info("Flex measurement: TLBR: " << diffTLBR << " TRBL: " << diffTRBL);

Ok, so the value printed out is the difference in belt lengths with +500 added onto the calibration value. Makes sense - my belt lengths are ~1845 x 2 = 3600 (x 2 because it’s 2 belts), so about 0.1% system stretch (I think - assuming Frame Flex of 5 is 5mm).

Now that might be interesting in itself - arguably it could be showing me my whole system is super stable and has very little flex. It could be telling me I only have belt stretch, or I have no belt stretch. Or (most likely) it might be telling me a lot of the force is being used to turn the reels.

Wild extrapolation

Ok, this is where we get pinch-of-salt-y.
What I actually want is the calibration to measure the belt lengths at the centre point multiple times and bump up the force each time, and dump those raw values out. Maybe in time that can be added.

But for now, I do actually know some data and can fudge some extrapolation. I did run the initial calibration long enough to know the belt lengths at 600 are ~1845, and our first data point is at 1100, and giving us a length of ~1849 (as it tells us the total was ~ +4.5). So we can guess the base length at 1200 was 1850, and work out the value for 1700, and so on.

Dave’s Dodgy Data:
With that extrapolation, that would give us:

Force Belt Length
600 1845
1200 1850
1800 1853
2300 1856

Graphed to:

Which (remembering our healthy pinch of salt) gives us a belt length at 0 force of ~1842 - or 3684.

Except I know from measuring that really it’s ~3710-3720.

I have measured values from another calibration that give the expected length at 900 as ~3698 - or 1849 - which matches this graph, so it’s plausible - though again, big grain of salt.

Which I think matches with my supposition that force is being lost as something other than stretch - primarily as mechanical loss in turning the reels.

Next:
If i had loads of time i’d make the code dump out more values and re-test with sticky reels, but the primary purpose (other than dumping my thoughts / first try) was to get a before snapshot.

I’m off to rebuild my Maslow with some sanded-to-free-spinning reels (and i’l post my experiences with that separately).

I’ll re-run this experiment with those, and we’ll see what we see :person_shrugging:

3 Likes

This is an excellent line of exploration :smiley:

2 Likes

I have tools to get 0.001" class measurements out to maybe 48" (2 GIANT calipers). Maybe I could make a couple of known blocks and get out to 2+ meters.

Three classes of measurements:

Constant belt end to spool
Run belt inside a strong aluminum tube pushing 2 meters long (I have some on hand). Anchor belt at the far end, install a loading block on the other end to firm up the location of the spool end. Using the motor itself, check and see what the encoder readings say at a range of tensions. Ideally go all the way from slack to full tight back down to slack and repeat a few times.

Variable tension, variable exposed belt
Using a set of known length load carrying objects that are MUCH stiffer than the belt, take a set of data as above, but with a range of exposed belt lengths.

Constant tension, variable exposed belt
Using calipers and blocks and a tool to apply a specific force, run out a set of belt lengths and measure them precisely at a constant tension. Hanging Maslow is a reasonable way to get constant tension.

The spring constant of the system is going to be comprised of a handful of parts:

  1. Exposed belt stretch (spring constant is related to the exposed belt)
  2. Belt stretch on spool (only a few turns involved, complex friction issues)
  3. Belt pack compression (tied into belt stretch)
  4. Flex of spool

My engineering gut says that if we spool under semi-constant tension (like in actual operation) then #2 becomes a non-issue. However, if we spool up under low/varying tension, there’s going to be a variable and history-related noodling around!

#4 feels like its probably small, but it should be linear and calibrateable.

If we can keep the tension reasonably constant we can cancel out #4 for sure. Maybe a small factor due to arm angles might still factor in.

Belt pack compression feels like it would be small and likely made constant with uniform tension.

#1 is the key factor here, IF we spool the belts on at uniform tension!

If we want to get the spooling tension/wrapping/packing out of the equation, we need to program the Maslow to do a big rectangle over the whole operating area. One full trip around at constant tension will get all four spools to an near ideal state. This might be combined with a “check the planned cut area” step :wink:

Thoughts? Tomatoes? CNC routed tomatoes?

1 Like

One factor is that we are measuring the belt length using the encoder roller which is AFTER the spool on the train of things pulling on other things so we can ignore any stretch or things like that on the spool side. We just care about the section of belt from the roller to the anchor point (and the anchor point itself).

On the other side of the roller we do care bout the machine being rigid and not flexing under force which is a contributing factor

1 Like

Good point! I was forgetting the metrology location! That helps the factors quite a bit!

1 Like

I’ll reply properly tomorrow as it’s late here now, but I gathered some nice data post-smoothing the spools that shows pretty linear scaling with motor force.

But I also realised my wild speculation was the wrong way round - I was adding the difference in belt lengths, I should have been taking it away :joy: Shows you how wildly extrapolating I was that that wasn’t noticable… The measured belt length should be getting shorter as the actual belt stretches.

I wonder if I / we need to talk in something like unstretched and stretched belt length or something to keep the nomenclature sane. :thinking:

1 Like

Rod wrote:

My engineering gut says that if we spool under semi-constant tension (like in actual operation) then #2 becomes a non-issue. However, if we spool up under low/varying tension, there’s going to be a variable and history-related noodling around!

#4 feels like its probably small, but it should be linear and calibrateable.

If we can keep the tension reasonably constant we can cancel out #4 for sure. Maybe a small factor due to arm angles might still factor in.

Belt pack compression feels like it would be small and likely made constant with uniform tension.

#1 is the key factor here, IF we spool the belts on at uniform tension!

If we want to get the spooling tension/wrapping/packing out of the equation,
we need to program the Maslow to do a big rectangle over the whole operating
area. One full trip around at constant tension will get all four spools to an
near ideal state. This might be combined with a “check the planned cut area”
step :wink:

this may be harder to do than you think, not all workpieces are a full 4x8 sheet

also, even doing a full rectangle will leave a significant portion of the belt
on the spool untouched.

David Lang

Ok, so, I managed a much better go at this after redoing all my arms/spools.

Basic initial results - the frame flex at each force (so how much shorter the belt is after applying +500 force)

Initial force TL-BR TR-BL
600 5.037 4.274
900 4.572 4.035
1200 3.09 3.047
1500 4.376 2.625
1800 4.086 2.7

Quick graph

Vaguely similar to above.

More interesting - this time round I let it run the initial calibrations - meaning I had the first point, which is pretty close to centre:

force bl br tr tl force tl-br tr-bl
600 1846.81 1864.91 1852.81 1851.2 600 3716.11 3699.62
900 1844.05 1863.22 1853.28 1853.14 900 3716.36 3697.33
1200 1842.71 1860.34 1853.19 1853.35 1200 3713.69 3695.9
1500 1839.95 1859.23 1853.17 1853.36 1500 3712.59 3693.12
1800 1837.22 1857.36 1853.33 1853.38 1800 3710.74 3690.55

Looks like some solid system flex with force:

And for reference, here’s my laser measured frame details, plugged into:
http://lang.hm/maslow/maslow4_manual_calibration_simple.html
(thanks @dlang - saved me writing the same thing myself :smiley: )

Measurements
Bottom: 2910
Top: 2906
Left: 2301
Right: 2300
Bottom Left to Top Right: 3700
Top Left to Bottom Right: 3716
Calculated tl to br: 3715.85 Error= 0.15

Anchor locations:
Maslow_blX: 0
Maslow_blY: 0
Maslow_brX: 2910
Maslow_brY: 0
Maslow_tlX: -7.700853013121105
Maslow_tlY: 2300.9871135803587
Maslow_trX: 2898.298969072165
Maslow_trY: 2299.9702358672434

This is the right way round compared to the one above - but still the useful thing is what is c (what is the projected length at 0 force). And yeah, close but slightly above the real value - whichi’m pretty sure implies there’s still a small amount of friction in the system / mechanical loss (which there should be).

Ok, but we also have the flexed measurements so we can work out the lengths after we up the force:

force TL-BR TR-BL bl br tr tl force tl-br tr-bl force tl-br tr-bl
600 5.037 4.274 1846.81 1864.91 1852.81 1851.2 600 3716.11 3699.62 1100 3711.073 3695.346
900 4.572 4.035 1844.05 1863.22 1853.28 1853.14 900 3716.36 3697.33 1400 3711.788 3693.295
1200 3.09 3.047 1842.71 1860.34 1853.19 1853.35 1200 3713.69 3695.9 1700 3710.6 3692.853
1500 4.376 2.625 1839.95 1859.23 1853.17 1853.36 1500 3712.59 3693.12 2000 3708.214 3690.495
1800 4.086 2.7 1837.22 1857.36 1853.33 1853.38 1800 3710.74 3690.55 2300 3706.654 3687.85

And graph those too:

And put them all on one plot to compare:

Which is quite a nice graph I think!

Now I did have a go at extrapolating the pre-smoothing data, and it does appear to have a (slightly) different slope / m:

But it’s a completely unsafe bit of data to use because it really was suuuuper extrapolated - i’m kicking myself a bit because if i’d realised it wouldn’t have taken me much longer to capture originally :confused:

Speculation

So what might we take from this / do with this?

  • If you knew the frame size, the projected value at 0 force would probably give you a good idea of how much friction was in your system, but that’s a bit chicken and egg.
  • As it is, you could probably generate reasonable starting co-ordinates from the expected 0-force values - it won’t be right, but it should be in the right ball park.
  • I’m sure there’s info you can gain from the slope, we just need more than one data point.

What could be next steps

  • It would be good if the unit manoeuvred itself until it had the belts as close to even tl-br and tr-bl, and then measured the belt lengths at 600/800/1000/1200/1400/1600/1800 automatically - we could gather more data from different devices in different states.
  • I have a suspicion that you’d get more data and be able to draw more conclusions if you repeated the measurements in a cross - so travel tl-br and at a couple of points measure the tl-br belt length (probably with tr-bl belts loose) and vice-versa.
  • And I still think there might be a case for measuring at multiple tensions at each point in the main calibration, but that’s the most speculative and might not actually tell you much.
1 Like

One thing I did consider as a future avenue / I have pondered before but is outside the scope of what you’d expect a user to do:

Some of the belt could be replaced with a length of 3/4/5mm dyneema, with the length-past-retraction value bumped up. At the kind of forces the Maslow produces, stretch would be essentially 0 I think.

As long as you retained enough toothed belt for the cutting area, it would actually make a lot of sense to do it permanently, especially on large installations. But the cost / risk of catching on the frame / etc means it wouldn’t do it in production.

1 Like

There was an idea thrown out to add metal tube extension between anchor point and belt end to reduce amount of exposed belt and lessen belt stretch. I don’t know if anyone tried. Maybe simple plywood extensions would be enough for a test.

Dano

Ohhhhhh, was that one of the things that was suggested by / you were suggesting @WeldingRod - apologies, I think I misunderstood.

A fixed piece would be interesting, if a little unwieldy :thinking: TBH dyneema isn’t that expensive, I’ll have a dig around and see what I have in my box of kite/windsurf stuff anyway.

Dave wrote:

What could be next steps

  • It would be good if the unit manoeuvred itself until it had the belts as
    close to even tl-br and tr-bl, and then measured the belt lengths at
    600/800/1000/1200/1400/1600/1800 automatically - we could gather more data
    from different devices in different states.
  • I have a suspicion that you’d get more data and be able to draw more
    conclusions if you repeated the measurements in a cross - so travel tl-br and
    at a couple of points measure the tl-br belt length (probably with tr-bl belts
    loose) and vice-versa.

one thing to remember is that with nearly straight lines, you have a very hard
time pulling them completely straight. it only takes a small amount of force to
move a considerable distance (applying a lot of force on the two nearly-straight
belts)

I think it’s worth trying, but see what happens when you are off a bit.

also, think about what will happen when you aren’t close to a perfect rectangle
(say, if you were to offset one of the top anchors by a foot)

  • And I still think there might be a case for measuring at multiple tensions
    at each point in the main calibration, but that’s the most speculative and
    might not actually tell you much.

but it’s worth trying.

I think the big takeaway is that we need an easier way to define a calibration
routine than to have it hard-coded in C

we need to be able to easily move around and then send a ‘report belt lengths’
request.

I think it can be done with the available commands, but it’s hard

David Lang

It is currently possible to define extra length of the anchor, but it assumes
that the anchor is stiff and does not flex in the Z direction. We would need to
add an additional length variable (and probably for each arm) that is allowed to
flex in Z.

This doesn’t make a big difference when you are a long way from the anchor, but
when you get close, it makes a noticable difference (~5mm when you are ~600mm
from the anchor with stock arm and anchor IIRC)

David Lang

Dano wrote:

There was an idea thrown out to add metal tube extension between anchor point
and belt end to reduce amount of exposed belt and lessen belt stretch. I
don’t know if anyone tried. Maybe simple plywood extensions would be enough
for a test.

with the current variables, make sure it doesn’t flex in the Z direction and is
the same on all 4 arms and you can just change the endextension value

David Lang

To check my understanding:

Say my original anchor point has Z-offset 0mm. The assumption in the code is both ends of the extension are at Z-Offset 0mm? I presume because the plastic belt ends aren’t expected to be able to rotate in Z?

Ah, it’s true - I wasn’t thinking too much about what happens if the attachment points are wildly out of square, intensionally or not :thinking:

So the current code expects the extensions stay parallel to the work piece but still pivot in the xy plane? Good reminder.

Dano

Yes, both the end fitting length and the spool arm length are assumed to pivot. I doubt they are assumed to pivot in Z…

My thought on using a metal tube was just to help us understand belt stretch, as it would give a length where we KNEW the anchors weren’t moving.

I could see making some belt extenders, but its going to be a bit tricky to avoid having more slop in the connections that the improvement in stretch they gain… Plus they may be heavy enough to deflect the belt down some and add yet another factor of weirdness.

Dano wrote:

So the current code expects the extensions stay parallel to the work piece but still pivot in the xy plane? Good reminder.

That is correct. think about the current belt ends.

it would not be a hard job to add an additional variable to the calculation to
allow for an extention that can pivot in the Z plane, but my question would be
if it’s enough to have a single value, or if we should make it an array in case
you have different length extensions on differnt arms (say you are using
extensions to reach walls or something like that an you need different length
extensions due to the building)

David Lang

Dave wrote:

Say my original anchor point has Z-offset 0mm. The assumption in the code is
both ends of the extension are at Z-Offset 0mm? I presume because the plastic
belt ends aren’t expected to be able to rotate in Z?

that is correct. the initial math did a triangle from the anchor to the center
of the router at the level of the arm, and I showed that with a reasonable Z
offset and 600mm on the xy plane, the fact that the anchow end and the arm don’t
flex like that resulted in an error of ~5mm when all the Z difference was in the
belt length rather than anchor to bit length (I may be off slightly on the exact
numbers, but it was significant enough to fix)

David Lang

1 Like