Great writeup and analysis Kyle!
This takes me back to my physics 101 class.
Would it make sense to calculate the arbitrary force ‘goal’ using the tension setting at frame size.
The data seems to imply a square frame could perform better as then the Y angle forces would be same as X (ignoring gravity)
Dano
When my Z axis is too high, it tends to give me less accurate movements and tends to tilt more easily. Could it be that if your drawing method were shorter, it would give a different result? You’re doing great research!
Would someone (?) please try to replicate this experiment, using a horizontal setup? For that matter, it would be good to have multiple sets of data for both orientations, to reduce the impact of site-specific issues on the analysis.
Thanks for all the input everyone!
I see three possible adjustment algorithms that could be helpful here
f(1): travel angle as we’ve been discussing
f(2): arm height angle
f(3): vertical weight of the machine
Let’s just focus on f(1) for now, since I think it has the most impact.
I created a mockup of my frame in fusion to measure the belt angle as the machine travels, and here are three views at the origin, 100mm along the X axis, and 1000mm along the X axis. You can see how the angle changes relative to the direction the machine is moving.
Here’s a little spreadsheet showing how the pulling angle impacts the force and what percentage reduction would be needed to equalize the two. I think initially testing a reduction only could be useful to not accidentally over stress any one belt. Also note, I haven’t throughly checked the math on this yet so if anything looks off, please let me know!
What’s interesting here is seeing how much the force actually changes (assuming the math checks out.) At 1000,0 location the longer belts have nearly 3x the force of the short belts moving the machine. I don’t know if reducing the force on those belts by 1/3 would resolve the issue I’m seeing or if that would be too much, we might just need to test and see what happens.
Kyle wrote:
What’s interesting here is seeing how much the force actually changes
(assuming the math checks out.) At 1000,0 location the longer belts have
nearly 3x the force of the short belts moving the machine. I don’t know if
reducing the force on those belts by 1/3 would resolve the issue I’m seeing or
if that would be too much, we might just need to test and see what happens.
the thing we need to figure out how to model is that the belts are not actually
solid, they are springs.
so how can we insert a spring constant (length * force * string constant =
stretch) to the calculation to account for this.
David Lang
Yeah, I guess a fourth function f(4) could be a stretch coefficient.
Wow, nice measurement campaign! Looks like I’m late to the party!
I’m still trying to understand your data:
Can you define what you mean by “skew”, please? Maybe it’s because I’m not a native speaker, but I’m confused:
Phrased differently: Ignoring the dependency on the direction of travel, you mostly see a scaling effect with a scale factor < 1 combined with sagging (gravity) around small x values. Correct?
About the travel direction dependency: What happens if you move vertically from (-1200,-600) to (-1200,600) and (1200,-600) to (1200,600)? The reason I’m asking is that when you are moving e.g. right and then up, the TL belt starts as “releasing” belt and then becomes a “pulling” belt (and vice versa for the BR belt). Could this cause the longer top belt to pull the sled towards the center when you move from one row to the next?
I know that doesn’t explain the behavior in the top left quadrant. That quadrant behaves like my horizontal setup does everywhere; the sled is lagging behind the nominal position.
To answer you questions
Good ideas on testing other tool paths, it’s clear that the direction of the machine has a pretty big impact on the measurements. This is a very tedious process and not sure how much time I’ll have to try to manually map out other paths.
I think this is actually happening to me here as well. This is looking up the Y axis toward the origin and there’s looks to be a lag in every other row, assuming this is the true center. I think this is causing the issue of every-other row being worse in my data since I was measuring from these points as the X origin. What’s becoming pretty complicated is trying to figure out where the nominal plane is to compare the actual points against. I’m going to get a 4’ ruler soon which should help a lot.
Next step is to look at this offset in the X origin along the Y axis and see if it smooths out my data then see if my trigonometry belt angle theory still makes sense. Seems like that might be the case for the edges, then deflection, machine lash/play, or stretching (like @dlang has mentioned) could be the cause of the lag.
I know how tedious this is! I’m impressed how you measured every point and by no means I’m expecting you to repeat this! My thought was more along the lines of drawing a couple of dots at x=-1200 which you approach from the right, and then a straight vertical line to see if the line goes through the dots and if the line is straight or curved. Just to find out what might be worth looking at next.
Something like this (gcode is handwritten and untested, so check in the preview first):
kyle.nc (852 Bytes)
Again: Just if you really feel like doing it.
Yeah that might be the way to go. I’m going to pick up a 4’ ruler from harbor freight today so I can get a more accurate picture of how well the points align along the Y axis from this X axis tool path. The photo I posted last more or less shows how they aren’t aligned very well but I only have an 18" straight edge ruler so I can’t really tell across the whole workspace.
But I can’t really tell if one set of dots is the nominal location and the other direction is ~2mm off, or if the nominal location would actually be right down the middle and both are off by 1mm in opposite directions.
Interesting! If this is as pronounced with a vertical frame as with my horizontal setup, it seems to me that the difference between the pulling and releasing belts is a big contributor. I still have to measure this lag again now that I have higher belt tension.
I don’t think that’s important. As long as it’s only a shift of the whole coordinate system, it doesn’t make a difference to the cuts.
hendrik wrote:
I don’t think that’s important. As long as it’s only a shift of the whole coordinate system, it doesn’t make a difference to the cuts.
I suspect that errors are going to be symmetrical so as you cross the center you
will see if the errors are lining up or shift in the other direction.
David Lang
Exactly, that’s where I’m not sure yet if they equally cross a center line or if one direction is accurate and the other is off. I think it does make a difference if you have a cut that changes direction there, or think of the case where you might be cutting box joints up that line and changing direction each time.
Assuming each arm has similar friction forces I would expect fairly symmetric results as well. But we also have seen some arms are more stiff or requires more force to retract. Complicated.
Dano
The logic makes sense to me with less angle (longer belts) more force in the X vector is applied/exerted. Reducing the force might be ok if it’s trailing ( moving positive X). But moving back -X I suspect we don’t want significant reduction. In general I suspect we probably don’t want a 1:1 linear change in force. Likely some sort of force curve .
Dano
Yes, the math equation doesn’t seem quite right – reducing by 70% seems like far too much. It would be interesting to see if I could get a dev version of the software that allows me to adjust the force on each belt and see what reduction is needed to even things out in the trouble areas.
I’m also thinking of rigging up a fishing or crane scale in the corners and see what tension each belt is imparting on the frame.
I’m using this and it has shown me how a very tight reel doesn’t impart the same force, so I’m in the process of softening the arms to achieve balance in the force and tension of the belts.
I’d love to see some of your data on this!! Can you post what the numbers are at 0,0, and 1200,0? Also what the numbers do on the way to that point? Would also be helpful knowing if you have a vertical or horizontal frame.
