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.











 

I did a few tests.

1. The first test is a cutting a hole 6mm at 1400mm/min.
2. The second test is cutting a hole 6mm at 3000mm/min.
3. The last test is passing a corner.

I know cutting the hole 6mm at 1400 mm/min will give perfect result from my experience.
It gives a gforce of 0.018 [g].

I know cutting the hole 6mm at 3000 mm/min is too fast to get a circulair accuracy 0.2mm from my experience.
It gives a gforce of 0.083 [g].

From above i can see, the gforce of 0.018 gives perfect results.

Then move trough a corner, given a tight radius 0.2mm, find velocity while gforce staying below < 0.018 [g].
This results in a corner velocity ~360 mm/min.

For info, It results in 255 mm/min when corner radius is 0.1 mm. (better accuracy)

This all looks realistic to me from practical perspective.

picture of test

Grorius, This is quite interesting.
This thread mentions that it is possible to vary the accelleration on the fly using the function emcAxisSetMaxAcceleration(axis, maxAcceleration)
forum.linuxcnc.org/20-g-code/26437-any-g...c-dec-override#33120

I did some work that extended the state tags structure to publish new interp.xxxx pins in motion that showed the arc radius and if its a circle or not in real time.
github.com/rodw-au/linuxcnc/tree/arc-radius
If you follow the commits ahead, you will find a pull request to Linuxcnc that fizzled out
github.com/LinuxCNC/linuxcnc/pull/900
My thinking was that a custom component could use these interp.xxxx pins to modify behaviour via some yet to be invented algorithm.
So you could call emcAxisSetMaxAcceleration() in real time to set your limit.

The other approach to do this is to use a gcode filter as we have done in the monokrom plasma config which probably provides almost exactly what you need. github.com/joco-nz/monokrom-vcp
It already has the data handling for the velocity overides linked to hole radius (as a ratio of material thickness), and the material via a SQL database which could become pretty massive..
This video I did explains the hole handling in monokrom


Monokrom's gcode filter finds the holes as the gcode file is opened, removes the existing gcode and replaces it with our own optimised gcode.

I think Monokrom approach is probably the best way forward as it provides a near complete framework to manage what you want to do.

A lot of the Hypertherm TruHole technology is done in their cam software in the  gcode generated. Linuxcnc does not have its own cam module but a gcode filter allows us to achieve the same result..

So many paths to achieve the same result... Nirvana!

Maybe this could be of interest as it's derived from LinuxCNC and they claim to have implemented Jerk Control :
discourse.heig-vd.ch/uploads/short-url/d...zyGbGiPk3tht3Xej.pdf