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

Nie masz gdzie i z kim gadać? Musisz, mimo wyraźnej prośby, zamulać kolejny watek w którym nie ma miejsca na bajdy o linuksie oraz wypowiedzi ludzi których nie dotyczy kwestia funkcjonalności piko?
Zgłosiłeś pomysł, niepotrzebnie bo po raz kolejny ten sam, ale niech będzie. Podziękowali i pożegnali.

Prośba do moderatora o usunięcie 2 ostatnich postów w wątku wliczając niniejszy.

mc2kwacz pisze:Prośba do moderatora o usunięcie 2 ostatnich postów w wątku wliczając niniejszy.

Nie ma powodu żeby cokolwiek usuwać.

.

Jeszcze raz na temat kwadracików w arcyważnej zakładce grupa. Mnie to już nie pomoże, ale dla innych i nowych użytkowników Piko może być pomocne. Kwadraciki, w momentach kiedy nie są użytkowe, powinny być "wyszarzane" lub całkowicie ginąć. Opcje obróbki, które są różne dla różnych zaznaczonych do edycjo grup, też powinny być w jakiś sposób zaznaczane, że być może popełniamy błąd i zaznaczyliśmy niewłaściwe grupy do zmiany. To takie zmiany wpływające na ergonomię użytkowania i zmniejszające ryzyko błędu operatora.

----

Drobna propozycja dot. widoku. Chodzi o to, żeby sposób prezentacji i zakres działały niezależnie. Czyli jeśli mamy widok na pracę 2d a potem zmieniamy na 3d, to żeby znowu nie trzeba było klikać "praca". Czyli ZAWSZE jedno kliknięcie zamiast 2, jeśli chcemy zmienić JEDEN aspekt widoku. Wydaje się byś super proste i szybkie do zrobienia.

Ja mam propozycję, czy można byłoby zrobić, aby w wersji free pikocnc w symulacji obróbki grubość materiału była większa niż 5mm (np. 15mm). Pozwoliłoby to prześledzić obróbkę materiału spokojnie w domu nie podłączając do maszynki.

Pozdrawiam

Proponuję popracować nad ergonomią interfejsu użytkownika. Obecnie program przystosowany jest do pracy z myszką i klawiaturą. Natomiast operowanie na panelu dotykowym jest bardzo utrudnione. Przyciski są zbyt małe, niewłaściwie rozmieszczone, brakuje przycisków do poruszania osiami, operacje na rozwijalnych listach, itp, itd. Także umieszczenie całego panelu sterującego po lewej stronie ekranu jest raczej dla mańkutów. Praworęczni podczas pracy zasłaniają sobie pozostałą część ekranu i trzeba się gimnastykować.
Ponieważ jestem także programistą proponuję swój wkład w rozwój PikoCnc. Mogę zaprojektować wygodny interfejs na panel dotykowy. Pytanie tylko czy autor zechce zastosować takie rozwiązanie.

PS. Projekt wykonam oczywiście nieodpłatnie...sam używam PikoCNC i lubię wygodę

Powracam z tematem "inteligentnego" dojazdu do krańcówek. Problem jest następujący:
- jeśli chcemy, żeby nie było strat na zakresach roboczych i jednocześnie maszyna nie waliła w zderzaki, trzeba ustawić spore przyspieszenia. Spore przyspieszenia z kolei powodują, że maszyna potrafi przeskoczyć krok (dokładnie 4 kroki, co na śrubie 5mm daje natychmiast 0,1mm błędu). poza tym spore przyspieszenia niepotrzebnie nadwyrężają mechanikę, czyli powodują szybszą dewastację maszyny.
- jeśli chcemy, żeby nie było dużego ryzyka zgubienia kroków, trzeba ustawić względnie małe przyspieszenie. A to powoduje że droga hamowania na limitach strasznie się wydłuża. I żeby uniknąć dzwona, trzeba limity przesuwać w kierunku środka stołu, co jest niczym innym jak stratą na obszarze roboczym. Obszar utracony wydłuża się odwrotnie proporcjonalnie do przyspieszenia!
Dlatego postuluję, że gładkie hamowanie z uwzględnieniem przyspieszenia i pozycji krańcówek jest sprawą pilnie potrzebną do zrobienia.

Między innymi dlatego była propozycja uruchomienia PikoCNC na Linuksie....

Skoro uruchamia się pod wini to prawdopodobnie będzie też działała komunikacja. Piko aktualnie korzysta wyłącznie z systemowego portu COM: (w najzwyklejszy systemowy sposób) więc jeśli wini to obsługuje to raczej nie powinno być problemu. Ktoś gdzieś pisał, że Cnconv też działa ale komunikacja już nie. Przypuszczam, że Cnconv korzysta bezpośrednio z bibliotek FTDI a to już inna bajka. Dla piko sterowniki FTDI trzeba by zainstalować od strony Linuksa (są takie na stronie FTDI) i dane z portu COM wini przekierować na wirtualny com który powstaje po instalacji sterowników - i wtedy może...

Ja mam propozycję, czy można byłoby zrobić, aby w wersji free pikocnc w symulacji obróbki grubość materiału była większa niż 5mm (np. 15mm).

Masz kontroler? To napisz do mnie o klucz licencyjny - wszystkie ograniczenia wtedy znikają

Powracam z tematem "inteligentnego" dojazdu do krańcówek. Problem jest następujący: ….
..Dlatego postuluję, że gładkie hamowanie z uwzględnieniem przyspieszenia i pozycji krańcówek jest sprawą pilnie potrzebną do zrobienia.

Mc2kwacz-u, to nie przejdzie, wyobraźnia umiera mi gdy o tym myślę. Jedyne co mogę zaoferować przycisk do awaryjnego wyłączania softlimitu na takie okazje.

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

cosimo pisze:

Między innymi dlatego była propozycja uruchomienia PikoCNC na Linuksie....

Skoro uruchamia się pod wini to prawdopodobnie będzie też działała komunikacja. Piko aktualnie korzysta wyłącznie z systemowego portu COM: (w najzwyklejszy systemowy sposób) więc jeśli wini to obsługuje to raczej nie powinno być problemu. Ktoś gdzieś pisał, że Cnconv też działa ale komunikacja już nie. Przypuszczam, że Cnconv korzysta bezpośrednio z bibliotek FTDI a to już inna bajka. Dla piko sterowniki FTDI trzeba by zainstalować od strony Linuksa (są takie na stronie FTDI) i dane z portu COM wini przekierować na wirtualny com który powstaje po instalacji sterowników - i wtedy może...

W tym akurat zgadzamy się w 100%.
Problem polega na tym, że ja nie mam sterownika a Ty masz.
Gdybyś zechciał się tym zająć, to służę pomocą, ale ja pięciu stówek z czystej ciekawości nie wydam.

.

cosimo pisze:m2kwacz-u, to nie przejdzie, wyobraźnia umiera mi gdy o tym myślę. Jedyne co mogę zaoferować przycisk do awaryjnego wyłączania softlimitu na takie okazje

Bez softlimitu i bez krańcówek (jog zamiast krańcówek) chyba jeszcze gorzej będzie?
Wydaje mi się to dość proste do zrobienia. Co innego, gdyby plik nc był bezpośrednio wykonywany przez procesor sterownika. Wtedy to on musiałby kontrolować odległość od softlimitów. Ale skoro parametry wektorów są na bieżąco wysyłane do sterownika przez pc, to chyba powinno być do zrobienia.
W wersji najprostszej i najszybszej w działaniu (minimalna ilość obliczeń w locie) widzę to tak:
1. na podstawie przyspieszeń ustawionych przez użytkownika tworzysz dla każdej osi po 2 tabele (oddzielnie dla każdego krańca osi) zawierającej kilka wyliczonych wartości położenia. Każda z wartości odpowiada maksymalnej prędkości osi jaka może być użyta przy przekraczaniu tej granicy. Uwzględniasz prędkość maksymalną zaprogramowaną przez użytkownika i schodzisz w dół, np w krokach co 500mm/min
2. podczas pracy sprawdzasz, czy tworzony wektor wchodzi w obszar(y) który obejmuje tabela. Jeśli tak, to dzielisz go na krótsze wektory (odpowiadające zakresom maksymalnych prędkości, zależnie w ile "warstw" prędkości wchodzi pierwotny wektor, i potem kolejnym wektorom nadajesz prędkość nie większą niż maksymalna w tym zakresie. Ograniczenie oczywiście dotyczy osi na której zbliżamy się do limitu. na drugiej osi może prędkość spaść również ale nie musi, zależy od kąta wektora.
To może zmienić parametry obróbki, ale ważne jest, że nie będzie za szybko, raczej za wolno. Nikt rozsądny nie piłuje kilka mm od krawędzi stołu. To zabezpieczenie na wszelki wypadek. No i przed szybkimi przejazdami do krawędzi.

Na rysunku niżej graficzny sposób działania opisanej korekty prędkości maksymalnej ruchu osi przy szybkim zbliżaniu się prostopadle do krawędzi obszaru roboczego. Wartości liczbowe odległości przykładowe. Po prawej stronie z korektą krokową, po lewej stan obecny (kolizja przy małym marginesie). Szerokość czarnej taśmy symbolizuje wartość ustawionej prędkości.
/od pewnego czasu forum nie przyjmuje ode mnie obrazków jako załączników/

Dlatego ja mam maszynę o te 2-3 cm większą niż potrzebna