scurve path, respecting a maximum gforce trough corners or direction change

Hi,

I have been thinking for a while how a path planner should behave when running the gcode path.
In perticular wich speed to use in corners from 0 to 90 degrees. Let your thoughts shine on this.

When a machine has to move trough a 90 degrees corner, it should (almost) stop in the corner, then move in other direction.
If path lines are colinear, machine may go on at full speed. There are plenty of scenario's. And how to anticipate on this?

I don't know how lcnc does this exactly, What i have read is that lcnc has difficulties with short lines, arc's are ok.
Look ahead n lines... the g64  has influence.

I have thought about a solution wich works on the principle of
releasing a maximum ammount of gforce to the machine.

I made a example how to calculate the gforce when moving along a path at a certain speed and direction changes.

github.com/grotius-cnc/g_force_impact_ev...r/blob/main/gforce.h

If this gforce logic is inside the scurve path planner, would there be a better solution?



















 

Maybe this could give some insight how things work currently:




Edit:
Considering that the same author has had a pull request pending since May 2019 for some bug fixes in the trajectory planner I'm not sure anybody has a clear picture of what is actually happening in the core of linuxcnc anymore.
And yes, I know this is a bit provocative coming from a back bencher like me

Hi Arciera,

Thanks for the video. I watched it to the end.
First my respect to Rob Ellenberg's contributions to lcnc over the past years.

Most of the video it shows how he tried to solve blending using non exact mathematics.
Blending if in fact a off point solution, you will never reach or cross a waypoint.
They cheat at several points to get a desired effect, moving circle center coordinates on purpose..
The type of blending that is used, make's it impossible to calculate the exact path lenght.

The corner speed with blending is calculated by a few parameters like : square root, blend radius.

There is no information given about how to solve a path respecting exact coordinates and exact math.

For example for rapids, just use a 3d spline algo crossing the exact waypoints instead of the above off point blending.
Rob talks about ramping speed solutions, all soncence, stitch an glue examples how not to do exact math, sorry to say so.

Hi,

I made a calculation to get the g-force when the machine is following the path of an arc.

• The formula : a = 4 π² r n²

reference

The above works for arc path's. But the next question is :

• how about straight corners, like line-line corners?

I think i have found a solution to calculate line-line corners changes, it has to be reviewed if
what i did is mathematical correct.

github source code

Imagine the following situation :

If you have 2 lines, with a 90 degree corner, speed 1000 mm/min, machine running along the path :

• lineA={0,0,0},{0,2,0}
• lineB={0,2,0},{2,2,,0}

Situation 1.
LineA & lineB are vectorized back to 0.1mm lenght, to get a really tight corner.

This will then result in ~37 revolutions/second at 1000mm/min when passing the corner.
the Gforce is then 0.37 [g]

Situation 2.
LineA & lineB are vectorized back to 0.01mm lenght. What would happen when passing the corner ?

the Gforce is then 3,7 [g]

hmm. exact 10 times more.

I think the conclusion is as follows :

When the machine can stop in 0.1mm at a speed of 1000mm/min the gforce = 0.37 [g]
When the machine can stop in 0.01mm at a speed of 1000mm/min the gforce = 3.7 [g]

For info, if the lineA & lineB where 3 arc points, the Gforce of moving along the arc is : 0.019 [g]

I will think about this solution and maybe ask review at math exchange. I must be sure this is
a realistic solution.

picture


 

My take on this is the minimum radius that can be traversed is based on centripetal acceleration formulas.
Its soley dependendant on the accelleration of the machine.
I wanted to solve that in real time but my maths was not strong enough to solve the simultaneous equations required.

Hi Rod,

My take on this is the minimum radius that can be traversed is based on centripetal acceleration formulas.
Yes. The formula for the acceleration of a centrifuge is: a = 4 π² r n²
The radius has to be > 0, otherwise formula will fail.

Its soley dependendant on the accelleration of the machine.
Yes, decelleration is the opposite of acceleration. Where going trough a corner you will decellerate before and will
go trough the corner at a certain speed where the inertia force result is within machine accuracy.

I wanted to solve that in real time but my maths was not strong enough to solve the simultaneous equations required.

1. Say you did some test's with your plasma gantry, you found out it can handle 1.75 [g] during operation.
Staying under this 1.75 [g] value, your machine cut's nice tiny holes, moves ok trough corners, everything goes well.
You did find out the 1.75 [g] value by running a gcode script, something like the stepconfig wizzard to find out g-force.
You have seen that values above 1.75 [g] will give your oval shape holes, or inertia problems etc.

2. Above implementation is quite easy. Just one [g] value.
The path planner then uses this [g] value to calculate the max velocity for passing trough corners, derived from above formula.
The input "a" is then your max machine [g] value. The formula output "n" is then sqrt(n²). Where n = revolutions / second.
You did know the radius, circumfence, Then max velocity comes out.

3. If this should work, then path planning is a lot easyer to do. I will do some more test's today. Find out if i can spot bug's.