WYŁĄCZNIE pomysły na poprawę działania i funkcjnalność softu

Ja też mam. Ale nie o tym rozmawiamy co kto ma, tylko jak to powinno działać, żeby było dobrze (poprawnie w myśl oczywistych oczekiwań). To znaczy, żeby przy prostej zmianie przyspieszenia nie trzeba było przestawiać wymiarów i co za tym idzie programowej pozycji pracy. Nie po to są w programie limity, żeby po ich ustawieniu zgodnie z faktycznymi wymiarami, maszyna waliła w zderzak, bynajmniej nie "na styk" ustawiony.

Jak dla mnie to zbędne jest Myśl co robisz i nic w nic nie będzie waliło. Jeśli już to niech się wyświetla komunikat że obszar rysowania poza maszynę ale przy starcie. W maszynie mam zapas za zderzakami po 30mm a maszyna kręci się do 20m/min czyli wyhamować ją to z 10cm więc w tym rozmiarze w koło zwalniała by mi podczas obróbki? a co z materiałami które wymają stałej prędkości bo inaczej będą się palić czy topić?

Myślę że lepiej poświęcić czas na coś innego niż bardziej przydatnego

Nie po to są w programie limity, żeby po ich ustawieniu zgodnie z faktycznymi wymiarami, maszyna waliła w zderzak, bynajmniej nie "na styk" ustawiony.

Widocznie „styk” jest mniejszy niż droga hamowania osi. Droga hamowania zależy z kolei od przyśpieszenia to chyba jasne. Jak chcesz mieć na totalnie zerowy „styk” to zrób limity na krańcówkach podłączonych do e-stopu (jak to powszechnie (ale nieszczęśliwie) przy mach-u jest praktykowane) wtedy maszyna stanie dęba – ma to taką wadę, że praktycznie po każdym najechaniu trzeba bazować maszynę. Pomysł aby spowalniać program w okolicach limitu to trochę przesada (zresztą nigdzie się z tym nie spotkałem) i nie zamierzam tu nic kombinować. Jeśli masz jakąś pracę na granicy obszaru roboczego to chyba najprościej byłoby na ten czas wyłączyć limity i tyle – co ma się złego stać?

Zrobisz jak chcesz, nie chcesz, to Cię nie zmuszę przecież. Trochę nie rozumiem, bo to jest proste.
Moje rozumowanie jest też proste, i jak sądzę oczywiste: maszyna ma określony obszar roboczy i ten obszar powinien być zachowany NIEZALEŻNIE od ustawionych parametrów dynamicznych. To powinien rozwiązać program sterujący. To tak jakby producent samochodu zabronił w instrukcji skręcania kierownicą do oporu, bo się koło może urwać Idąc w porównaniu motoryzacyjnym dalej, tak samo jest na drodze. Widzisz znak ograniczenia prędkości albo STOP, i masz się na nim zatrzymać lub na nim masz mieć prędkość ograniczoną do określonej. A nie dopiero zaczynać coś robić kiedy miniesz ten znak, prawda?

Ja się spotkałem. Przy sterowaniu Megaplota (mój jedyny punkt odniesienia w kwestii sterowania frezarką) marginesy logiczne były ustawione na ~3mm przed zderzakami i mimo maksymalnej prędkości 5000 (G0) kolizji nie bywało a maszyna dojeżdżała do granicy bez problemu, i to precyzyjnie (0,00). Czyli można? Aż tyle nie oczekiwałem od Piko, bo spodziewam się że to może być problem "organizacyjny", byle to było 2-3 milimetry, a nie liczba często dwucyfrowa.
Po prostu na obecna chwilę jest to zrobione źle, i już. Pomysły alternatywne, prowadzące do utraty kroków są złe i zupełnie nie do przyjęcia.
Dopiero co sugerowałeś, że pomysł zapisywania "kilku cyferek" do pliku to też przesada

Mitek, jadąc wzdłuż granicy X składową prędkości Y miałbyś nieograniczoną. Poza tym efekt byłby widoczny praktycznie tylko przy dużych prędkościach (relatywnie do przyspieszenia). Na łukach, szczególnie ostrych, posuw i tak spada. A wrzeciono nie nadąży z obrotami za posuwem.

Nie ustawiam prac na granicy obszaru. Choć zdarzało się, fakt, kiedy płyta miała 60 cm szerokości... Ale wystarczy chcieć dojechać do krawędzi żeby wygodnie wymienić frez (np cieniutki i delikatny, który wystarczy musnąć żeby złamać), i już musisz mieć duży zapas, bo jak nie to dzwon. I oprócz zmierzenia długości płytką, musisz jechać do bazowania. Jeśli ktoś nie ma precyzyjnych krańcówek home, to w tym momencie ma problem potencjalnie poważny, bo mu się zgrubna obróbka może nie zejść z precyzyjną. Pomijam też, że sam dzwon, nawet na zderzaku do tego przeznaczonym, to nie jest w żadnym wypadku zdrowe dla maszyny zdarzenie. To nie jest czysta bezwładność, tylko silnik nadal kręci na siłę!

Ja się spotkałem. Przy sterowaniu Megaplota (mój jedyny punkt odniesienia w kwestii sterowania frezarką) marginesy logiczne były ustawione na ~3mm przed zderzakami i mimo maksymalnej prędkości 5000 (G0) kolizji nie bywało a maszyna dojeżdżała do granicy bez problemu, i to precyzyjnie (0,00). Czyli można? Aż tyle nie oczekiwałem od Piko, bo spodziewam się że to może być problem "organizacyjny", byle to było 2-3 milimetry, a nie liczba często dwucyfrowa.

Taki numer jest możliwy tylko przy dwóch założeniach: korzystamy z softlimit (przy krańcówkach osi nie jest to możliwe) i zachowanie takie jest tylko dla jog-a! Dla programu na pewno nie – w Megaplocie można w ogóle uruchomić program wystający za obszar roboczy? Wątpię, zresztą po co.. Tak więc podsumowując: dla jog-a osi w trybie softlimit jest to faktycznie do zrobienia...

Jeśli dobrze zrozumiałem, piszesz o piko, że w trybie cięcia nic się zdarzyć nie może?
Tego nie wiem, i oczywiście dobrze jeśli tak jest. Z resztą chyba dziwne by było, gdyby było inaczej, bo to by oznaczało, że maszyna nie kontroluje linii cięcia.
Owszem, chodziło mi o szybkie dojazdy. One są przecież także kontrolowane przez program pc. Sterownik Piko nie jest autonomiczny, również w kwestii kontrolowania panelem ręcznym. tak więc mam na myśli dojazdy. Ten sam efekt jest zarówno na softlimitach jak i w położeniach gdzie występują fizyczne krańcówki home.
Czyli przyjrzysz się sprawie? Fajnie. Nie chodzi o upór we wprowadzaniu pomysłów, tylko jest to faktycznie cenna i potrzebna rzecz. Cecha naturalna, czyli dobra.

Przy okazji przypomnę więc ( ) kwestię priorytetów między softlimitem a krańcówkami home. Kiedy przestawi się ręcznie obszar roboczy (przez nadpisanie położenia maszynowego), maszyna potrafi nie dojechać do krańcówek home i MOŻNA TEGO NIE ZAUWAŻYĆ, bo to mogą być pojedyncze milimetry. Na przykład po kolizji ze zderzakiem(!)

Normalnie w maszynach przemysłowych, zerowanie jest obowiązkowym punktem programu po włączeniu zasilania. Tyle że tam zerowanie jest dokładne (bo drogie), nie to co w domowych maszynach. Więc zrozumiałe, że udostępniłeś możliwość nadpisania danych maszynowych, bo to może uratować pracę, jeśli się odpowiednio zastosuje. Ale powstałe ryzyko z tym związane jest spore, bo można dane maszynowe (które w maszynach przemysłowych są nietykalne w sposób prosty lub nawet wcale) łatwo niechcący zmienić, i nieszczęście gotowe. Dlatego postulowałem generowanie chociażby okna ostrzeżenia, że się grzebie w tych nastawach. Ale to ewentualnie, bo jednak zmiana sama się nie zrobi. Za to "samo" zrobi się bazowanie bez faktycznego zbazowania i z tym już, uważam, trzeba koniecznie coś zrobić. Przynajmniej okno ostrzeżenia, że zbazowanie nie było kompletne (jedna lub więcej fizycznych krańcówek home nie zadziałała).

W megaplocie nie dało się absolutnie wyjechać poza logiczny ani fizyczny stół, tyle pamiętam. Tam w ogóle wszystkie dane maszynowe były na stałe zaszyte i w żadnej formie nie dostępne dla usera. Z oczywistych względów - kupowało się działającą nierozbudowywalną całość a nie sam sterownik.

Cytat:
Proponuję popracować nad ergonomią interfejsu użytkownika. Obecnie program przystosowany jest do pracy z myszką i klawiaturą.

Też nad tym myślę i nachodzi mnie coraz większa ochota dopasowania interfejsu do ekranów dotykowych Jeśli masz jakieś wizje tego to chętnie zobaczę (a może wykorzystam).

Żeby nie być gołosłownym - słowo się rzekło, panel u płota .
Przedstawiam Wam moją propozycję panela dotykowego. Idea jest taka aby na panelu były tylko te funkcje, które są najprzydatniejsze podczas obsługi maszyny. Stąd cały CAM, funkcje konfiguracyjne i pomocnicze powinny zostać na innym ekranie. Panel jest konfigurowalny i można sobie dowolnie poprzestawiać wszystkie moduły z lewa na prawo i z góry na dół. Jak komu wygodnie. Wiem, że pewnie można tam coś zmienić lub dodać. Czekam więc na opinię a zwłaszcza na opinię Cosimo
Oprócz zdjęcia zapodałem także załącznik z plikiem exe, w którym to możecie sobie poklikać, poprzestawiać, wczytać G-Code, itp. Miłej zabawy

Marek

Bardzo fajne, ale zaznaczam, że sprawa jest ciężka do optymalizacji.
moim zdaniem wszystko co jest na ekranie piko jest równie potrzebne. To co wybrałeś jest Twoją wizją zapotrzebowania, być może związaną z charakterem pracy.
Dlatego dobrze by było, gdyby taki ekran, jeśli powstanie, był konfigurowalny elastyczniej, nie tylko w ramach przesuwania okienek.
Ja na przykład nie zmarginalizowałbym okna podglądu i jego opcji. Nie wyprowadziłbym makr ani kursorów (bo mam joga i jest to lepsze rozwiązanie). Całkowicie zrezygnowałbym tez z zawartości okna "połączenie" bo to załatwiają fizyczne przyciski oraz tabulator. W oknie "ustawienia programu" wolałbym widzieć zaawansowane opcje pozycjonowania na stole i względem narzędzia, zamiast skalowania i lustrzanego odbicia czy tym bardziej obrotu. Za to na pewno chciałbym mieć szybki dostęp do cama i plików wsadowych oraz konfiguracyjnych.
Nie twierdzę, że to co pisze jest w jakikolwiek sposób lepsze, tylko chce pokazać, że zależnie od specyfiki pracy, różne fragmenty piko będą ważniejsze, mniej ważne lub wręcz zbędne.
Generalnie, jeśli miałbym się ustosunkować do propozycji, to uważam że obecny ekran piko jest lepszy. Nie da się go wykastrować arbitralnie, żeby statystyczny użytkownik nie narzekał. Natomiast sama idea takiej możliwości (konfigurowalnego ekranu dotykowego) jest jak najbardziej słuszna i sensowna. Bo piko ma za mało wejść i wielu poręcznych rzeczy się guzikami zrobić nie da.

Żeby nie być gołosłownym - słowo się rzekło, panel u płota ...

Dzięki, bardzo fajne i daje do myślenia. Tak jak mckwacz pisze będzie to ciężka sprawa dogodzić wszystkim, dlatego chyba najlepszym wyjściem było by „jądro” piko dać jako dll-elkę a interfejs jako „open source” dało by to najlepsze możliwości dopasowania do konkretnych wymagań... nie mówiąc już o tworzeniu wersji na inne maszyny (plazma, tokarka etc.)

Jasne, że się wszystkim nie dogodzi, dlatego gdyby np. do Piko było coś w rodzaju API na poziomie GUI można byłoby (tak jak piszesz) tworzyć dowolne interfejsy dla konkretnych maszyn i do konkretnych zastosowań. Ktoś chce mieć CAM - to ma. Inny nie chce, bo korzysta z gotowych g-code'ów to ma maszynkę uproszczoną do wycinania na laserze czy plazmie.
Może właśnie zamiast tworzyć gotowe interfejsy i narażać się na ciągłe narzekania, że czegoś nie ma, to ten czas poświęcić na przejrzenie i uporządkowanie kodu pod kątem API i udostępnienie go. Myślę, że projekt mógłby nabrać rumieńców i przyciągnąć większą ilość potencjalnych klientów. Początki już są, bo przecież dostępne są funkcje operowania na maszynie z poziomu makr. Teraz połączyć to z GUI i mamy narzędzie o naprawdę sporych możliwościach.