6th order motion planning (ref synthetos/g2core)

[mnesarco]

Hi Friends,

I am new to this CNC/grbl world and I am learning from different communities (grbl, synthetos, smoothie, marlymc, etc..)

I have been using g2core, but the project seems to be a little abandoned while grbl is pretty active. I am impressed with the port to STM32 done by https://github.com/thomast777/grbl32, STM32 boards are pretty cheap and available and brings a lot of performance compared to Arduino.

One thing that I love of g2core is 6th order motion planning, and I wonder why nobody else have ported it to grbl. It is maybe too difficult (i don't know) but it sounds like a great improvement to grbl, in particular for 32bit grbl forks.

I have been trying to identified where the magic is in g2core and found one single function with the 6th order math related to this:

https://github.com/synthetos/g2/blob/9fd1dae6aa9f7285894d8c1f31efefc18c1447f0/g2core/plan_exec.cpp#L670

In my limited understanding, i think it calculates the velocity of each segment in the planned queue. And i guess it is the same that one function do in grbl:

https://github.com/gnea/grbl/blob/eefe2bb95bb7b21ec2bb87e6ab6e20747e1626c4/grbl/planner.c#L126

I do not know the complexities involved in this issue but I wonder if someone has tried to port this amazing functionality to grbl.

hey @thomast777 what do you think about this?

[chamnit]

g2’s 6th order planner isn’t what it advertises to be. It’s really still a 2nd order planner that plugs in higher order acceleration ramps.

The math involved with a true 3rd order (or higher) is quite complex and gets especially hairy when you deal with non-zero accelerations through junctions.

[mnesarco]

Thanks for the clarification @chamnit. So is it actually equivalent to the current grbl motion planning or are there still any real advantage in g2core planning algorithm?

[chamnit]

G2 is smooth in and out of its acceleration ramps. If you need that. It is useful for traversing for rapid movements. But for CNC milling you need the programmed feed rates to be achieved as quickly as possible and maintain them throughout. This ensures the chip load on the tool is as programmed.

Anytime you smooth an acceleration, you slow down how quickly to gets to speed. I’m pretty sure that if you try running a job on Grbl vs G2, Grbl will always finish first, especially if there are lots of curves in the program.

[mnesarco]

Thanks again @chamnit, I haven't tried grbl yet, I started with g2core because I thought g2 would be better for cnc milling based on the claim that the sixth order movement was real. I will try Tom's grbl32 in my next build.

[bdurbrow]

I don't mean to be down on the Synthetos guys - building one of these from scratch is a non-trivial project - but I've come to the same conclusion that @chamnit has: counterintuitively, higher-order motion management (while useful for some things, like self-driving cars) is counterproductive for machining applications.

[talpadk]

G2 is smooth in and out of its acceleration ramps. If you need that. It is useful for traversing for rapid movements. But for CNC milling you need the programmed feed rates to be achieved as quickly as possible and maintain them throughout. This ensures the chip load on the tool is as programmed.

Anytime you smooth an acceleration, you slow down how quickly to gets to speed. I’m pretty sure that if you try running a job on Grbl vs G2, Grbl will always finish first, especially if there are lots of curves in the program.

Unless the smoother higher order curves allows for more aggressive settings (I would believe) Also smother moves probably reduces vibrations... but I'm not sure how much better it gets when using steppers, it not like they run smoothly to begin with.

[MARIOBASZ]

I had in mind to try G2Core for its motion planner with pull control. I use trocoidal milling strategy, I feel that reducing vibrations and tugs can result in greater acceleration, I don't know if my reasoning is correct, on the Trinamic website I have also read reference to speed control in S

[chamnit]

@talpadk : That may be true, if the 3rd order motion planner is optimal. However, g2core is very far from optimal. The planner assumes the acceleration ramp is a fixed curve. In reality, it can have many more possible states, especially at the entry and exit conditions.

[MARIOBASZ]

@chamnit , Adding a first acceleration at the beginning and another deceleration at the end (half of the acceleration value?) Could result in less jerk and better response of the stepper motors?

[chamnit]

That is effectively 3rd order motion planning. It’s more complex than just that.