Maslow Home Maslow Community Garden

Top-beam vertical deflection adjustment for calibration: (observed 2mm swing on beam tip)


#1

The purpose of this thread is to discuss the merits and drawbacks of adding a top-beam deflection adjustment into the Maslow firmware and GroundControl. This follows:

Actual measurements:
I used a laser line pointing at the beam tip, and saw a 2 mm vertical change on one beam tip (near motor position) when the sled moves from left to right. Same thing at all sled heights.The deflection apparently follows a simple load distribution equation. So the sled would be 2mm too low on the left, 1 mm too low on the center, then 2mm too low on the right.That means the sled position varies twice 1mm vertically across the workspace width due to this deflection. (For now, I assume left and right beam tip behave the same. I still have to confirm)

My sled is loaded with a Ridgid router, a standard Z axis motor and two bricks.
I have made my top beam reasonnably stiff: It’s made of a 10 feet steel strutt open forward with hard wood extensions to space gearbox shafts roughly 11.5 feet apart. The horizontal distance from gearbox shaft to the closest beam holding attachement is 19 inches.

What about top beam bow?
From a “no sled load” condition, up to a “sled at the workspace top line”, and using a tape measure, I see no change in the distance between gearbox shafts. And I can place my tape tightly on the sprockets. So for now I concentrate on the vertical deflection.

I might be wrong, but the total combined top beam “flex and twist” creating this deflection is likely to be larger on Maslow cnc frames using plain 2x4 birch wood top beams.
I consider this 1mm vertical error a significant value. (Could it confuse the GC calibration process based on optimisations?)
One solution to include this beam deflection would be to correct the true motors vertical positions according to the sled weight ratio they carry as a result of the sled horizontal position. This would insert an adjustment on the motor vertical position in kinnematics.cpp.

The one required calibration value is to measure the vertical deflection when the sled moves from one workspace side edge to the other. Then extrapolate the value for the sled position right under the motor horizontal position.
How this value would be measured may be simplified, but a cheap laser line and a pen worked quite well for me.

I’m currently trying this new calculation on my github branch of the firmware. See documentation folder for diagrams ( beam_deformation_model.svg )

To establish the benefit of that correction, could volunteers from the community share measurements of their beam tip vertical deflection (mm) when their sled goes from left side to right side of the workspace?

Tx.


#2

so you have a 11.5’ top beam with two(??) supports 100" apart

is your unistrut mounted open side up or open side forward/back? (can you easily
rotate it to see if there is a difference?)

can you try fastening anything (say a 2x4) to the bottom of the unistrut between
the leg supports to see if that changes the flex?

I’m trying to figure out if the flex is happening across the entire width of the
beam (bowing it down) or only on the portion of the beam past the support point.

Thanks for testing this.

David Lang


#3

The unistrut is held in three places: center and near each end. I can’t rotate it without disassembling the whole thing apart.

It does not really matter if it flexes down: What I assume is that every frame will have some sort of flex depending on the design and material, and the Maslow cnc control could account for that in the calibration.

Regards,


#4

Isn’t this a mechanical problem? The curse of a software fix is that in the future one can’t be sure that it’s still accurate or needs to be recalibrated. Bracing that prevents the flex once and for all seems a better solution to me.


#5

Remember, we are aiming for an accuracy of 0.5mm, so even things like this may
end up mattering.

I suspect that this is like chain sag, it can be reduces, but never eliminated
completely.

That makes it something to measure and account for. Hard-coding a correction
factor in is a very bad idea, but measuring and correcting means that if it’s
not needed, it will be zero.

It may be that a single unistrut is not stiff enough and we need to double it
up, add something else as a stiffener or something along those lines.

That said, so far this is an error in the 2mm range (so ± 1mm), and we are
fighting errors that are much bigger right now (along with the problem of
knowing what the errors actually are)

David Lang