Pomysł ciekawy, ale jakoś tego nie widzę w codziennej praktyce warsztatowej.
Po pierwsze, większość nowoczesnych i średnio-nowoczesnych sterowań (Fanuc z AICC, Heidenhain z Cycle 32, Sinumerik z CompCad/Cycle832, a nawet amatorskie LinuxCNC) ma już wbudowane algorytmy typu Look-Ahead.
Sterownik sam analizuje geometrię z wyprzedzeniem i zwalnia w narożnikach dokładnie na podstawie fizycznych limitów dynamiki osi zapisanych w parametrach maszyny.
Po co dublować tę funkcję na poziomie G-kodu i sztucznie go "puchnąć" tysiącami dodatkowych linii z ciągłą zmianą F?
Po drugie, jeśli CAM generuje stały posuw, to zazwyczaj problemem jest zły postprocesor albo brak włączonej funkcji wygładzania ścieżki/Look-Ahead w samej maszynie.
Po trzecie, skąd Wasza aplikacja wie, jakie maszyna ma naprawdę przyspieszenia i sztywność konstrukcji? Maszyny (szczególnie bramowe) potrafią mieć inne przyspieszenie na osi X, a inne na ciężkiej osi Y.
Jeśli użytkownik wpisze te dane „na oko”, to aplikacja albo przeliczy posuw zbyt zachowawczo (strata czasu), albo zbyt agresywnie i maszyna zgubi kroki/wpadnie w rezonans.
Żeby to miało sens, musielibyście idealnie odwzorować model kinematyczny konkretnej maszyny w przeglądarce.