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

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!

Grotius wrote:

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

I think that this is because the G-code does not provide exact numbers, so there needs to be a certain amount of fuzz in the calculations. 

Most CAM packages only provide 3 or 4 decimal places for arc end points and radius/centre. This is very often not an exact representation of the actual points, and the trajectory planner needs to account for this. 

Also don't forget combined rotary and linear moves, what does "jerk" even mean there? How do you blend them? 
 

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