The 5kHz is the value provided by the RTLinux task scheduler under stress testing. This is mostly a theoretical limit of how fast the OS can maintain a constant velocity while timing a step.  Hence, the advice to avoid multitasking while running an RT application.

In reality, the steps-per-second values in the INI files are the maximum limit constrained by the communication bandwidth, kinematics math, inertia of the mechanisms, mass of the z-axis, and the type of motor.  On my mill, I tend to use about 30rpm on the lead-screws as small <3mm end-mills must move slower to avoid heavy tool-load.

GRBL (and Marlin) does not deal with most of these issues, and has been reported running from 1500 rpm (~10kHz) to >3000 rpm (~30kHz). Note, they were likely using low-voltage motors on >24v current-limited drivers to get this kind of performance.   We do recommend this firmware for simple 2.5 axis engravers/routers where speed is preferable to precision, but don't think a gantry style platform will ever get anywhere near that fast with open-loop steppers.

Cheers,
~J~

The major timing limit is with LinuxCNC sending raw change-pin-state messages rather than high-level g-code to an interpreter like GRBL. Thus, there is a limit to how many updates per-second can be made through a 115200baud serial link, and still allow enough run-time on the atmega to actually process these tasks.

For NEMA17 1.8' motors, we tested these limits without generating RT task timing error messages. Some motor acceleration curves are very slow to pick up, and you start to lose the torque needed to maintain proper tool-load. There will certainly be  machine specific settings people will need to modify, and dropping unused axis will bump performance.

"Minimum time from a direction change to the beginning of the next step pulse in nanoseconds" (this can be 1ns in theory, but is set for safety).
stepgen.<chan>.dirsetup = 400000

"Minimum time from the end of a step pulse to a direction change in nanoseconds."
stepgen.<chan>.dirhold  = 400000

Note, this part is odd as it refers to the minimum TX time for a UART message (not 1ns as one may be led to interpret):

stepgen.<chan>.steplen  = 1

So, we calculate the worst case max output from the default profile:

f_Hz = 1/ (t_dirsetup + t_dirhold) = 1/(0.0004 + 0.0004) = 1250Hz

And assume a 1.8' stepper in half-step mode is 800 steps/rotation:

rpm = f_Hz / 800 steps/rotation * 60 second/minute = 93.75 rpm

More information about LinuxCNC HAL variables cam be found here.

Your max velocity calculation with the default profile sounds about right. =)

We tried to test with the most resources people will likely ever use, as it is easier for people to remove stuff... than to have us document how to configure each machine.

The pi3B+ can barely handle 5-axis kinematics, and starts to throw latency errors with 8-axis. At some point, the driver will need re-written in C/C++ with bit-packing for better i/o performance.

Note, most of the path planners on the machine are limited to 3-axis, but NativeCAM can generate 4-axis g-code jobs.  Also, I referred the author to a script to cut gears with a slitting saw that he may include as a menu macro at some point, but he wasn't personally interested in our project at the time.