bmajkut:
Popatrz na to tak: im szybciej maszyna jedzie, tym prostsze odcinki robi. To logiczne, bo przyśpieszenia, które są wymagane do przejścia trajektorii o zadanym kształcie rosną do kwadratu prędkości.
Wniosek: możemy przybliżać prostymi odcinki o stałym czasie trwania (nie mylić ze stałą długością).
Dowcip w tym, że musisz mieć przygotowane parametry timera na zapas - zawsze jeden fragment do przodu, żeby po zakończeniu wykonania poprzedniego segmentu natychmiast podmienić parametry (przeliczyć nie zdążysz).
Aktualna pozycja to X0, pozycja w czasie (teraz+T) to X1.
Przygotowujesz dir = X1>X0 (albo odwrotnie, zależy od konfiguracji osi)
okres impulsów t = T/abs(X1-X0)
faza impulsów to bardziej złożony problem, teraz jestem w pracy i nie będę się rozpisywał.
generalnie, po osiagnięciu czasu T0 szybko ustawiasz powyższe parametry i przeliczasz nowe dla czasu T2. Koniec filozofii. Jest to przybliżenie, ale całkiem znośne. Używa hardwarowego timera. Czy oprogramujesz to bez oscyloskopu? Nie wiem, może są jakieś wirtualne oscyloskopy do emulatora.

Kiedy się projektuje jakieś urządzenie, to zaczyna się od koncepcji. W skład koncepcji wchodzi ustalenie zakresu możliwości urządzenia. I już na tym etapie zasadniczo wybiera się rozwiązanie minimalne

Minimalizuje się koszt. Jak urządzenie ma być produkowane w milionach sztuk, to owszem, tak się robi. Jak mówimy o pojedynczych setkach czy nawet sztukach, to zwyczajnie bardziej opłaca się wziąć nieco przewymiarowany hardware i mieć święty spokój.

spokojnie rozpędzę zwykły napęd na silniku krokowym płynnie i płynnie wyhamuję co do kroku, osiągając w przelocie 200kHz step współczesnym procesorem 8-bitowym, wewnętrznie taktowanym 1-2MHz za ledwie

Na jakiej krzywej? Bo na prostym odcinku to faktycznie nie problem. Cały czas przypominam, że mówimy tu o "mądrym" sterowniku, a nie głjupawce jakiejś, która wymaga podawania prostych odcinków

Wielu korzysta z MACH'a albo LinuxCNC i teraz zacząłem się zastanawiać czy te programy są wyposażone w taki system przewidywania tego co będzie za chwilę

Trudno powiedzieć. Ale skoro taki "amator" jak ja to zaimplementował, to raczej bardziej profesjonalne narzędzia też to mają.

widać tu przewagę wiedzy nad sprzętem.

Kolego, to się nazywa insynuacja. Insynuujesz, że Twój rozmówca wiedzy nie ma. Mylisz się. Nie mam natomiast tyle czasu, żeby pieścić 8-bitowy procesor, kiedy mogę użyć czegoś bardziej współczesnego.

z submikronową precyzją numeryczną

Problem w tym, że na serach możesz wykonać efektywnie "skok" o kilka "kroków". Po prostu mówisz "teraz ma być X" i tyle. Napęd ma się dostosować. W przypadku napędu krokowego trzeba wygenerować wszystkie stany pośrednie, Serwomechanizm można sterować ze stałą częstotliwością - powiedzmy, 1kHz. Przy większej prędkości straci się trochę (sporo) precyzji - przykładowo, przy 1m/s korekta będzie co milimetr! - ale w ogóle da się to zrobić, nawet niezależnie od rozdzielczości enkoderów. Jeżeli masz silnik krokowy ustawiony na 200kroków/mm, to przy 1m/s trzeba generować impulsy z częstotliwością 200kHz. Z80 tego nie zrobi. AVR tego nie zrobi. Procesor taktowany 100MHz zrobi to z łatwością.

Co do tematu przyśpieszania - albo jest to bardzo proste (na poziomie półgłupiego sterownika) albo potwornie uciążliwe (na poziomie interpretera g-kodu czy innych podobnych wytworów). Pierwsza część to realziacja niemal fizycznego wypuszczania sygnałów step/dir. Tutaj nie ma filozofii. W najprostszej wersji (zakładając, że masz odpowiednio szybki kontroler z FPU), przeliczasz sobie aktualne współrzędne i kwantyzujesz do wielkości kroku. Jeżeli wartość jest większa, niż poprzednia -> dir0, impuls step, jeżeli mniejsza -> dir1, impuls step, jeżeli równa -> nie robisz nic.
Jeżeli zaś chodzi o zaplanowanie ruchu maszyny, to robi się mniej radośnie, gdyż trzeba przeglądać ścieżkę w przód i sprawdzać, czy przypadkiem nie należałoby już zacząć zwalniać przed:
a) zatrzymaniem
b) ciasnym łukiem.
Zdaje się, że jak się w G-kodzie ustawi posuw np. na 30mm/s, to nikt się nie przejmuje tym, że na rogach kwadratu trzeba się zatrzymać, a łuku o promieiniu 0.5mm też się raczej nie zrobi z tą prędkością - to musi zrobić albo program sterujący albo autonimiczny sterownik. Robiłem to (na PC) i o ile nie wymaga to zaawansowanej matematyki (równania kwadratowe, pochodne), to wykonanie jest zwyczajnie upierdliwe.

PS. Zapomnij o kontrolerach z rodziny AVR. STM32F4 to jest mniej więcej to, czego potrzebujesz, jeżeli maszyna ma być autonomiczna.