Można - ja tak robię w swoim kontrolerze. A i tak Arm Cortex M3 ( LPC1769 ) z 120MHz zegarem daje radę generować 4 osi ~100kHz. A tylko dodaje stałoprzecinkowe liczby 64 bitowe , bo całe przetwarzanie jest na PC ( 256 bitowy zmienny przecinek)spioch211 pisze:Zastanawia mnie także potrzeba zmiennoprzecinkowości. czy nie można tego ominąć poprzez określenie zakresu pracy np 1,001 [mm] nic więcej i tak nie uzyskasz w dalszych przeliczeniach kroku brać 10000[pkt]? i to przeliczać na kroki
interpreter G codu na USB: Arduino
-
jarekk
- ELITA FORUM (min. 1000)
- Posty w temacie: 4
- Posty: 1701
- Rejestracja: 17 mar 2006, 08:57
- Lokalizacja: Gdańsk
Tagi:
-
ursus_arctos
- Lider FORUM (min. 2000)
- Posty w temacie: 3
- Posty: 2083
- Rejestracja: 11 cze 2011, 18:29
- Lokalizacja: Warszawa / Lublin
- ale tylko prototyp który nie wszedł do produkcji. Pasuje tam też jeden z procków LPC43xx ( Cortex M4 + Cortex M0 / 204MHz oba) , pewnie kiedyś taką wersję też zrobię.
-
ursus_arctos
- Lider FORUM (min. 2000)
- Posty w temacie: 3
- Posty: 2083
- Rejestracja: 11 cze 2011, 18:29
- Lokalizacja: Warszawa / Lublin
Cudów nie ma, jak arduino ma 2kB pamięci, to parsowanie gcode na nim można robić co najwyżej dla sportu. Podobnie z prędkością przetwarzania - może i potrafią wysyłać impulsy do 30kHz bez jitteru, ale ile segmentów na sekundę mogą przetworzyć, to już się nie chwalą...
Ja mam w tej chwili w swoim sterowniku miejsce na 1200 rozkazów, które już zawierają wstępną obróbkę (wyliczone prędkości i przyśpieszenia). GRBL ma planowanie na 18 segmentów, czyli w gruncie rzeczy bardzo mało, przy większych prędkościach szacowanie prędkości w przód może wymagać większej liczby segmentów.
Ja mam w tej chwili w swoim sterowniku miejsce na 1200 rozkazów, które już zawierają wstępną obróbkę (wyliczone prędkości i przyśpieszenia). GRBL ma planowanie na 18 segmentów, czyli w gruncie rzeczy bardzo mało, przy większych prędkościach szacowanie prędkości w przód może wymagać większej liczby segmentów.
