Piko się wiesza?

[mc2kwacz]

Informacja niepokojąca. Miejmy nadzieję że niedługo się wyjaśni.

Nic nie zamierzam nikomu narzucać, nie mój projekt, choć tak samo jak i innych użytkowników - moja sprawa. Uważam że w Piko bardzo dużo się ostatnio zadziało na plus. Ma nowe funkcjonalności od miesięcy albo lat wyczekiwane. Coraz trudniej znaleźć sensowny i uzasadniony pomysł na poprawę funkcjonalności. Mi do głowy przychodzi tylko zrewidowanie algorytmu pomiaru długości narzędzia, co należy do kluczowych potrzeb (konkretny do bólu pomysł przedstawiłem).
Ale do rzeczy. Na tym etapie dla dobra użytkowników należałoby się zatrzymać, przynajmniej na chwilę w rozwoju, zebrać udokumentowane sygnały niepokojące i wyczyścić program z drobnych błędów. Bo wiele osób coś zauważyło. Ja też obserwowałem nienormalne zatrzymania programu, szczęśliwie że na etapie startu.
Pamiętajmy, że co prawda Piko sprzętem profesjonalnym nie jest, ale z racji jakości i możliwości użytkownicy stosują go do obróbki kosztownych materiałów i do profesjonalnych zadań.

Wiem o czym piszę, miałem kiedyś podobny problem organizacyjny z bardzo skomplikowanym projektem, który rozwijał się z prędkością, fizycznie uniemożliwiającą 100% weryfikacje każdej wersji. Tyle że byłem w gorszej sytuacji, bo nie miałem możliwości zablokowania rozwoju w dogodnym momencie. Mimo przemyślanej i modułowej konstrukcji po pewnym czasie "klocki Lego" mogą zacząć do siebie pasować.

[RobWan]

2.2.4 wiesza się przy prędkościach ok 1,9m/min

Ja G0 mam 10 m/min i nie ma problemu w 2.2.4. Poza tym co pisałem wcześniej.

Robert

[mc2kwacz]

Bartas pisał o 1,9m/min a nie o 10m/min. Poza tym nie znasz jego ustawień konfiguracyjnych ani nie pozyskałeś informacji, czy powyżej 1,9m/min też zaobserwował problem. Tak więc brak podstaw do wyciągania wniosków oraz argumentowania.

[bh91]

U mnie występowało przesunięcie - walczyłem długo, upraszczałem wektory i robiłem inne cuda na kiju - raz się oparłem o stół a ten się przesunął - silniki miały hamulec - obadałem sprawę i okazało się, że winą przesunięcia było to, ze nie zamocowałem podkładki przy śrubie podczas któregoś montażu...

Ale obwiniałem najpierw piko - potem komputer, jak sie okazało winna była sama mechanika.

[cosimo]

ten problem ale zauważyłem jedną "prawidłowość" - do wersji softu 2.2.2 nic się nie działo. Dziś na wersji piko 2.2.3 i 2.2.4 wiesza się przy prędkościach ok 1,9m/min , gdy zmniejszę do 1,7m/min problem znika.

Od wersji 2.2.3 oprócz oficjalnych zmian zmieniłem też całkowicie procedury „analizy do przodu” która działa gdy wykonuje się program.(sprawdza gdzie trzeba będzie hamować). Być może, że tu jest coś nie tak. Za parę dni zamieszczę jeszcze jedną aktualizację i przywrócę stare wersje tych procedur i zobaczymy. Puki co do samego frezowania można wersji wcześniejszych używać – jeśli ktoś nie czuje się pewnie.

wiesza się przy prędkościach ok 1,9m/min , gdy zmniejszę do 1,7m/min problem znika.

Wiesza się w jakim sensie? Cały program, czy silniki w poślizg wpadają ? Jaki masz „kąt hamowania” ustawiony ? Jeśli więcej niż 10 to zmniejsz

Co do kolegi antharax na razie nie mam koncepcji. Nie wykluczam jakiś hardwarowych problemów. W każdym razie dobrze jakby zwrócił uwagę na przebieg transmisji (w okienku monitora) czy liczba ramek w normie (62) i co pokazują liczniki błędów.

I jeszcze na temat prędkości w programach – muszę uczulić na pewną sprawę:
Jeśli np. dla osi X oraz Y mamy w ustawieniach prędkość maksymalną 4000 ale dla osi Z mamy tylko 2000 - To nie możemy (a raczej nie powinniśmy) w programie ustawiać większego F niż najwolniejsza użyta oś ! Tzn. nie ma problemu gdy X i Y jadą razem lub same tzn. bez Z - wtedy F może być 4000, natomiast jeśli jedzie np. X razem z Z to F nie powinno być większe niż 2000 ! Oczywiście nie dlatego, że oś Z pojechałaby szybciej niż ma w ustawieniach – nie pojedzie. Ale dlatego, że przestaje wtedy prawidłowo działać „analiza do przody” (pewną analogią jest tu przesterowany wzmacniacz) i ryzykujemy, że na jakimś zakręcie silniki wpadną w poślizg i pogubią krok. To samo dotyczy procentowego przyśpieszania.

[mc2kwacz]

Cenna uwaga, ale zauważ że to powinna być funkcjonalność programu. Jeśli dajesz do dyspozycji jakieś parametry, i użytkownik w dobrej wierze z nich skorzysta, to te parametry powinny bezwzględnie poprawnie zadziałać. Jeśli jest jakieś ograniczenie wzajemnego powiązania parametrów, to program powinien sam zadbać o to, żeby wprowadzić ograniczenia prowadzące do poprawnego działania. I zasadniczo powinien też poinformować o ograniczeniu (niespełnieniu założeń użytkownika). Bo przecież obroty narzędzia są dość ściśle związane z posuwami.
Wydaje się, że najprostszym sposobem jest wbudowanie filtra nastaw na etapie ich wprowadzania. Zarówno w ustawieniach sterownika jak i ustawieniach cama. Nie jest to filtr skomplikowany, w końcu chodzi jedynie o 3 prędkości liniowe i obroty.

Użytkownik musi mieć zaufanie do sprzętu. Rozgarnięty konstruktor maszyny wie co może silnik, cała oś, sterownik silnika. Tak samo powinien mieć pewność co może Piko, bo nie można go obciążać obowiązkiem eksperymentowania wobec rzeczy które powinny być czarno na białym napisane. Bo może dojść do kuriozalnej sytuacji, jak kiedyś w przypadku użytkownika, który naciskając sobie dla zabawy na przyciski na panelu kuchenki mikrofalowej wprowadził ją w stan fabrycznej blokady a serwis oskarżył go o uszkodzenie pozagwarancyjne ))

Mnie też nie raz zastanawiało co będzie, jak ustawię różne prędkości i różne przyspieszenia na różnych osiach. Ponieważ nie mam mentalności badacza i dyskutanta zjawisk paranormalnych, więc zawsze mam ustawienia dopasowane do najsłabszej osi i jednakowe we wszystkich osiach. Ale to mój intuicyjny wybór. Program zaś umożliwia wiele, w zasadzie wszystko.

P.S. jestem niemal przekonany, że problemu kolegi antharaxa nie da się rozwiązać korespondencyjnie. A rozwiązać się z pewnością przecież da.

[bh91]

No właśnie mnie jedyna rzecz jaka w piko drażni to rozsiew informacji - część jest na forum, część w manualu, troche w newsach na stronie i trzeba czasem się ostro naszukać. RobWan zna bardzo dobrze sterownik i zna odpowiedź na większość dolegliwości w moim przypadku

Pozdrawiam kolegę!

[bartas4]

wiesza się przy prędkościach ok 1,9m/min , gdy zmniejszę do 1,7m/min problem znika.

Wiesza się w jakim sensie? Cały program, czy silniki w poślizg wpadają ? Jaki masz „kąt hamowania” ustawiony ? Jeśli więcej niż 10 to zmniejsz

Wiesza się program-staje się martwy i nie można nic zrobić... Nawet przy tak prostym programie jak planowanie stołu-zrobi kilka/kilkanaście linii g-kodu i zawiecha (oczywiście przy 1,9m/min bo przy 1,7m/min śmiga normalne skomplikowane programy).
Sterowanie niewygórowane to fakt bo zestaw to PIKO + SSK-B01 x3, zasilacz MZ-01 i trafo 230V/25V z krokowcami 1.9Nm 2,8A , sterowanie 1/2 kroku ale do poprzednich wersji softu nie było problemu.

A kąt hamowania mam ustawiony na 4


Pozdrawiam

[mc2kwacz]

Pewnie dużo łatwiej będzie kolegom jeśli sprecyzujesz to co zauważyłeś. A czy przy 1,8m/min i przy 2,0m/min też się nie zawiesza?

[cosimo]

Wiesza się program-staje się martwy i nie można nic zrobić...

Doprecyzujmy co się wiesza program czy kontroler... Da się normalnie zamknąć program ? Jedna z LED koła gniazdka USB błyska jakiś raz na sekundę ?
Czy to się dzieje zawsze automatycznie jeśli przekroczysz prędkość czy jest w tym też jakiś przypadek?

Próbowałeś wrócić do starszej wersji i sprawdzić czy faktycznie zjawisko nie występuje ?
Gdybyś podesłał mi swój plik config byłbym wdzięczny.

zatrzymać, przynajmniej na chwilę w rozwoju, zebrać udokumentowane sygnały niepokojące i wyczyścić program z drobnych błędów

Jeszcze na dniach jedna aktualizacja i przerwa na dwa miesiące – najwyżej poprawki.