Почему ни один обоссанный интерпретатор гкода не умеет ограничивать ускорение линейной функцией от текущей скорости? Это же универсальное свойство шаговиков. У линейных осей робота, движимых электромоторами, ускорение пропорционально моменту, момент пропорционален току через обмотки электромоторов, ток пропорционален разности напряжения питания и противо-ЭДС мотора, противо-ЭДС мотора пропорциональна скорости его вращения. Если ограничивать движение максимальной скоростью и максимальным ускорением, как это в klipper сделано например, вместо функции от скорости, проёбываешь и более высокое возможное ускорение на низких скоростях, и более высокую возможную максимальную скорость при длительных перемещениях.

Похоже, единственный юзабельный и неглючный уй для станка - это axis через vnc. Четырёхграммовый двухсантиметровый кубик из полилактида без проблем выдерживает мой вес и расковыривается только ногтями по стыкам слоёв. Пришло время закупить экструдированного пенополистирола да стекляху на столик, а затем напечатать крепления для оси z и экструдера вместо сделанного ранее хлипкого говнеца из рэндомных метизов и стяжек.

Zig milling tool path surface spoilboard g-code generator: ghc -e 'let feed = 1000; diameter = 2; depth = -1; x = 140; y = 140; in putStr $ "F" ++ show feed ++ "\nG0 X0 Y0 Z0\nG1 Z" ++ show depth ++ "\n" ++ concatMap (\pass -> "G1 Y" ++ show y ++ "\nG0 Z0\nG0 Y0\nG1 Z" ++ show depth ++ "\nG1 X" ++ show (diameter * pass) ++ "\n") [1..x / diameter] ++ "G1 Y" ++ show y ++ "\nG0 Z0\nG0 X0 Y0\nM2\n"' // блядь пиздец у гкода уёбищный синтаксис, приходится писать кодогенераторы притом что он сам по себе тьюринг-полный

Чят, посоветуй хороший, годный триде-принтор, на который можно повесить дремель вместо экструдера и что-то неторопливо вырезать.