BŁĘDY w Piko

Zienek pisze:rozłączyć i ponownie połączyć

TAB --- tylda. Trzeba chwilę odczekać przed tyldą (~1s).

Robert

Zienek pisze: W wersji 4.0 jedyną nowością jest to, że pokazuje się mrugający komunikat

Kod: Zaznacz cały

E_STOP: PLC nie pracuje!

Po którym trzeba się rozłączyć i ponownie połączyć ze sterownikiem, żeby go używać.

Rozumiem, że kontroler stracił komunikację – ale po chwili wróciła sama jednak już z powyższym komunikatem ? Czy też było inaczej i konieczne było rozłącznie fizyczne wtyczki USB ?

U mnie tylko podczas włączania. I nie zawsze. Włączam program i od razu TAB, tylda. I raz na dziesięć włączeń pojawia się ten komunikat.
Wtenczas wciskam przycisk ROZŁĄCZ i ponownie TAB, tylda ale chwile przerwy robię przed tyldą.
Może to nie ma znaczenia (przerwa) ale zawsze pomogła.

RObert

Zienek pisze: W wersji 4.0 jedyną nowością jest to, że pokazuje się mrugający komunikat

Kod: Zaznacz cały

E_STOP: PLC nie pracuje!

Miłą informacja, tyle że to i bez komunikatu widać i czuć.
Zastanawiam się, czy Piko wywala się na zakłóceniach czy pada kiedy system operacyjny uruchamia jakieś własne procesy zakłócając (zatrzymując) chwilowo ruch na portach?
Przy następnej okazji założę bezpośrednio na porcie USB aktywny izolator galwaniczny. Mam takich kilka własnego chowu, z przeniesieniem zasilania na stronę izolowaną. I zobaczymy czy to pomoże czy nie.

cosimo pisze:

Zienek pisze: W wersji 4.0 jedyną nowością jest to, że pokazuje się mrugający komunikat

Kod: Zaznacz cały

E_STOP: PLC nie pracuje!

Po którym trzeba się rozłączyć i ponownie połączyć ze sterownikiem, żeby go używać.

Rozumiem, że kontroler stracił komunikację – ale po chwili wróciła sama jednak już z powyższym komunikatem ? Czy też było inaczej i konieczne było rozłącznie fizyczne wtyczki USB ?

To się dzieje w trakcie pracy. Np jakiegoś dłuższego grawerowania.
Szast prast,
maszyna staje, mruga powyższy komunikat,
trzeba się rozłączyć i połączyć ponownie,
zwykle osie, które pracowały prosto przed wystąpieniem błędu gubią swoje koordynaty.

Bo Piko nie pracuje w czasie rzeczywistym. Pecet coś wysyła, sterownik coś wykonuje, coś odsyła do peceta i pecet to wyświetla po tym jak ściągnie z bufora portu szeregowego.
To jest niestety bardzo ułomne i znamienne w skutkach. W startym Sinumeriku analizowanie programu jest "do przodu". Oznacza to, że jeśli w programie jest błąd to egzekucja wywala się wcześniej niż pojawi się linia z błędem. Ale za to, to co jest na ekranie w 100% odpowiada bieżącej pozycji mechaniki. I jak coś stanie to co do mikrona widać gdzie faktycznie nóż stoi.

W Piko odwrotnie - oś, o ile nie ma chwilowego zatrzymania, jest zawsze na bardziej zaawansowanym etapie pracy niż się pecetowi wydaje. Wszystko sprawia POZORY płynności ale efekt jest taki, że jak coś się wywali to jedyne na co można liczyć to b. dobrej jakości bazowanie.

Te stuknięcia w napędach o których pisałem i które czasami daje się usłyszeć, to są chwilowe zawieszenia transmisji. Takie po których transmisja wraca do normy. Zazwyczaj jednak nic nie stuka tylko po prostu od razu staje dęba i na tym koniec pracy.

Po przywróceniu transmisji metodą "mechaniczną", sterownik nie odsyła do peceta faktycznego położenia osi. Pewnie go nawet sam nie zna bo nie liczy na bieżąco. Jeśli się tego nie uwzględni, nie sprawdzi i wznowi pracę, reszta programu wykona się obok. Nawet kilka centymetrów dalej.
Dlatego jeśli przerwa nastąpiła podczas pracy to nawet NIE MA CO PRÓBOWAĆ kontynuować programu bez bazowania wszystkich osi. W tym kontekście "możliwość wznowienia programu po przerwie" jest nieprawdą. Taka możliwość istnieje ale wymaga przede wszystkim świetnego precyzyjnego bazowania. czego prawie nikt nie ma, bo tym się właśnie charakteryzują tanie maszyny, że bazowanie jest powtarzalne "na słowo honoru".

mc2kwacz pisze:"możliwość wznowienia programu po przerwie" jest nieprawdą.

A skąd ten cytat?

Robert

mc2kwacz pisze:...tym się właśnie charakteryzują tanie maszyny, że bazowanie jest powtarzalne "na słowo honoru".

Dla mnie bazowanie w amatorskiej maszynie jest tylko po to, aby ustalić fizyczny zakres pracy osi.
Jeśli zepsuję coś w detalu, lub program się niespodziewanie przerwie (co w przypadku Piko jeszcze mi się nie zdarzyło) z bazowaniem radzę sobie inaczej. Tworzę w jakiejś płytce MDF wybranie pod uszkodzony detal, mocuję go w nim na wcisk i znam dokładne koordynaty.
Niestety sprawdza się to tylko w przypadku regularnych i znanych kształtów.
W przypadku reliefów robiłem sobie odwiert referencyjny z boku materiału, w który po zawieszce wkładałem frez i znałem dość dokładnie pozycję.

RobWan pisze:A skąd ten cytat?Robert

Z forum choć nie musi być dokładny. Kiedyś Gaspar mnie bajerował, że jak prąd wysiądzie to w Piko można wrócić do przerwanej pracy

Wojtek, wybacz ale Twoje podejście jest tak samo amatorskie jak maszyna.
Dla mnie nie akceptowalne. Każda szanująca się maszyna CNC ma porządną referencję. KAŻDA. Amatorska maszyna nie musi być badziewiem ze zgrubnymi czujnikami pozycji. Tym bardziej że zrobienie przyzwoitego bazowania niewiele kosztuje i jego brak jest po prostu dowodem niechlujstwa w podejściu do pracy. Harcerskie metody odzyskiwania pozycji w ogóle mnie nie interesują.
Mnie Piko też kiedyś się nie zacinał. Ale przestał i póki co nie wiem dlaczego.

To się dzieje w trakcie pracy. Np jakiegoś dłuższego grawerowania.
Szast prast,
maszyna staje, mruga powyższy komunikat,

Ok, roześlę dziś nowe FW gdzie time-outy są bardziej liberalne.

Piko wywala się na zakłóceniach czy pada kiedy system operacyjny uruchamia jakieś własne procesy

Jeżeli program sterujący „żyje” i mamy komunikat na ekranie, to znaczy, że timeout-y w kontrolerze zadziałały i może mieć to związek z tym, że komputer zajął się czymś innym niż komunikacja, lub też miał miejsce przypadek opisany na końcu. Natomiast jeśli jest zawiecha totalna – program nie reaguje, to znaczy, że od zakłóceń zablokował się układ obsługujący USB.
Pojawianie się komunikatu w przypadku o jakim pisze RobWan to jeszcze inna sprawa.

Kiedyś Gaspar mnie bajerował, że jak prąd wysiądzie to w Piko można wrócić do przerwanej pracy

A co nie można ? To, że wcześniej trzeba zrobić jazdę referencyjną, zmierzyć narzędzie to chyba oczywiste – więc nie wiem co próbujesz udowodnić. Dobry nawyk wręcz konieczność to zrobić REF po każdym RUN.

Mnie Piko też kiedyś się nie zacinał. Ale przestał i póki co nie wiem dlaczego.

Ostatnio testując kontroler na biurku zerwałem komunikacje trącając kontroler łokciem. Okazało się, że kabel USB w gniazdku kontrolera ma taki luz „na boki”, iż wystarczyło go delikatnie przekrzywić w którąś stronę i już żegnaj komunikacjo. Zacząłem bardziej przyglądać się kablom pod tym kątem i okazuję się, mają spasowanie do gniazda „od sasa do lasa” - dlatego warto poczochrać swoim kablem i zobaczyć jak to jest .