Niepoprawne działanie sterownika CNC.

[romek-rutkowski]

Cześć,
uruchamiam sterownik CNC na bazie Arduino UNO + Shield z układami DRV8825. Silniki 17HS8401 (ustawiony na 1,66A).
Na początku ustawiłem na pełne kroki (bez podziału = 200), ale silnik wykonuje niecałe 360 stopni (około 330..340).
Co może być tego przyczyną?

Ustawienia w Grbl 0.8c:
$0 = 200.000 (steps/mm x)
$1 = 200.000 (steps/mm y)
$2 = 200.000 (steps/mm z)
$3 = 20 (microseconds step pulse)
$4 = 250.000 (mm/min default feed rate)
$5 = 250.000 (mm/min default seek rate)
$6 = 0 (step port invert mask. int = 00000000)
$7 = 200 (step idle delay, msec)
$8 = 10.000 (acceleration in mm/sec^2)
$9 = 0.050 (junction deviation, mm)
$10 = 0.100 (arc, mm/segment)
$11 = 25 (n-arc correction, int)
$12 = 3 (n-decimals, int)
$13 = 0 (report inches, bool)
$14 = 1 (auto start, bool)
$15 = 0 (invert step enable, bool)
$16 = 0 (hard limits, bool)
$17 = 0 (homing cycle, bool)
$18 = 0 (homing dir invert mask, int:00000000)
$19 = 25.000 (homing feed, mm/min)
$20 = 250.000 (homing seek, mm/min)
$21 = 100 (homing debounce, msec)
$22 = 1.000 (homing pull-off, mm)

[romek-rutkowski]

Dopiszę, że za każdym razem jak wysyłam przesunięcie o 1mm to silnik wykonuje niepełny obrót.

[Avalyah]

A sprawdzasz to bez obciążenia tych krokowców, czy jak są w maszynie? A konkretniej czy powód może być mechaniczny, czy nie.

[romek-rutkowski]

Silniki są poza maszyną, więc bez obciążenia. Ośka silnika obraca się równomiernie bez zasilania.

[Adam Domański]

Dopiszę, że za każdym razem jak wysyłam przesunięcie o 1mm to silnik wykonuje niepełny obrót.

Porób zdjęcia jak to wszystko masz podłączone, poustawiane to może będzie łatwiej coś doradzić bo z tego co piszesz przy zadaniu 1 mm powinien zrobić pełny obrót a nie robi

[tuxcnc]

to może będzie łatwiej coś doradzić

Najpierw to się trzeba zapytać skąd autor wątku wyrwał GRBL v0.8c, czy to na pewno jest v0.8c i po jasną cholerę chce sterować na pełnym kroku.
Bo mi to wygląda na gościa, który zrobił Frankensteina i się dziwi, że on nie żyje...

[romek-rutkowski]

Najpierw to się trzeba zapytać skąd autor wątku wyrwał GRBL v0.8c, czy to na pewno jest v0.8c i po jasną cholerę chce sterować na pełnym kroku.

Zapewne z internetu. Taką wersję odczytuje Grbl Controller, nie pamiętam którą wersję zainstalowałem, ponieważ dopiero teraz mam na to czas.
tuxcnc, mimo Twoich złośliwości, to powiem, że ustawione jest na 200 kroków aby przetestować poprawność sterowania silnikiem. Mikrokrokami zajmę się później (200 czy 6400 dla 1/32, to i tak chcę zobaczyć pełny obrót).

Zdjęcia nie wrzucam, ponieważ obecnie Uno z płytką sterowników DRV8825 leży samodzielnie na biurku z podłączonym silnikiem. Uno zasilam z USB. Drivery dostają zasilanie z zasilacza 24V 5A.

[tuxcnc]

tuxcnc, mimo Twoich złośliwości

Trudno nie być złośliwym, kiedy wszystko robisz źle i oczekujesz od innych pomocy.
Po pierwsze, najnowszy GRBL v1.1h. ma datę wydania 2019.08.25, czyli niedługo będzie miał sześć lat (od tamtej pory nie jest rozwijany, bo możliwości procesora ATmega 328P zostały wykorzystane w całości).
Skąd wyrwałeś ten zabytek 0.8c ???
Po drugie, krokowiec to dwufazowy silnik synchroniczny prądu sinusoidalnie zmiennego i aczkolwiek potrafi stać w miejscu, to bardzo źle znosi zasilanie przebiegiem prostokątnym (skacze, rzęzi i co najgorsze, potrafi zrobić krok w przeciwnym kierunku niż powinien).
Dlatego sterowania pełnym krokiem należy unikać jak ognia.

[romek-rutkowski]

Kolejne wersje były iteracjami, czy poprawiały podstawę obsługi napędów?

Jeśli chodzi o wersje Grbl, to jedynie 0.8 działa stabilnie. v0.9i - nie potrafi zapisywać do EEPROM, a v1.1 działa niestabilnie z Grbl Controller3.6.1.
Z chęcią zainstalowałbym v1.1, ale dlaczego po jednorazowym naciśnięciu przycisku przesuwu, nastawionego na jeden "step size" w oknie podglądu aplikacji zaczynają się ciągle pojawiać nowe dane, a ich koniec następuje dopiero po zamknięciu transmisji/połączenia przez USB?

Dodam, że potem sprawdziłem na kompilacji kodu z mniejszą prędkością UART i sytuacja była podobna.

[tuxcnc]

dlaczego po jednorazowym naciśnięciu przycisku przesuwu, nastawionego na jeden "step size" w oknie podglądu aplikacji zaczynają się ciągle pojawiać nowe dane, a ich koniec następuje dopiero po zamknięciu transmisji/połączenia przez USB?

Miałem takie jaja kiedy z czystej ciekawości spróbowałem sterować GRBL spod Windows...
Nie pamiętam czy to był Grbl Controller czy jakieś inne Candle, ale cyrk był taki, że maszyna jechała dalej nawet po zamknięciu programu...
Widzisz, GRBL ma bardzo prosty protokół komunikacji. Komputer z programem sendera wysyła g-kod i czeka na potwierdzenie jego wykonania. Taka jest teoria, ale w praktyce, szczególnie pod Windows, sender potrafi przepełnić bufory podsystemu USB i wszystko się wywala...
Tyle tylko, że to nie jest wina GRBL.