Constant Velocity as a feature?

[phil-barrett]

I keep hear people say "Grbl doesn't do CV". So I looked into it a bit. But, to be honest, I did not find an exact definition of CV. In Mach, it is defined vaguely -

maintain a constant velocity during ALL angular or arc moves while obeying the acceleration parameter.

The vagueness is obeying acceleration parameter - no way you can change the speed of a stepper instantaneously so of course the velocity will not be constant. In terms of the speed of each stepper, the acceleration parameter simply controls how long it takes the stepper to reach the new speed. The Mach claim is that is does better with an arc composed with lots of short segments than "non-CV control software".

I think that CV is a non-issue with respect to grblHAL. In fact, I think that Mach 4 and grblHAL on a reasonably fast processor will produce very similar movements for any GCode program. CV seems like marketing bullshit. Am I wrong here?

[kfmut]

It's working by NOT following the path exactly...and this feature has baited a few ppls because they didn't know it could be switched on/off.

[phil-barrett]

Thanks, that is helpful.

[phomann]

Hi Phil, It’s not marketing hype. There are 2 modes of operation in Mach3/4, exact Stop and constant velocity. In exact stop, the axes comes to a stop at the end of a command (e.g. G01 X10 Y5) then starts the next command. With a Gcode file with a lot of small moves, exact stop increases the total processing time dramatically as the axes are continuously accelerating and decelerating. In Constant Velocity, Mach continuously looks ahead (how far ahead is configurabe) at the Gcode file and calculates a velocity to use as the axes transitions between Gcode segment. Yes there is still some acceleration and deceleration at the transition but nowhere near that of Exact stop. The advantage of CV is that it smooths out the motion and the cutting time for the Gcode is reduced. The disadvantage of CV is that there is some rounding of the cut at the corners. That said I’ve always used CV with Mach3 as I can’t see the corner rounding on my mill. Hopefully that helps you understand what CV is all about. Cheers. Peter Homann - (from my mobile) http://www.homanndesigns.com

…

On 5 Apr 2022, at 6:15 am, phil-barrett ***@***.***> wrote:  I keep hear people say "Grbl doesn't do CV". So I looked into it a bit. But, to be honest, I did not find an exact definition of CV. In Mach, it is defined vaguely - maintain a constant velocity during ALL angular or arc moves while obeying the acceleration parameter. The vagueness is obeying acceleration parameter - no way you can change the speed of a stepper instantaneously so of course the velocity will not be constant. In terms of the speed of each stepper, the acceleration parameter simply controls how long it takes the stepper to reach the new speed. The Mach claim is that is does better with an arc composed with lots of short segments than "non-CV control software". I think that CV is a non-issue with respect to grblHAL. In fact, I think that Mach 4 and grblHAL on a reasonably fast processor will produce very similar movements for any GCode program. CV seems like marketing bullshit. Am I wrong here? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[andrewmarles]

GRBLHAL is essentially running in CV mode at all times with look ahead and the corner blending is defined by the junction deviation. What is not currently supported is G61.1 exact stop mode which I don't think is terribly important since you can just set the junction deviation to a very low value and you will replicate similar behavior. With modern MCUs the look-ahead in GRBLHAL is deep enough that there are no issues with a constant velocity arc at really any feedrate you'd care to use.

[Meliusja]

Mach 3's implementation of CV with no guarantees on path deviation make it virtually useless for anything precision. The GRBL implementation is infinitely better in my opinion.