GRBL na arduino - szarpie i zawiesza się

drzasiek90 · Post napisał: **drzasiek90** » 10 kwie 2022, 19:29

Może i czary mary ale jednak nie to

Ciekawostka jest taka, że maszyna zawsze miała podłączone uziemienie, ale do tej pory (czyli przez długi czas gdy działała oraz przez pewien czas jak zaczęły się kłopoty) podłączona była przez przedłużacz, który miał "bolec" a co się okazało, nie miał przewodu uziemiającego, taki chiński myczek, dowiedziałem się o tym teraz jak szukałem przyczyn już wszędzie.
Tak więc przez sporo czasu bez podłączonego uziemienia działała, potem zaczęły się kłopoty. Wymieniłem przedłużacz na prawidłowy, kłopoty nie minęły

Czary mary.

nitroactive2 · Post napisał: **nitroactive2** » 11 mar 2023, 11:49

Witam,
Troszeczkę odkopię temat, bo u mnie podobnie się dzieje... Program leci, wszystko OK, po kilku minutach zawiesza się na losowym wierszu. Sterownik Blackbox x32, GRBL 1.1 Hal . W Openbuilds control mam takie komunikaty jak na załączonych zdjęciach. Co może nie grać ? Kabel USB nie wyrabia z transmisją? Dodam że problem choć losowy, to za każdym razem pojawiał się przy dość specyficznej operacji, przypominającej trochę frezowanie trochoidalne, gdzie widzę że przesyłana jest duża ilość punktów w ciągu ułamka sekundy. Opóźnienia w przesyłaniu danych i zawieszanie ? Co myślicie?

Drugie pytanie, blackbox X32 ma złącze ethernet. Ono służy do komunikacji z OBC? Może zastąpić komunikację przez USB za pomocą Ethernet? Jak to wygląda w praktyce? Ewentualnie jeszcze opcja karty SD...

Obrazek

tuxcnc · Post napisał: **tuxcnc** » 11 mar 2023, 12:26

nitroactive2 pisze: ↑
11 mar 2023, 11:49
Kabel USB nie wyrabia z transmisją?

Przywaliłeś jak audiofil...
Może powinieneś kupić pozłacany kabel z miedzi kierunkowej i go przesłuchać?
A tak na poważnie, to spróbuj na Linuksie i z innym oprogramowaniem (do GRBL jest całkiem sporo).
Co prawda twojego sterownika nie znam i z uwagi na cenę nie poznam nigdy, ale z Windows+GRBL miałem kilka doświadczeń i wszystkie były nieprzyjemne.
Otóż, teoretycznie, nie powinno wysyłać się następnej linii przed wykonaniem poprzedniej.
Procedura jest taka, że wysyła się linię i czeka na potwierdzenie "ok". Natomiast w Windows transmisja jest z zasady buforowana i miałem już takie jajca, że zamykałem program sterujący na PC, a maszyna jechała dalej jakby nigdy nic...
Te linie zaczynające się od "Idle" to nie jest żaden błąd, tylko informacje dla programu sterującego, w jakim stanie i w jakiej pozycji jest maszyna. Natomiast nie jestem w stanie powiedzieć dlaczego są wyświetlane zamiast kolejnego "ok". Przepełnienie jakiegoś bufora byłoby odpowiedzią...
Natomiast, jak pisałem wcześniej, tzw. "lagi", czyli zacinanie się transmisji nie spowoduje zawieszenia GRBL, bo on czeka na kompletną linię i dopiero po jej otrzymaniu, w całości, przystępuje do jej wykonania. Na wybitnie kiepskim komputerze frezarka dostanie czkawki i będzie szarpać, ale program będzie szedł...

nitroactive2 · Post napisał: **nitroactive2** » 13 mar 2023, 10:33

tuxcnc pisze:Przywaliłeś jak audiofil...

Zgadłeś

lubię posłuchać muzyki...

Ale tak zupełnie poważnie chodziło mi nie o to że kabel USB za 500 zł będzie szybszy od kabla USB za zl 30, tylko o to czy komunikacja przez Ethernet`owy kabel nie byłaby lepsza. Z tym że z tego co czytałem w instrukcji to ten port ethernet jest do podpięcia akcesoriów typu interfejs sterujący osiami.

Wczoraj puszczałem ten program "na sucho" i za każdym razem utknął w innym miejscu, raz przejechał niemal całość (jakieś 90% linii kodu), innym razem ledwo 2 minuty i już stop. Nie mam pojęcia co jest. Skończyły mi się pomysły, czy problem leży w sterowniku (już się kopałem bo to jest drugi sterownik, pierwszy reklamowałem i czekałem 3 miesiące na nowy egzemplarz), sofcie, czy sprzęcie (laptop/ kabel). Jedyne co mie jeszcze przychodzi do głowy to zainstalowanie Ubuntu na laptopie i OBC w wersji na linuxa. Kabel sygnałowe do silników krokowych są ekranowane, wszystko uziemione...

tuxcnc · Post napisał: **tuxcnc** » 13 mar 2023, 11:05

nitroactive2 pisze: ↑
13 mar 2023, 10:33
Jedyne co mie jeszcze przychodzi do głowy to zainstalowanie Ubuntu na laptopie i OBC w wersji na linuxa

To Ci powinno przyjść do głowy jako pierwsze.
Z tym, że powinieneś wypróbować też inne oprogramowanie do sterowania GRBL, którego jest całkiem sporo.
Windows od wersji XP zabrania bezpośredniego dostępu do portów, a USB to już w ogóle inna bajka.
Jak już pisałem, w GRBL jednostką transmisji jest linia g-kodu. Wysyła się pełną linię i czeka na potwierdzenie zanim wyśle następną, W Windows chyba tak nie można, bo by działało zbyt wolno. (To takie moje przypuszczenie, bo nie mam potrzeby ani ochoty tego sprawdzać). W każdym razie z czystej ciekawości próbowałem sterować GRBL z poziomu Windows i efekty były takie, że nigdy więcej tego nie zrobię...
Podłączenie innego komputera z innym systemem operacyjnym i innym oprogramowaniem sterującym powinno dać odpowiedź na pytanie, czy przyczyna problemów leży w sterowniku.
Ja do GRBL używam Ubuntu i bCNC. Robię różne rzeczy, kompiluję własne wersje GRBL, testuje różne znalezione w necie, i jak coś się pieprzyło, a zdarzało się to często, to nigdy bCNC nie był tego przyczyną, dlatego mam do tego programu zaufanie i go polecam.

nitroactive2 pisze: ↑
13 mar 2023, 10:33
Z tym że z tego co czytałem w instrukcji to ten port ethernet jest do podpięcia akcesoriów typu interfejs sterujący osiami.

Co by znaczyło, że to nie jest Ethernet, a jedynie użyto takiego samego gniazda, co się czasem zdarza...

nitroactive2 · Post napisał: **nitroactive2** » 13 mar 2023, 11:10

OK, zainstaluję, sprawdzę i dam znać jakie efekty.

nitroactive2 · Post napisał: **nitroactive2** » 16 mar 2023, 14:53

A więc tak, jest połowiczny sukces. Zainstalowałem Ubuntu+ OBC, i udało się dojechać do końca programu. Natomiast problem nie został wyeliminowany, bo w trakcie pracy były 3 zacięcia, jednak w przeciwieństwie do pracy na Win, przy zacięciu pomagało kliknięcie "pause program" a następnie "resume", i program ruszał dalej. Tak więc sukces połowiczny, chyba czas spróbować innego laptopa no i sender oczywiscie.

tuxcnc · Post napisał: **tuxcnc** » 16 mar 2023, 18:23

nitroactive2 pisze: ↑
16 mar 2023, 14:53
czas spróbować innego laptopa no i sender oczywiscie.

Laptop może , choć nie musi, być wystarczający.
Prawdziwym problemem może być program na PC, szczególnie kiedy wieloplatformowość sprowadza się do napisania programu pod Windows i zmuszenia go do pracy pod Linuksem...

nitroactive2 · Post napisał: **nitroactive2** » 04 gru 2023, 13:55

Jeszcze raz odkopię temat, moje problemy nie ustały, co wiecej teraz już praktycznie nic nie można zrobić. Uruchomienie wrzeciona i od razu wszystko świruje. No i właśnie to dało mi do myślenia. Wygląda na to że problem leży w samym wrzecionie i/ lub falowniku. Jeśli puszczę program na sucho bez wrzeciona (usuwam m3 i m5 z programu ręcznie) to wszystko działa bez większych problemów. Ale jeśli tylko włączę wrzeciono komputer traci kontakt z maszyną praktycznie za każdym razem. Cały ploter w tym momencie jest już bezużyteczny.

Odłączyłem też samo wrzeciono od falownika i puściłem program bez usuwania M3 i M5. Program "załączył " (słychać falownik, i częstotliwość rosła) ale samo wrzeciono fizycznie nie pracowało. I teraz czy mogę założyć że falownik tutaj nie jest przyczyną EMI, czy jednak takie odłączenie wrzeciona niczego nie przesądza? Chodzi o to czy źródłem zakłóceń (bo chyba to jest przyczyna) jest samo wrzeciono czy również falownik?

atom1477 · Post napisał: **atom1477** » 04 gru 2023, 20:07

Źródłem jest falownik. Wrzeciono nie ma w sobie nic co by generowało zakłócenia.
Wrzeciono jedynie promieniuje zakłócenia generowane przez falownik.
Zakłócenia mogą też być promieniowane przez przewody.
Ale żeby jakieś zakłócenia były, to musi być prąd. Odłączając wrzeciono sprawiłeś że falownik pracuje bez obciążenia, czyli nie daje prądu.
Wykluczyłeś jedynie że zakłócenia nie są napięciowe (napięcie falownik daje zawsze, tzn. PWMa na wyjściach).

Jak tylko tuxcnc skomentuje że napisałem same bzdury, i będziemy mogli myśleć co dalej zrobić z Twoim problemem.
Na początek napisz jak długie są przewody, i czy są ekranowane.

GRBL na arduino - szarpie i zawiesza się

Re: GRBL na arduino - szarpie i zawiesza się

Re: GRBL na arduino - szarpie i zawiesza się

Re: GRBL na arduino - szarpie i zawiesza się

Re: GRBL na arduino - szarpie i zawiesza się

Re: GRBL na arduino - szarpie i zawiesza się

Re: GRBL na arduino - szarpie i zawiesza się

Re: GRBL na arduino - szarpie i zawiesza się

Re: GRBL na arduino - szarpie i zawiesza się

Re: GRBL na arduino - szarpie i zawiesza się

Re: GRBL na arduino - szarpie i zawiesza się

Szyna liniowa HIWIN MGNR12 0069 mm

Bit Standard, TORX, C 6.3, T20 WIHA

Szyna liniowa HIWIN MGNR12 0069 mm

Bit Standard, TORX, C 6.3, T20 WIHA

Zaloguj się • Zarejestruj się

Połącz się z kontem sieci społecznościowej