Piko + miniserwo = ...

Jakie tam masz drivery silników? Dla Leadshine jest konfigurator. Z błędami, do tego na Ebmia jest nieaktualna instrukcja pisana na dodatek przez kogoś kto ma bardzo mętne pojęcie o regulatorach Ale jest.
W programie można testować w dowolny sposób oś, aż do bodaj 5000r/s2 (!). Prędkości też takie dostępne, że strach włączyć Cenną cechą programu jest okno monitora w formie oscyloskopu, w którym widać zarejestrowane odchyłki pozycji. Może się przydać, kiedy serwo jest za słabe do bezwładności maszyny i trzeba się ograniczać. W normalnym wypadku nie ma co grzebać w parametrach regulacji, bo są optymalne.

Przechodząc na miniserwa wybrałem inną koncepcję okablowania, celem zmniejszenia zakłóceń i ograniczenia ryzyka awarii przewodów: drivery enkoderowe są przy silnikach. Tylko zwykłe klekoty M542 zostały na kupie, przy zasilaczu.

Informacja dla czytających co drugie zdanie w co trzecim poście:
PROBLEM PRZYSPIESZANIA PODCZAS CIĘCIA JEST ROZWIĄZANY W FIRMWARE 2.0.4.
TEN TEMAT MOŻNA UZNAĆ ZA ZAMKNIĘTY.

Poniżej analiza dynamicznej pracy Piko, A NIE DYSKUTOWANIE PROBLEMU.
(Pomijając zalecenie skorygowania dynamiki na krańcówkach)

Pewnie parę osób zainteresuje. Poniżej odpowiedź serwa hybrydowego zabudowanego na maszynie dla różnych parametrów przyspieszenia i prędkości.
1 krok błędu = 1um błędu położenia (teoretycznie, przy braku luzów i idealnie sztywnej maszynie). Mierzony silnik osi Y porusza masywną bramą. Zobrazowany ruch, to naprzemienne przesuwanie w przeciwnych kierunkach z krótką przerwą w spoczynku.
Większość wykresów dla sterowania przez program konfiguracyjny. Niektóre dla sterowania z Piko. Na koniec wykres wykazujący przyspieszenie ok 6m/m2 w cyklu bazowania home w Piko, podczas gdy maksymalne przyspieszenie ustawiane w Piko wynosi 2m/s2.

0.5m/s2 , 1000mm/min , test config


1m/s2 , 1000mm/min , test config


1m/s2 , 4000mm/min , test config


1m/s2 , 4000mm/min , Piko


2m/s2 , 1000mm/min , test config


2m/s2 , 3000mm/min , test config


2m/s2 , 4000mm/min , Piko (max. akceleracja w Piko)


3m/s2 , 3000mm/min , test config


Bazowanie HOME w Piko, szacowane przyspieszenie 5..6m/s2 !

Jak widać na obrazkach, Piko z firmware płytki 2.0.4 ładnie steruje silnikami. Niewielka, akceptowalna oscylacyjność na zboczach wynika z 1kHz cyklu realizacji przyspieszenia. Aby nie było jej wcale, cykl sprzętowy przyspieszania musiałby być skrócony około 3x co najmniej. Ale tu jest dobrze i nie musi być lepiej.
Problemy pojawiają się na "przejazdach technicznych", kiedy Piko nie słucha nastaw użytkownika lecz steruje silnikami wg własnego uproszczonego widzimisię. Wtedy przyspieszenia osiągają niekontrolowanie duże wartości co nadwyręża maszynę.
Agresywne przejazdy techniczne generują średnio 2,5..3x większe błędy w serwach. Z ich powodu nie można ustawić błędu bezpieczeństwa na 50, tylko aż 150[um].
Nie wiem, czy cosimo już tu czegoś nie poprawił, bo mam wrażenie że jest lepiej niż było w 2.0.8. Ale nadal są piki podchodzące pod 100 mikrokroków.
I nie ważne gdzie konkretnie pik występuje, czy na starcie, czy hamowaniu, w jedną czy drugą stronę. Jego wystąpienie powyżej progu alarmowego powoduje błąd serwa i zatrzymanie całego systemu. Jedyna droga wyjścia z błędu serwa to wyłączenie zasilania maszyny...
Przy zastosowaniu zwykłego silnika, w miejscu gdzie wystąpił pik na ostatnim wykresie, doszłoby do wystąpienia błędu o wartości ~1/70 obrotu w więc do przeskoczenia do sąsiedniego położenia synchronizmu, CZYLI DO ZGUBIENIA 4 PEŁNYCH KROKÓW. Na śrubie o skoku 5mm odpowiada to odległości 0.1mm

A jaką masz prędkość najazdu na krańcówki, i ewentualnie czy jej zmniejszenie nic tu nie zmienia?

Prędkość najazdu 2500, zjazdu 100. Nie mogę zmniejszyć prędkości najazdu, bo przy stole o przekątnej > 1metra, będę czekał pół godziny aż osie dojadą na przeciwległy (nieużytkowy) koniec z krańcówkami i czujnikiem.
I tak jest to 2x mniej niż mam na JOG-u ustawione i 2x mniej niż G0.
Ale zrobię próbę przy 1000, 500, i napiszę jak wyszło. Właściwie to nie bardzo wiem, w którym miejscu to się dzieje, bo tam wszystko się odbywa bardzo szybko dojazd, zatrzymanie, zjazd. Liczyłem, że sam będziesz wiedział, gdzie jest najbardziej "ostro".
Ok, określę w którym konkretnie momencie co się dzieje.

[ Dodano: 2013-10-20, 01:39 ]
Więc tak:
Udar mechaniczny pojawia się w momencie wyhamowania na krańcówce.
Siła tego udaru jest mniej więcej proporcjonalna do prędkości najazdu, ale tylko w zakresie prędkości do ok. 2000 mm/min. Powyżej udary wyglądają na stałe. Nie wiem, czy to zasługa Piko czy zabezpieczeń a raczej parametrów regulatora miniserwa. Obstawiam to drugie. Nie zauważyłem żadnego wpływu zmiany "kąta hamowania" z 30 na 10, na wynik pomiaru przeciążenia.

Tak więc, jeśli to możliwe, warto ZMNIEJSZYĆ PRĘDKOŚĆ NAJAZDU DO CO NAJWYŻEJ 1500. WTEDY PROBLEM NIE WYSTĘPUJE - jest akceptowalnie mały.
Jeśli ktoś nie może lub nie chce czekać długo na zbazowanie, wtedy powinien zmniejszyć prędkość najazdu mimo wszystko, i dla przyspieszenia operacji dojeżdżać szybko ręcznie w okolice krańcówek i dopiero wtedy uruchamiać bazowanie.

Maksymalne błędy na wykresie sięgają 75, ale wszystko wskazuje na to, że realne piki są wyższe. Dlatego, że serwo ustawione na 100 po kilku próbach parkowania jednak resetuje się. 150 za to jest wartością bezpieczną z punktu widzenia zawieszania serwa i koniecznego po tym resetu maszyny. Można przyjąć, że 2x tyle ile widać na wykresie jest dopiero wartością bezpieczną dla niezawodności i ciągłości pracy.

Zjazd do czujnika odbywa się z dużą prędkością, ale już nie ma tu pików przeciążeniowych. Zapewne więc są wykorzystywane parametry dynamiki zadane przez użytkownika.

Średnie wyniki błędu (pik na wykresie) spowodowanego gwałtownym hamowaniem dla różnych prędkości najazdu:
500 - 8
1000 - 16
1500 - 28
1700 - 40
1900 - 55
2000 - 70
powyżej b.z.
Podczas normalnej pracy, nawet z największymi przyspieszeniami i prędkościami, błędy podczas przyspieszania/hamowania nie przekraczają 25. Tak więc ostre hamowanie na czujnikach jest pewnym problemem wartym rozwiązania.

Ja mam ustawione najazdy na 500 i problemu niema. Inna sprawa że bazowania dokonuje zawsze wciskając strzałki z SHIFTem i docieram blisko pomiarowych krańcówek. Taki pomiar robię raz dwa razy na dzień więc to nie problem.

Jedyne co było by ciekawe to gdybym mógł się dowiedzieć o ile przestawiła się maszyn od stanu zerowani np w logach mogło by się wyświetlić po kolejnym zerowaniu jaka jest różnica

Jedyne co było by ciekawe to gdybym mógł się dowiedzieć o ile przestawiła się maszyn od stanu zerowani np w logach mogło by się wyświetlić po kolejnym zerowaniu jaka jest różnica

W monitorze, w pierwszej zakładce "Bazowanie" to właśnie informacje o ile rozjechały się osie

Mitek, dzisiaj zupełnie przypadkowo natknąłem się na wątek "prehistoryczny", z czasów kiedy nie tylko mnie tu nie było jako zarejestrowanego forumowicza ale nawet nie było działu Piko. Wątek był między innymi o tym, ze test taki fajny sterownik i że powinien mieć swój dział. Pamiętam już wtedy zachwyty nad Piko, w tym wypowiedź Twoją i Gaspara.
Zupełnie bez złośliwości - Piko wtedy raczkowało, błędów było znacznie więcej niż dziś, w tym tragiczny 100-hercowy cykl przyspieszenia, DOPIERO NIEDAWNO POPRAWIONY. Tymczasem były same zachwyty nad działaniem i nikt z użytkowników nie zauważył nawet, że Piko realnie nie przyspiesza, tylko dosłownie rzęzi/charczy na starcie i podczas hamowania.
W ostatnich tygodniach było podobnie. Co włączałem Piko, to znajdowałem kolejny błąd. I żadnego śladu zgłaszania tego przez innych użytkowników. Powiedzmy, że zrozumiem rzadkość używania plików STL i jeszcze większą rzadkość świadomego kontrolowania przez userów PC-tów ustawień grafiki. Ale poważny błąd w braku obrotów po pauzie (tu akurat ktoś JEDEN potwierdził, że zauważył), czy hamowanie na zderzakach?

Zmierzam do tego, że nie ważne co komu w działaniu przeszkadza a co akurat nie. Skoro ten dział służy jako feedback dla autora, to każda niedoskonałość działania jest czy raczej powinna być przedmiotem uwagi i tematem do zastanowienia. Mniejsza o późniejsze wnioski, ale zastanowić się trzeba. Bo jak rozumiem (a może się mylę), chodzi o to żeby sterownik i jego oprogramowanie osiągnęły stan dopracowania i nie wymagały "kombinowania" przez userów, jak uniknąć konfliktów z jego niedostatkami.
Flaki mi się przewracają na lewą stronę, jak czytam wypowiedzi w stylu bh91, że jemu to "wystarcza", "nie przeszkadza" i że maszyna może sobie mieć 3cm zapasów na hamowanie. Jeśli wystarcza i nie przeszkadza, to niech się cieszy tym co ma i nie przeszkadza tym którzy chcą mieć jak należy. Dla mnie może sobie pozostać z softem i firmware 1.0.0

Zmierzam do tego, że nie ważne co komu w działaniu przeszkadza a co akurat nie..

W tym zapędzie do doskonałości włącz jeszcze instynkt samozachowawczy. Jak myślisz co może pomyśleć ktoś, kto wchodzi na forum i czyta co drugie słowo „błąd” „źle” itd. ? - ja bym poleciał kupić cokolwiek innego. Wszystkie Twoje propozycje można w jednym poście zmieścić a Twoich wpisów jest nieproporcjonalnie „od cholery” ( i nie dziw się, że czytam co drugie zdanie w co trzecim poście), jednak nie ilość jest tu najgorsza ale Twoja terroryzująca forum retoryka „cwanego bachora” np :

Flaki mi się przewracają na lewą stronę, jak czytam wypowiedzi w stylu bh91

Tak więc, jeśli chcesz abyśmy jaszcze jakiś czas pojechali na jednym (piko) wózku, to uruchom instynkt samozachowawczy - dla naszego wspólnego dobra.

Cosimo +

mc2kwacz - jeśli chciałeś profesjonalne rozwiązanie, to nie wiem, czemu nie kupiłeś CSMIO za dwa i pół patyka, albo jakiegoś Haasa, czy cokolwiek z przemysłu, tylko się katujesz z amatorskim rozwiązaniem dla tłuszczy?

Bardzo wyrywny jesteś i wymagający. Trochę na wstrzymanie weź.

Cosimo, odpowiedziałem prywatnie, może znajdziesz czas żeby przeczytać
Możliwy układ - poprawa za poprawę

Cały czas TWIERDZĘ, ŻE PIKO TO DOBRY PRODUKT, warty polecenia. Tyle że może być jeszcze lepszy. I to bez specjalnego wysiłku ze strony autora.

Zienek. to nie jest przemysłowa maszyna i nie zamontuje do niej przemysłowego sterowania o wartości większej niż sama maszyna. Proste i logiczne, MAM NADZIEJĘ. Gdybym potrzebował przemysłowej frezarki, to bym taką kupił gotową kompletną i w ogóle nie zaprzątał sobie głowy żadnymi innymi sterowaniami.

CSMIO to są tylko sterowniki, bez oprogramowania sterującego. Dla mnie BEZWARTOŚCIOWA oferta, jak wszystko inne co potrzebuje MACH-a żeby w ogóle zadziałać. I od kiedy to cena, ładnie pomalowane pudełko albo ilość migających lampek świadczą o profesjonalizmie lub ich brak o braku profesjonalizmy? Sztuką prawdziwą w elektronice jest zrobienie układu prostego, oszczędnego i jednocześnie funkcjonalnego. Oraz niezawodnie działającego. A nie nawalenie elementów. Każdy element zwiększa zawodność. Na płytce Piko jest jeden kontroler który robi wszystko. Na płytce Magaplotu jest Altera Max II + kości pamięci zewnętrznej, Atmel Arm, i co z tego, że fajny niebieski wyświetlacz pokazuje temperaturę i różne bzdety, jeśli sterownik się zawiesza i tylko wyłączenie prądu pomaga??? Nie wspominając o tym, że nawet połowy tego nie można sobie ustawić co w Piko.

Dla Piko nie widzę obecnie żadnej alternatywy w kategorii prostych autonomicznych sterowań, poza tym z czego już w pełni świadomie zrezygnowałem, czyli softu i sterownika Megaplotu. Jest jeszcze tylko LinuxCNC który odrzucam z uwagi na ograniczenia sprzętowe sterownika (PC).
Tylko Piko jest jednocześnie: systemem sterowania kompletnym do prostej frezarki lub podobnej maszyny, ma potencjał rozwojowy, umożliwia konfigurację maszyny i chodzi pod Windows. Może jeszcze coś gdzieś jest podobnego, ale nie słyszałem.
To jest taka pozycja wyjściowa, że tylko trzaskać sprzęt i wchodzić na kolejne rynki. Ale najpierw trzeba poprawić to i owo w WAŻNYCH drobiazgach.

Nie oczekuję skrzyżowania kombajnu z koparką i maszyną do lodów, tylko softu działającego CAŁKOWICIE poprawnie w tym wąskim zakresie który jest polem jego działania.

P.S. Na mnie żadne plusy za pomoc ani minusy dezaprobaty nie robią żadnego wrażenia.

P.S.2 Cosimo, na tym forum, okazuje się, jest limit czasowy edycji postów. Po kilku dniach postu nie można już edytować, np żeby dopisać do niego, że problem się wyjaśnił albo został rozwiązany. Na domiar złego ostatnio forum nie działało kilka dni (poza reklamami sponsora ) i 5-dniowy okres na edycję praktycznie się skasował. Nie moja wina. Z resztą istnieją kanały komunikacji elektronicznej poza forum.
Tak więc jedynym sposobem na przyszłość, żeby takie dopiski mogły się pojawić zaraz na początku tematu, zamiast straszyć potencjalnych klientów informacjami że "znowu coś jest źle", jest rozsądnie szybka reakcja z Twojej strony. Nawet jeśli to jest kolejny "tylko mój problem".