Wgrałem program do STM32F103 wytworzony na stronie https://svn.io-engineering.com:8443/
Konfigurację na powyższej stronie zgodnie z informacjami z neta, jednak po podłączeniu przez USB do laptopa (Windows) otrzymuję komunikat o nieznanym urządzeniu.
Czy z Bluepill'ami jest problem z utworzeniem połączenia USB w grblHAL?
Czy do laptopa trzeba jednak podłączyć przez przejściówkę USB-UART?
Wybierałem w konfiguracji: Native USB i Virtual.

Wybiorę jedną z nich, a na teraz potestuję działanie 3 osi na STM32F103. Zakładam, że wystarczy do STM32F103 wgrać skompilowany program z gita...

Mam pod ręką kilka płytek z STM32. Obecnie niewykorzystana leży z STM32F103, czy na niej można zrobić sterownik do 4 osi?
Znalazłem na stronie https://github.com/pvico/grbl32 niejednoznaczną informację o obsłudze do 6 osi, ale w pierwszym punkcie pisze, że 3 osie.

Do jakich częstotliwości można wysłać sygnał do silników dla tak słabego mikrokontrolera?

Tylko, że piszę o kilku wysłanych bajtach g-codu, które nie zatkałyby byfora.
Poza tym, dlaczego v1.1 miałby gorzej współpracować z bałaganem Windowsa niż wersja 0.8?

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 pisze: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.

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

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

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)