Dodatkowe zaciski i nowa płytka to 2% roboty. Procesor musi mieć zasoby żeby to obsłużyć i trzeba go oprogramować.

Tu już producent musiałby zrobić nowy sterownik na innym procesorze... To zdecydowanie więcej niż doszlifowanie drobiazgów w tym co jest.

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".

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

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.

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

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.

cosimo pisze:Firmware jest rozsyłane mailowo do wszystkich, choć czasami ktoś się nie załapie na listę...

No niestety masz pewne zapędy masochistyczne Info powinno być rozesłane ale nie jest, bo nie masz porządnej bazy nabywców. Do tego (lub jak kto woli - zamiast tego) zero informacji na stronie, żeby ci którzy nie dostali mogli się połapać, że nie dostali czegoś co powinni lub mogliby. Nawet na tym forum brakuje informacji o firmware, co przecież kosztowałoby Cię maksymalnie 5 minut, z wyjaśnieniem co, po co, gdzie, jak i dlaczego.
Świeczką na gipsie jest ciągły brak aktualnego i aktualizowalnego manuala z wynalazkiem o nazwie "spis treści"
Pomyśl sobie, ile czasu byś zaoszczędził na czytanie głupich pretensji lub jeszcze głupszych pytań o to co powinno być czytalne w manualu...
Drugi objaw masochizmu to wystawianie wersji niesprawdzonej (bo nie łudź się, nie jesteś w stanie sprawdzić całego softu za każdym razem, mimo najszczerszych chęci) jako końcowej a nie "beta".

--

Maszyna z serwami przetestowana.
Więc tak.
Wszystko nabrało wreszcie sensu Maszyna pracuje płynnie, silniki szeleszczą. Jedynym skutkiem poruszania się masywnej bramy z dużymi przyspieszeniami jest wibracja całej konstrukcji (brak kratownicy na bokach). Chyba z tego powodu zmniejszę akcelarację do 1,5m/s2. Ustawiłem G0 na 100mm/s i można dać więcej ale nie dam z powodów bezpieczeństwa pracy. Podobnie ręczne szybkie posuwy ograniczyłem do 60mm/s z tego samego powodu.
Ale ogólnie rewelacja: piko+ miniserwa + moje precyzyjne krańcówki.
Zwiększenie przyspieszenia praktycznie rozwiązało problem z bezpiecznym hamowaniem na softlimitach. Co nie znaczy że nie należałoby tego jednak dopisać w sofcie, bo przecież nikt nie musi ustawiać przyspieszenia 2m/s2. Przy kilkakrotnie mniejszym (prace bardzo precyzyjne) problem pozostanie. I nie wszystkie maszyny zniosą duże przyspieszenia.

Na obecną chwilę mam niedosyt, w kwestii współdziałania softu i mechaniki, tylko w jednym miejscu. Ciągle to nieszczęsne bazowanie home jest niedorobione. O co chodzi.

cosimo pisze:

Przy okazji potwierdziłem, przypuszczenia, bo wyszło to natychmiast w postaci błędów miniserwa, że podczas najazdu na krańcówki home piko nie stosuje zadeklarowanych przyspieszeń

Podczas najazdu oczywiście, że nie.

No właśnie, a dlaczego "oczywiście"? Po co aż tak nadwyrężać drogie śruby kulowe, nakrętki i łożyska oporowe podczas zwykłego bazowania? Które na dodatek, jeśli nie poprzedzone dzwonem, jest w przewidywalnym miejscu?
W miniserwach programuje się między innymi maksymalną ilość kroków błędu chwilowego. Błąd wyrażony w krokach bezpośrednio przekłada się na błąd posuwu. A więc na przykład przy 5000 krokach na obrót i śrubie 5mm, 1 krok odpowiada 1um.
Przy dynamice takiej jak sobie ustawiłem, czyli prędkość maksymalna 100mm/s i przyspieszenie 2m/s, błąd serwa w ruchu oscyluje wokół +/-15um, w szczycie (przy gwałtownych przyspieszeniach) osiągając +/-25um, jak wynika z pomiarów monitorem serwa. Czyli można by ustawić sobie 50 impulsów (um) i mieć pewność że żaden punkt pracy nie będzie "zajechany" bardziej niż 0.05mm. Czyli tyle ile jest w stanie zmierzyć suwmiarka elektroniczna za 50zł. Nieźle jak na szybkie cięcia.
W momencie gdy serwo którekolwiek wyliczy większy błąd, w tym momencie zatrzymuje cały system. U mnie bez utraty pozycji, bo nie używam wejść enable.
I tu pojawia się zgrzyt. Ponieważ na etapie bazowania home, przyspieszenia na osiach są dużo większe niż te ustawione w konfiguracji (przypuszczam że sprowadzone to jest do kąta hamowania), i w efekcie serwo ma znacznie większy błąd TYLKO W TYM MOMENCIE UŻYTKOWANIA MASZYNY. U mnie oscyluje wokół 100um i upgrade firmware nic tu nie zmieniło, problem tkwi w software. Tak więc, żeby błąd się nie zdarzał, musiałem ustawić błąd maksymalny z zapasem, na 150um. I teraz już jest ok, ale niestety w pracy zostanie również zgłoszony błąd dopiero powyżej 150um. 3-4x większy, niż mógłby być Nie da się tego ominąć, bo skasowanie błędu serwa wymaga wyłączenia zasilania maszyny. Poza tym nawet to nic nie da, bo przecież maszyna ciągle nie jest zbazowana. Tak więc w cosimo cała nadzieja, że poprawi, "zmiękczy" charakterystykę hamowania na krańcówkach home oraz to samo z dziwnie bardzo agresywnym mechanicznie zjazdem do czujnika (bo spodziewam się i tu kłopotów, choć nie zaobserwowałem na obecną chwilę). Wtedy można by wykorzystać pełnię możliwości miniserw sterowanych z piko.

Ale, trzeba przyznać, wszystko powoli zmierza w dobrym kierunku. Parę drobiazgów do poprawienia i piko może rządzić.

Przy okazji zauważyłem błąd w sofcie: dopóki maszyna nie zjedzie z obydwu krańcówek, dopóty żadna pozycja krańcowa się nie zaktualizuje. Drobiazg, ale jednak... Powiedzmy że jedna oś nawaliła. Piko cały czas próbuje z niej zjechać, ale pozycje pozostałych osi są niezmienione i niewłaściwe, choć maszyna już z nich wcześniej poprawnie zjechała (sekwencja).

No tak, to by wiele tłumaczyło... Uff, a już się zacząłem martwić
Wysyłam mejla na mejla

[ Dodano: 2013-10-02, 16:06 ]
Noooo, panie, teraz to jest inna rozmowa, jak powiedziałby Kobuszewski
Potem się tym pobawię bardziej, ale od razu widać, że to jest to co być powinno...
Ustawiłem akcelerację 2m/s2 i śrubki się same nie wykręcają, jak dopiero co wcześniej Przy 100Hz to można śmiało rzecz nazwać po imieniu, że nie było przyspieszania tylko start z kopyta i hamowanie jak na ścianie. Okres próbkowania na poziomie czasu przyspieszania

Należałoby nabywców przymusić do wymiany firmware, bo nie wiedzą co czynią używając 2.02. A przynajmniej poinformować porządnie na stronie, że jest nowy firmware, ZALECANY.

Firmware mam 2.02 i nie widzę na stronie informacji o nowym albo skąd pobrać. Nie pamiętam też żadnego info na forum. Na stronie jest tylko informacja, że soft wymaga 2.02.
Pamiętam że ludzie coś niedawno pisali o problemach z 2.04, ale nie wiedziałem że o firmware chodzi, bo system numerowania softu jest TAKI SAM, żeby było czytelniej
Ustawienia:
kroków/obr 5000
posuw na obr 5,00
prędkość max 4000 (bezpiecznie)
przyspieszenie 0,40 (żeby zanadto nie rzęziło)
prędkość rozruchowa 100
kąt hamowania 30,00
Próbowałem z prędkością rozruchową 20 (minimum) i 200, i nie zauważyłem różnicy.
Test wygląda następująco: trzymam reset i naciskam raz lewo raz prawo (albo przód tył) jogiem z krótkim interwałem. Tak samo jak robi to program testowy serwa.
Przy przyspieszaniu i hamowaniu po maszynie niesie się charakterystyczne dudnienie, którego WCALE nie ma przy sterowaniu programem miniserwa. Wiem co piszę. I to jest znacznie mniej niż kiloherc. A ile jest w moim firmware 2.02?

Kiedy obserwuję na ekranie wykres błędu pozycjonowania serwa (jest taka opcja w oprogramowaniu), wtedy przy sterowaniu firmowym błąd narasta dość ładnie liniowo aby ustabilizować się przy stałej prędkości, podczas gdy w sterowaniu z piko na zboczach są bardzo silne oscylacje. Oznaczają one szybkie skokowe wymuszenia zmiany prędkości. Parametry regulacyjne miniserwa są optymalne fabryczne. Dają one najmniejsze błędy, jakie daje się uzyskać, przy założeniu szerokiego zakresu regulacji, sprawdziłem.

Zaraz poszukam informacji o 2.04...