Top Beam Tilt Correction Pull-Request

Software
,
1

The purpose of this thread is to discuss the merits and drawbacks of adding top-beam-tilt correction into the Maslow firmware and GroundControl. At @bar’s request we are moving discussion here (instead of GitHub) so that more of the community can participate in discussing this feature.

These changes are in the following PRs

If you feel strongly about these changes, please go vote for it one way or another with either a :+1: or :-1: reaction to @MaslowCommunityGardenRobot’s comment on the Pull Request.

1 Like
2

At this point, we aren’t sure how big the problem is that we are trying to fix
here, and it’s not clear if this fix is for the entire machine not being level
or the beam being crooked compared to the workpiece.

so I really don’t think it should go in as-is

David Lang

3

So on the one one hand it seems like the rewards are small for putting in tilt compensation, but on the other hand is there any risk? It seems to me like the biggest risk would be adding another variable which could confuse folks during the already strenuous calibration process.

On the other hand if we can prove that there is a benefit to having tilt compensation I am all for it!

1 Like
4

it’s not just the complication of the calibration process, but also the
complication of the math in the kinematics calculations. We know we have
problems there (sag and stretch if nothing else) so I think we need to keep that
as simple as possible for now.

After we fix the sag/stretch, then adding this back in would be good. I’m only
arguing against as a shorter term item.

David Lang

1 Like
5

There’s confusion about what this setting corrects - top beam out of square with respect to workarea rectangle, or the whole not level. There hasn’t been any testing to show how important leveling the top bar is and what the scale of that effect is.
After there is proof that tilt correction provides a benefit is the time to consider adding it. For now we have more than enough confusion with settings and calibration.

1 Like
6

if you dont know what you are trying to fix and cant measure it… then… yah…

seems like a ripe feature to write a test for (sorry it is the software eng manager in me coming out).

2 Likes
7

I think this is somewhat mitigated by marking it as ‘Experimental’ in GroundControl.

My understanding is that this change corrects two things: 1) beam out of square with respect to the work area and 2) beam not perfectly perpendicular to a vertical sprocket when measuring out chains. I think #1 will be important to some people who want to use their machine edge-to-edge. I don’t have a sense of how big of a deal #2 is. This patch does not correct for the potential for asymmetrical chain sag due to the entire frame being out of level.

Please write tests! Would be great to get some tests in the codebase. I’ve used Catch before to write tests for Arduino projects.

8

I looked at the files that were touched… its hard to write a test for the feature as is… all (most?) of the functions are void methods that work by messing with global (?) state, rather than returning their computed values. Im not criticizing the code (prob better than I could write), but it does make effectively testing (and reasoning about the codebase) much much more difficult.

If the function was a pure function - then writing a test for this should be as simple as plugging in the happy/not so happy path values with known output values and doing a simple assert.

9

I don’t care what it looks like in GroundControl, I am worried about what this
does to our efforts to analyze, cleanup, and improve the kinematics calculations
in the firmware.

David Lang

10

part of the problem is that we don’t know what the right output values are :-/

David Lang

1 Like
11

the solution to this is to have the machine make a cut to make the work area
square to the beam.

arrange to have support for the sled around whatever it is your workpiece sites
on, and then cut those supports so that they are square to the top beam.

David Lang

12

Yeah to test we’d need to do some refactoring for sure.

This is clever! But also it assumes your calibration values are correct enough to make a square/level cut, which seems to not be a given.

13

Please be sure to register your vote in the Firmware PR as well…

1 Like
14

What it does is change the coordinates for the motors. Right now, the X coordinate for the motor equals +/- 1/2 the distance between motors and the Y coordinate equals the motorYoffset. Instead of calculating this every single time triangularInverse is run (which is a great many times), it precomputes the X and Y coordinates for each motor and while doing so, modifies the X and Y coordinates based upon a tilt value. Adding a tilt alows results the X coordinates being brought closer to center (equals the cosine of the tilt value times 1/2 the distance between motors) and it changes (raises/lowers) the Y values of the motors by a distance equal to the sine of the tilt value times 1/2 the distance between motors.

This simplifies the math that the Arduino has to do because it’s not dividing distance between motors by 2 every time it executes triangularInverse.

I claim that the advantage of this method is that even though the work piece might be parallel with the top beam, the affect of the top beam being tilted will result in a distortion of the shape being cut. That is, you are more likely to get a square square doing this, even though the square that’s cut might be rotated relative to the plywood by an amount equal to the tilt. The square that’s cut will be level with the world but since the whole frame is tilted, it won’t be level with the plywood. But I’d rather have a square square.

I have not performed any test cuts to substantiate my claims.

1 Like
15

I have to correct myself. Apparently the current code precomputes as well. I apologize for my misunderstanding. I spent so much time looking at GC’s calibration code that I thought it applied equally to the FW.

16

To make a cut square to the beam, start in the lower middle with both chains equal and pull in the same amount of chain on both motors, making a shallow cut upward. Upward so that friction adds to gravity, centered to cancel out chain sag, and a shallow cut to minimize the force from the bit in the stock. Once that plumb center line is established, the user should adjust his workarea to that standard.

Here’s a script to cut a ~36" vertical line centered on 0,0

G90 G21
Go Z5.0 F800.0
G0 Y-450.0 X0.0
G1 Z-2.0 F800.0
G1 Y450.0 X0.0 F800.0
G0 Z5.0 
M30
1 Like
17

Chain Sag experiments. Thinking that if you put the sled at 0,0 about, (center of board), and took the bricks off. Assuming that the motors paid out the equal amount of chain on both sides that would put the sled at 0,0 (I would eliminate the current chain sag corrections from the program for this experiment.) without any sag corrections, it would sit somewhere above the 0,0 point on the y, and hopefully ok on the x since both chains should be the same length.

With the bricks removed, the sled assembly with the router weighs “x”, say 7 pounds for discussion. With your new optical measuring cameras, is there a way to lock in on that point, and then record the sled movements as weight is added to the sled up to the brick weights, or even more for the experiment. I’m thinking that the sled should move up and down in a vertical line for different weights. (more or less sag)

At some heavy weight the sag would be almost zero, but that would be too heavy for our motors. At no weight added there would be “more sag” amount. This would be weight dependent. Maybe even take the router off for the minimum weight measurement.

This could tell us values at the center of the workpiece. Then do top center, and bottom center the same experiment. More values.

From that information perhaps a “sag” equation could be derived for the center of the work piece based on the testing.
Hopefully there would only be Y value corrections, and that X was stable.

The experiment could be further tested on an edge top, center, and bottom positions. In these we will certainly have both X and Y movement with different weights to consider.

I don’t know where to go with this until we see some data, but it seems that if we understood the impacts of sled movement with different weights at a few locations we would get some insight into sag. Then decide if this is worth pursuing further to develop our own chain sag “corrections”.

The other thing is this would be a “static” experiment. I don’t know how much, if any, these values would change based on dynamic sag (while it is moving during a cut), cutting induced sag (force on the chain to pull the bit through the workpiece).

Does it make sense to do this? Could compare the measured values to another experiment with the sag calculations in the program, and see what the comparison yields.

Have you done anything like this in the development of the Maslow?

18

done, but there are others who voiced opinions that didn’t vote there.

This is exactly the case where I dislike auto-merge robots.

David Lang

1 Like
19

I’m with you on that.

1 Like
20

well, if your calibration isn’t correct, you can’t trust anything :slight_smile:

That said, if you are just trimming off the edges of the legs, and don’t have
different chain tolerance set for the two chains, they will be mirror images of
each other. They may not be perfectly flat, but the line across the top of them
will be parallel to the top beam.

unless the tilting causes the chain sag to be different on each side, but the
proposed fix does not detect or address that.

David Lang