# Transition speed between cuts

Is there a setting in the Firmware that controls the transition speed of the movement between cuts?

Could it be110 and 111 in the Firmware Tool?

At first I thought you were right about 110 and 111 but it seems it’s not so simple. I found the following info here.

The MAX_VELOCITY setting in the ini file [TRAJ] section defines the maximum rapid traverse rate. The maximum rapid traverse rate can be higher than the individual axes MAX_VELOCITY setting during a coordinated move. The maximum rapid traverse rate can be slower than the MAX_VELOCITY setting in the [TRAJ] section if an axis MAX_VELOCITY or trajectory constraints limit it.

The MAX_VELOCITY setting mentioned there is something that has to be set before the firmware is compiled. But at the end it says that the rapid rate can be lower than set in MAX_VELOCITY so I believe that lowering 110 and 111 will slow the rapid moves down but the machine will probably move faster when going diagonal than when going horizontal or vertical.

Hope that helps, I have found the following two links to be pretty helpful when trying to understand G-Code or GRBL settings.

Thanks. I set it to1000 and it is slower but it may be faster on a diagonal. I didn’t notice that move.

I’m not 100% certain what you’re asking.

If you’re asking about speed of movements in general, \$110, \$111, and \$112 are the maximum speed a specific axis will travel, while \$120, \$121, and \$122 are how quickly those movements accelerate up to the current feed rate from the current rate of travel.

If you’re asking specifically about cornering/sharp cuts, that is handled by \$11. GRBL has an internal cornering algorithm to determine how much the machine needs to slow down for specific angles. The quick and dirty is that a lower \$11 will result in slower, more careful turns, while higher values result in faster junctions. You can read more about this setting and how cornering works (warning: lots of math) at the following two links:

\$11 explanation

How cornering works in GRBL

1 Like

I was talking about movements in general. I’ll look further into the other numbers you mentioned. Thanks for your reply.

@Wills not sure why you need to tinker with that?
@KGN quick and dirty dose’nt fall off the rails…
Maybe just slow down a little

The goal is to “smooth” the motion so it’s not so jerky.