BŁĘDY w Piko

[kalreg]

Bardzo dziekuje za odpowiedz - troszke rozjasnila problem choc nie mam jeszcze na nie rozwiazania.

Poki co na forum Solidcama zapytalem o dzielenie kola na czesci - mam nadzieje ze SolidCam ma taka opcje. Kiedy planujesz wypuscic nowsza wersje ktora bierze pod uwage wykonanie pelnego kola?

Jesli chodzi o G41/G42, niestety jestem zbyt poczatkujacym uzytkownikiem frezarki by odpowiedziec na to pytanie. Wiem ze w solidcamie mozna wybrac w operacji profila czyli tej ktorej uzywam kompensacje prawa, lewa i center. Nie sprawdzalem tego jeszcze bo domyslna jest lewa, czy center nie werznie mi sie w frezowany obiekt na szerokosc promienia frezu.

Co do G54 G90 - nie wiem czy te komendy wykonuja sie ale zasadniczo reszta programow dziala dobrze wiec byc moze szczesliwie piko je ignoruje.

Tak czy inaczej dziekuje za szybka odpowiedz.

[Pablonator]

Chyba przechwaliłem. Dzisiaj kolejny frez odszedł do krainy wiecznego frezowania w maśle.

Cześć,
Czy komuś udało się rozwiązać problem opisany na 20 stronie wątku?
Po ponad pół roku bezawaryjnego korzystania z PikoCNC nagle zaczęły się pojawiać problemy z osią Z i Y - znienacka maszyna gubi (lub przestawia sobie) współrzędne w których się znajduję - oczywiście kończy się do kolizją z imadłem i/lub obrabianym przedmiotem.
Wersja PikoCNC 4.3.4 R4.
Problem pojawił się czterokrotnie: dwukrotnie podczas prymitywnej obróbki (praktycznie obróbka po prostych liniach z przesunięciami w osiach min. 1mm), a także dwukrotnie podczas bardzo zagęszczonej obróbki wykończającej.
Upatrywałbym się przyczyny w komunikacji PC - PikoCNC i pominięciu kilku linijek Gcodu, gdyby nie fakt, że w drugim przypadku kiedy obróbka była bardzo dokładna i skok osi Z wynosił 0,02mm, wrzeciono zanurkowało w materiał na jakieś ~8mm (czyli tak naprawdę poza zakres który miał być obrabiany) ..
Gdy drugi raz puściłem program - problem nie wystąpił..

Z góry dzięki za podpowiedzi gdzie szukać problemu!

[RobWan]

wrzeciono zanurkowało w materiał na jakieś ~8mm

Czyli po tym powinieneś zrobić REF, POMOC, MONITOR. I Z była nieprzesunięta?

Robert

[Pablonator]

Z i Y były przesunięte - sterując osiami w manualu dojeżdżały do samego końca po czym wyjeżdżały poza zakres (przeskakiwały na sprzęgle), mimo że współrzędne na monitorze mówiły co innego.
Po ponownym bazowaniu na REF i ustawieniu na czujnik wszystkie osie zatrzymują się na limitach.

Położenie freza na monitorze zgodne z Gcodem, w rzeczywistości przesunięte całkowicie gdzieś indziej. Program jest kontynuowany poprawnie, tyle że w innym położeniu..

[RobWan]

To wygląda na zwykłe gubienie kroków. Szukałbym nie po stronie Piko.
Jak już pewnie kilka razy pisałem miałem tak samo. Winny słaby silnik w ciężkiej Z-etce.

Robert

[Pablonator]

Sęk w tym że dwie osie uciekły na raz,
Druga sprawa, przeanalizowałem przed momentem program i w dość sporej okolicy kodu gdzie wystąpił problem, nigdzie nie było Z przejazdowych które nawet gdyby zostały ucięte w połowie wykonywania pozwoliłyby osi na zjazd znacznie niżej.
Z tego powodu też raczej wykluczyłbym komunikację PC-maszyna.

Nie mówię że silnik nie jest za słaby, ale jeśli tyle czasu wszystko chodziło jak należy i przy obróbce wykończającej gdzie nie ma praktycznie obciążenia osi i wrzeciona występuje problem, a w programach przy siedmiokrotnie większym obciążeniu problemu nie ma, zaczynam kombinować. Prędzej upatrywałbym się przyczyny sterowniku silników - postaram się to w jakikolwiek sposób zweryfikować.

Ogólnie wygląda mi to na jakieś zakłócenie, które leci do sterownika i podaje mu inne współrzędne niż te które powinno dostać..

[oprawcafotografii]

Sęk w tym że dwie osie uciekły na raz,...

No to może zasilacz nie wydolił i obie osie pogubiły się jednocześnie?

q

[RobWan]

Wersja PikoCNC 4.3.4 R4.

Spróbuj 441. Jest w niej jakaś zmiana, która likwidowała gubienie kroków w szczególnych przypadkach.
Ale raczej działoby się to za każdym razem w tym samym miejscu g-kodu.

Robert

[Pablonator]

No to może zasilacz nie wydolił i obie osie pogubiły się jednocześnie?

Jedna z głównych opcji które biorę pod uwagę, ale nie mam co do tego żadnego potwierdzenia, bo zgubienie nastąpiło przy praktycznie zerowym obciążeniu. Oznaczałoby to że przy grubych przejściach problem powinien występować częściej, a do tej pory się z tym nie spotkałem.
Również mając na uwadze szafę sterującą dołożyłem jej chłodzenie żeby zbić temperaturę - nie pomogło.

Spróbuj 441.

Z tego co czytałem, 4.4.1 to głównie zmiany w CAM (z którego nie korzystam), zmiany odnośnie gubienia kroków były właśnie w 4.3.4 z którego korzystam.


Jest jeszcze jedna rzecz której nie wziąłem pod uwagę, a może mieć powiązanie z problemem.. Jakieś półtora miesiąca temu delikatnie dociągnąłem śrubę kulową w osi Y (1/8, albo 1/4 obrotu, nie pamiętam dokładnie).. Po skręceniu wszystko chodziło w porządku, ale próbuję teraz powiązać fakty, bo problem który mnie spotkał miał miejsce w ostatnich dniach kiedy były upały (temperatura otoczenia pracy maszynki 28°C) - nie wiem na ile różnica kilku stopni temperatury może mieć wpływ na jeszcze większe tarcie śruby/łożyska, ale za chwilę biorę się za ponowne wyluzowanie osi Y.
Brakuje mi w tym wszystkim jeszcze zgubionej pozycji Z.. ale przy okazji sprawdzę również czy śruba na Zcie nie jest zbyt ciasna..
Potestuje i dam znać!

[RobWan]

Z tego co czytałem, 4.4.1 to głównie zmiany w CAM (z którego nie korzystam), zmiany odnośnie gubienia kroków były właśnie w 4.3.4 z którego korzystam.

W 441 usunięty jest filtr wektorów śmieciowych, który powodował gubienie kroków w jakichś okolicznościach.

Robert