Bezprzewodowe Grbl
-
Autor tematu - Specjalista poziom 1 (min. 100)
- Posty w temacie: 22
- Posty: 134
- Rejestracja: 15 kwie 2009, 15:18
- Lokalizacja: Płock
Re: Bezprzewodowe Grbl
projekt z zakupem NVEM ma na celu utworzenie oprogramowania dla użytkownika gdy nie chce być pasami przywiązany do MACH'a
a daje możliwość zmiany softu na odbiór ramek z linuxCNC lub innego oprogramowania do sterowania CNC
cena zakupu to 150zł + kw więc taniej jak nie które PCB dev do nauki (stm32 mam w paluszku ) a i odpada mi projektowanie
w każdej chwili można przywrócić soft orginalny z NVEM ( nie ma on zabezpeczeń FLASH do odczytu)
projekt udostępnie , znalazłem na PCB kilka rzeczy które się pożniej przydadzą np kolejny port rs232 ( gdzie mam przylutowane przewody do FT232 np do obsługi falownika przez Modbusa)
a daje możliwość zmiany softu na odbiór ramek z linuxCNC lub innego oprogramowania do sterowania CNC
cena zakupu to 150zł + kw więc taniej jak nie które PCB dev do nauki (stm32 mam w paluszku ) a i odpada mi projektowanie
w każdej chwili można przywrócić soft orginalny z NVEM ( nie ma on zabezpeczeń FLASH do odczytu)
projekt udostępnie , znalazłem na PCB kilka rzeczy które się pożniej przydadzą np kolejny port rs232 ( gdzie mam przylutowane przewody do FT232 np do obsługi falownika przez Modbusa)
-
- Lider FORUM (min. 2000)
- Posty w temacie: 7
- Posty: 7781
- Rejestracja: 26 lut 2011, 23:24
- Lokalizacja: mazowieckie
Re: Bezprzewodowe Grbl
Jajca sobie robisz ?
To że ktoś sprzedał jeden egzemplarz za pół ceny nie znaczy że tyle kosztuje.
-
Autor tematu - Specjalista poziom 1 (min. 100)
- Posty w temacie: 22
- Posty: 134
- Rejestracja: 15 kwie 2009, 15:18
- Lokalizacja: Płock
Re: Bezprzewodowe Grbl
tuxcnc nie myślisz przyszłościowo z projektem (lub wcale nie myślisz , a jeśli myślisz to pomyśl ) ...
to że Ja kupiłem za taką cenę to Brawo Ja ! mam coś do testu dla osób skierowanych które już mają Nvem
to że Ja kupiłem za taką cenę to Brawo Ja ! mam coś do testu dla osób skierowanych które już mają Nvem
-
Autor tematu - Specjalista poziom 1 (min. 100)
- Posty w temacie: 22
- Posty: 134
- Rejestracja: 15 kwie 2009, 15:18
- Lokalizacja: Płock
Re: Bezprzewodowe Grbl
Relacja z placu ,A4988 i silniczki z tego co miałem w zapasach aby kosztów nie robić dodatkowych przy testach
STM32F207 pięknie się spisuje jako sterownik grbl z ethernet , 6 osi z zegarem 400khz działa stabilnie jedynie programy współpracujące z GRBL z połączeniem ethernet opensource działają jak "gil z nosa" wiec muszę dopracować swój soft + doc do niego jeszcze .
Dlaczego ?
opensource programy do sterowania GRBL działają na zasadzie wymiany danych w "string" (ciąg znaków A-Z dla nie programistów)
zmieniłem to na &struct dzięki temu mogę "bombardować" GRBL z zapytaniem o status/pozycję '?' co 1mS (x1000 na sekundę)
planner zwiekszony buffor do 1023 pozycji
doszła również kolejna płytka z STM32F407 (168Mhz )
Cena 160zł + kw ale zdarzają się "używki" za nie całe 100zł znaleść
aby pinów do sterowania resztą CNC nie zabrakło , o dziwo overclock z 168MHz core do 220Mhz czy 250Mhz działa bardzo stabilnie (lecz nie wiem czy mi się aż taki clock)
do tego PCB ma flash 128M pod spodem , Host USB i kilka innych świetnych drobiazgów
blue_17 dzięki , doszedł st-link razem z stm32f407 praca/debug aż się mordka śmieje pod czas pracy
do obydwu PCB w internecie / github polecam znaleść można soft do LinuxCNC RT
https://github.com/pekkaroi/ethernetcnc
przepisać na biblioteki HAL i jest tanim kosztem świetny sterownik CNC do Linux'a dla tych co nie mają LPT
STM32F207 pięknie się spisuje jako sterownik grbl z ethernet , 6 osi z zegarem 400khz działa stabilnie jedynie programy współpracujące z GRBL z połączeniem ethernet opensource działają jak "gil z nosa" wiec muszę dopracować swój soft + doc do niego jeszcze .
Dlaczego ?
opensource programy do sterowania GRBL działają na zasadzie wymiany danych w "string" (ciąg znaków A-Z dla nie programistów)
zmieniłem to na &struct dzięki temu mogę "bombardować" GRBL z zapytaniem o status/pozycję '?' co 1mS (x1000 na sekundę)
planner zwiekszony buffor do 1023 pozycji
doszła również kolejna płytka z STM32F407 (168Mhz )
Cena 160zł + kw ale zdarzają się "używki" za nie całe 100zł znaleść
aby pinów do sterowania resztą CNC nie zabrakło , o dziwo overclock z 168MHz core do 220Mhz czy 250Mhz działa bardzo stabilnie (lecz nie wiem czy mi się aż taki clock)
do tego PCB ma flash 128M pod spodem , Host USB i kilka innych świetnych drobiazgów
blue_17 dzięki , doszedł st-link razem z stm32f407 praca/debug aż się mordka śmieje pod czas pracy
do obydwu PCB w internecie / github polecam znaleść można soft do LinuxCNC RT
https://github.com/pekkaroi/ethernetcnc
przepisać na biblioteki HAL i jest tanim kosztem świetny sterownik CNC do Linux'a dla tych co nie mają LPT
Re: Bezprzewodowe Grbl
Wystawiasz gdzieś repozytorium?gothye pisze: ↑26 paź 2020, 08:58Relacja z placu ,A4988 i silniczki z tego co miałem w zapasach aby kosztów nie robić dodatkowych przy testach
STM32F207 pięknie się spisuje jako sterownik grbl z ethernet , 6 osi z zegarem 400khz działa stabilnie jedynie programy współpracujące z GRBL z połączeniem ethernet opensource działają jak "gil z nosa" wiec muszę dopracować swój soft + doc do niego jeszcze .
Dlaczego ?
opensource programy do sterowania GRBL działają na zasadzie wymiany danych w "string" (ciąg znaków A-Z dla nie programistów)
zmieniłem to na &struct dzięki temu mogę "bombardować" GRBL z zapytaniem o status/pozycję '?' co 1mS (x1000 na sekundę)
planner zwiekszony buffor do 1023 pozycji
Gdzie przeczytałeś lub widziałeś źródła do linuxcnc?
Z tego co widzę w chinach można teraz wyrwać NVEM v2 6-axis za 250zł
-
Autor tematu - Specjalista poziom 1 (min. 100)
- Posty w temacie: 22
- Posty: 134
- Rejestracja: 15 kwie 2009, 15:18
- Lokalizacja: Płock
Re: Bezprzewodowe Grbl
STM32F407 czy nvem polecą na github (myślę że ok tyg jeszcze) zostały ostatnie testy , różnica to tylko zmiana pliku nagłówkowego który podmieni postprocesor wg ustawień . na STM32F407 zegar TIM2 można śmiało rozpędzić do 4MHz (pulse 0.125uS ) wiec serwo śmiało wysteruje .
Przy NVEM więcej jak 400KHz równych impulsów nie wyrabia już ale i tak uznaje jako bardzo dobry wynik .(wpieram się oscyloskopem oraz analizatorem logicznym do weryfikacji programu)
Komunikacja TCP/IP z PC wczoraj po optymalizacji softu na PC rozpędziłem do 300 komend gcode na 1 sekundę do sterownika , obecnie kończę moduł PLC ( wejścia/wyjścia),RS485 do falownika oraz chcę sprawdzić jak wejścia z osobnymi timerami zachowają się jako odczyt enkoderów .
Przy opracowaniu projektu spędziłem sporo czasu (kilka nocek też poświęciłem jak coś mi nie dawało spokoju w prawidłowym działaniu)
migracja GRBL to pryszcz , konfiguracja kodu dla STM + lwip + rtos to już zabrało najwięcej aby uzyskać szybką komunikacje TCP bez wysypania stosu co kończyło całą zabawę oraz zdarzało się w losowych momentach programu .
Porównując ESP32 do STM32 , to ESP oprócz wifi niczym więcej nie powala na głowę
Minusy ESP32
-ilość pinów (można dodać ekspander I2C / SPI ) ale przy bazowaniu osi dochodzi delay z odczytu ekspandera co np u mnie (2 śruby kulowe na osi Y ) dawało wynik "tak w miarę ... ale może być lepie ..
-240Hz 2 rdzenie ,tak ale do obliczeń ... , co z tego skoro sam program w FLASH zależnie wg ustawień pracuje max 80MHz
-pamięć RAM 520 KiB (ogółem 320Kb) też d.. nie urywa max wielkość tablicy max 64Kb ponieważ pamięć podzielona jest na sektory
-zależnie od środowiska (arduino/IDF) RTOS zalicza wpadkę i następuje przepełnienie stosu (restart modułu) próbowałem już wszystkiego może inni są lepsi i im się udało osiągnąć stabliną komunikacje , ja zrezygnowałem
- zasięg WIFI teroia 300m ,realia poniżej 4m pink do AP na ESP32 jest <2ms potem to loteria i zależy co mamy dookoła , im większy PING tym komunikacja leży , pracując jako serwer TCP i wysyłaniu danych do klienta (PC) nie otrzymując potwierdzenia ,potrafi w pętle wpaść i się wysypać RTOS
+ RMT ten moduł do silników krokowych jest świetny i pracuje bardzo stabilnie .
Dodane 5 minuty 2 sekundy:
Chciałem z ciekawości zerknąć jak to inni robią ale jako programista nie uznaje UDP protokołu do komunikacji , tym bardziej w takich projektach gdzie wymagam dokładności i pewności że pakiet dotarł do sterownika w TCP nie dodając dla siebie w programie dodatkowo ACK od sterownika .
Przy NVEM więcej jak 400KHz równych impulsów nie wyrabia już ale i tak uznaje jako bardzo dobry wynik .(wpieram się oscyloskopem oraz analizatorem logicznym do weryfikacji programu)
Komunikacja TCP/IP z PC wczoraj po optymalizacji softu na PC rozpędziłem do 300 komend gcode na 1 sekundę do sterownika , obecnie kończę moduł PLC ( wejścia/wyjścia),RS485 do falownika oraz chcę sprawdzić jak wejścia z osobnymi timerami zachowają się jako odczyt enkoderów .
Przy opracowaniu projektu spędziłem sporo czasu (kilka nocek też poświęciłem jak coś mi nie dawało spokoju w prawidłowym działaniu)
migracja GRBL to pryszcz , konfiguracja kodu dla STM + lwip + rtos to już zabrało najwięcej aby uzyskać szybką komunikacje TCP bez wysypania stosu co kończyło całą zabawę oraz zdarzało się w losowych momentach programu .
Porównując ESP32 do STM32 , to ESP oprócz wifi niczym więcej nie powala na głowę
Minusy ESP32
-ilość pinów (można dodać ekspander I2C / SPI ) ale przy bazowaniu osi dochodzi delay z odczytu ekspandera co np u mnie (2 śruby kulowe na osi Y ) dawało wynik "tak w miarę ... ale może być lepie ..
-240Hz 2 rdzenie ,tak ale do obliczeń ... , co z tego skoro sam program w FLASH zależnie wg ustawień pracuje max 80MHz
-pamięć RAM 520 KiB (ogółem 320Kb) też d.. nie urywa max wielkość tablicy max 64Kb ponieważ pamięć podzielona jest na sektory
-zależnie od środowiska (arduino/IDF) RTOS zalicza wpadkę i następuje przepełnienie stosu (restart modułu) próbowałem już wszystkiego może inni są lepsi i im się udało osiągnąć stabliną komunikacje , ja zrezygnowałem
- zasięg WIFI teroia 300m ,realia poniżej 4m pink do AP na ESP32 jest <2ms potem to loteria i zależy co mamy dookoła , im większy PING tym komunikacja leży , pracując jako serwer TCP i wysyłaniu danych do klienta (PC) nie otrzymując potwierdzenia ,potrafi w pętle wpaść i się wysypać RTOS
+ RMT ten moduł do silników krokowych jest świetny i pracuje bardzo stabilnie .
Dodane 5 minuty 2 sekundy:
https://github.com/pekkaroi/ethernetcnc
Chciałem z ciekawości zerknąć jak to inni robią ale jako programista nie uznaje UDP protokołu do komunikacji , tym bardziej w takich projektach gdzie wymagam dokładności i pewności że pakiet dotarł do sterownika w TCP nie dodając dla siebie w programie dodatkowo ACK od sterownika .
Re: Bezprzewodowe Grbl
Jak się zdecyduję to będę mógł pomóc.gothye pisze: ↑11 lis 2020, 16:45STM32F407 czy nvem polecą na github (myślę że ok tyg jeszcze) zostały ostatnie testy , różnica to tylko zmiana pliku nagłówkowego który podmieni postprocesor wg ustawień . na STM32F407 zegar TIM2 można śmiało rozpędzić do 4MHz (pulse 0.125uS ) wiec serwo śmiało wysteruje .
Nie masz na tym problemów ze stabilnością tego ethernetu? Wiem że sporo ludzi narzekało na ten NVEMgothye pisze: ↑11 lis 2020, 16:45Komunikacja TCP/IP z PC wczoraj po optymalizacji softu na PC rozpędziłem do 300 komend gcode na 1 sekundę do sterownika , obecnie kończę moduł PLC ( wejścia/wyjścia),RS485 do falownika oraz chcę sprawdzić jak wejścia z osobnymi timerami zachowają się jako odczyt enkoderów .
Ja apotrzebuję akurat dwie Z
UDP itp. się przydaje jak chcemy mieć szybko ale bez synchronizacji np napędów.gothye pisze: ↑11 lis 2020, 16:45https://github.com/pekkaroi/ethernetcnc
Chciałem z ciekawości zerknąć jak to inni robią ale jako programista nie uznaje UDP protokołu do komunikacji , tym bardziej w takich projektach gdzie wymagam dokładności i pewności że pakiet dotarł do sterownika w TCP nie dodając dla siebie w programie dodatkowo ACK od sterownika .
Jak wszystko ma swoje plusy i minusy.
-
Autor tematu - Specjalista poziom 1 (min. 100)
- Posty w temacie: 22
- Posty: 134
- Rejestracja: 15 kwie 2009, 15:18
- Lokalizacja: Płock
Re: Bezprzewodowe Grbl
Witam po przerwie
Jestem "po wypadkowy" ale wracam do pracy nad modułami
Wiem że ludzie narzekali na NVEM z ETH , wg mnie to wina softu pierwotnego w nim a nie samej warstwy sprzętowej .
Poprawiam cały czas komunikacje TCP -> PC i idzie to coraz lepiej , gdybym miał w tym NVEM jeszcze SDRAM na pokładzie to była by poezja i wisienka na torcie projektu . Sporo spędzam czasu na optymalizacji RTOS i bitów maskowania przerwań ale więcej jak 340 komend gcode na 1 sekundę już nie dam rady . Co przy np wykonywaniu płaskorzeźb uznaje za bardzo dobry wynik .
cubit dzięki za PW odpisałem .
Jestem "po wypadkowy" ale wracam do pracy nad modułami
Wiem że ludzie narzekali na NVEM z ETH , wg mnie to wina softu pierwotnego w nim a nie samej warstwy sprzętowej .
Poprawiam cały czas komunikacje TCP -> PC i idzie to coraz lepiej , gdybym miał w tym NVEM jeszcze SDRAM na pokładzie to była by poezja i wisienka na torcie projektu . Sporo spędzam czasu na optymalizacji RTOS i bitów maskowania przerwań ale więcej jak 340 komend gcode na 1 sekundę już nie dam rady . Co przy np wykonywaniu płaskorzeźb uznaje za bardzo dobry wynik .
cubit dzięki za PW odpisałem .