Is anyone familiar with the principles of acceleration in GRBL?

I'm wondering if anyone is familiar with how GRBL deals with acceleration - the high level principles rather than the code.

This is from the comments in the GRBL file planner.c

/*                            PLANNER SPEED DEFINITION
                                     +--------+   <- current->nominal_speed
                                    /          \
         current->entry_speed ->   +            \
                                   |             + <- next->entry_speed (aka exit speed)
                                   +-------------+
                                       time -->

What I'm struggling with seems to me a simple and obvious issue - namely when one GCode move finishes and another starts then (inevitably?) at least one of the motors must change speed or direction. And if that is the case I would expect that deceleration / acceleration is needed between every pair of GCode moves.

So how is it that GRBL seems to be able to eliminate some of the deceleration/accleration intervals?

...R

Yes in theory, but if the change is slight the acceleration phase may be shorter than one step and can
be optimized out, or at least won't be detectable listening to the motors (in fact for circular cuts the
speed doesn't need to change, each radius of cut and feed rate sets a speed limit) - circular motion has
constant acceleration magnitude.

If doing a right-angle between fast cuts then the deceleration/acceleration is clearly needed.

Since GCODE primitives only have straight lines and circles it makes the planing simpler than if general
Bezier/spline curves were primitives. For circles you just have a speed limit to figure out, for joins between
straight lines you can use the angle to determine the speed at the join. You can also compare the time
for the acceleration segment against the time between steps - if its only a step or less you can optimize
the acceleration segment away completely as it wouldn't be more than one step in duration anyway.

An interesting thing I noted about some bundled software with a budget laser cutter was that it didn't
do the speed limiting for a circle (even though it handled deceleration around sharp corners fine).
This meant that it went haywire for fast cuts with small circles as the steppers miss-stepped. Hopefully
GRBL doesn't share this flaw (though for CNC milling feed rates are very slow by comparison, and you
wouldn't bother doing circular rapids anyway).

Thanks Mark. That is very helpful.

...R

I've spent too long figuring out how to drive steppers GCODE(!). Its more complex than you
might think, in particular you need theoretically unbounded lookahead to the GCODE instruction
stream to get optimal speed profiles, so you have to structure a GCODE interpreter with a parser that
inserts commands on a queue, and the planner consumes these until its got enough information
to actually start running the motion segments - thereafter it has to assume the parser is going to
keep up as its committed to the plan.

Global speed override, pause/resume make things more complex too. Decent emergency stop
also needs to be handled properly to avoid tool dig-in (you can't just try to stop feeding pulses
to the motors suddenly, as on a curved trajectory that may force the cutter into the workpiece
and snap it) In fact emergency stop is basically the same as pause (but for safety you probably
need a power cutoff as well but ensure the motor supply has enough capacitance to finish the
pause deceleration so the tool isn't snapped and thrown across the room).

The more you look at the problem the more complex it becomes!

Does it do any harm NOT to bother with look-ahead planning and simply live with the extra time taken by deceleration and acceleration between GCode moves?

...R

Just living with the ace l/ decel times can increase a job time considerably.

That is part of the look aheads job to keep those to a minimum. and only use them where needed
Or in the case of laser work actually ignore them to prevent extra burn time around corners.
GRBL has a setting to IGNORE decel around corners.

You could in theory use that to some advantage at the risk if digging in !
People have been able to fine tune the acel / decel in the GRBL preferences for better performance and shorter job times but a lot depends on the motors used and thier specifications.

The limitations of GRBL are a trade off between higher priced machines with better and more complete g-code implementations and the MCU / entry price.

Even very small changes to GRBL can have repercussions in the size of the sketch making it inoperable as it is so close to the limit.
That's why there are no fancy features such as CSS or MACROS

Sort of curious as to why re-invent the wheel ?

ballscrewbob:
GRBL has a setting to IGNORE decel around corners.

Thanks Bob.

I'm not using GRBL - I have written my own code and I'm trying to get my head around the principles to decide what extra I might need to incorporate.

...R

Robin2:
Thanks Bob.

I'm not using GRBL -
...R

Oh WOW !

That's a mighty task you have taken on so I wish you all the best.

ballscrewbob:
Oh WOW !

That's a mighty task you have taken on so I wish you all the best.

About 400 lines of Arduino code in a single .ino file.

All the hard work is done on the PC using Python.

...R