Explanation of Velocity Lock

Is there somewhere I missed in the docs or the forums - a detailed definition of Velocity Lock (what parameters control the gui light on/off/color)? Is this related to corner lock? small holes? user settings, hal/ini settings etc.
I have my plasmac system that that turns the indicator on about 30 mm travel at 1600mm/min into a cut.
Not sure why? Is this good or bad? THC is functional - not sure if its actually controlling - will run some slopped material tests as experiments.
Voltage display quickly ramps up to a constant 4 volts when cutting. Initial cut ht set to 1.3mm. (THCAD-10 fed by 150K + 150K from Primeweld Cut60, 7i76e using F/32. )

Side note - Modified cut file from FastCam version 7. Works pretty good with holes changed to points for spotting, then manually using the pulse command (.5sec) at each occurrence of M0 followed by keyboard 'S' to resume.
Compared to the Software that came with this machine from China - LinuxCNC design, implementation, documentation is a godsend.

See linuxcnc.org/docs/2.8/html/plasma/plasma...k_velocity_anti_dive

Basically, everything is based on the book cutting speeds. When the cutting speed slows, there is more time for the material to burn away (wider kerf). The increased distance between the torch and the material increases the arc voltage. The THC thinks that the voltage has risen because the torch is higher so the THC drives the torch down to compensate (to reduce the voltage) and this can result in a crash.

There are a few overrides etc I am ignoring here but if we monitor motion.current-vel , we can set a threshold, say 90% of desired cut velocity. So if the current velocity falls below this, we can disable the THC until cut velocity is restored. So it goes without saying a machine with high acceleration is desirable as it limits the amount of segments that are under speed. But while we prevent the crash, we end up with a wider kerf so cut quality and part size suffers.

I personally think we are just scratching the surface of what is possible to maintain cut quality on corners, arcs, and other velocity slow downs. One issue we face is the manufacturers keep the high end features for their high end machines so there is a limit to what we can do with typical air plasma machines to manage cut quality and emulate the so called Hypertherm True hole quality.

Some good thoughts and explanation there - thankyou.
Asd I'm learning - Linuxcnc controls velocity to account for accel/decell limitations, say at direction changes (corners, small holes etc.) Then in the Plasmac mode we are dependent on that algorithm. Lc controlling a mill has a heavy table to move. Plasma cutting (at least on my small machine) only moves a cantilevered aluminum beam with a light weight torch on the end - in the Y direction. If this lower mass and therefore higher acceleration capability (for a given motor size) is not accounted for in Lc then we're paying a penalty. As you said - trading off cut quality vs. kerf width, vs. velocity and THC........
Is there a work around today with any parameters in the Hal/Ini files to input mass or acceleration capability? Or in a perfect world - is there a way to run a test on a given machine and determine the variables used in the velocity control algorithm?.
Maybe use a pattern like a 25 mm sq. Run repeated loops,
minimizing corner decel until steps are lost.
Back up to the point where you have a safe margin of error?
Thanks for helping us on the learning curve.

Basically when you build your machine, with a bit of trial and error, work out the maximum velocity and rapids your hardware can achieve for each axis and set that in your ini file settings. And yes, allow a margin for error.

An associate built a very complex model of stepper motors which I am happy I have validated after upgrading my drives and motors. But now I have to upgrade the table to handle the new velocity and acceleration without flexing.

And yes, plasma is all about velocity and acceleration. Light weight is good but it still needs to be rigid enough to not flex from inertial forces on each axis.

We were just discussing this here
forum.linuxcnc.org/plasmac/39851-thc-ena...re-we-doing-it-wrong