@dc42 Thanks for those details.
So the loop is closed at the 1HCL or M23CL board software level. Can you tell me if it is a velocity loop or a position loop ?
A velocity loop here could be the software detecting in real time that the required speed of the running Gcode command is not reached. And so react by requiring more power to the driver, to motor reach the required speed, and catch up the theoretical position a T moment.
A position loop could be the software checking at the end of a Gcode command if the required position is reached or not. And so react by delaying the motion execution to wait the system reach the good position, before starting the next Gcode command.
It could be done in real time too, by checking current position in real time, and react by requiring more power to the driver too, to reduce the position error.
Anyway, if the loop is closed in real time during Gcode command execution, this should reduce and adapt the motor current to what is really needed, and so maybe reducing MRR and VFA.
One more thing. Is a linear encoder support could be added in future ? To check the axis carriage linear position instead of axis motor angular position ? The final idea would be to make a dual-loop system and so eliminate all possible belt / leadscrew / mechanical backlash on each axis.
I ask those questions just by curiosity, it's an interesting domain.
Thanks