dawf pisze: ↑

13 lip 2022, 07:12

Obecnie w g33 nie ma za implikowanego wyjazdu z nagwintowanego otworu.

cosimo pisze: ↑

19 sty 2020, 23:13

To pewnie przydałoby się jeszcze, aby skok kompensacji luzu był zależny od miejsca na śrubie

cosimo pisze: ↑

19 sty 2020, 23:13

autor się nie zlituje, gdyż programowe kasowanie luzu w przypadku frezarki nadal uważa za nonsens, a programowe kasowanie luzu w układzie gdzie nie ma sprzężenia zwrotnego (np.liniał) za nonsens do kwadratu.

bartekn86 pisze: ↑

19 sty 2020, 13:04

Co do drugiej części z tym nocnikiem to nie za bardzo łapię o co chodzi. Jak mógł byś przybliżyć.

bartekn86 pisze: ↑

19 sty 2020, 10:10

Autor się wypowiadał że nie chce wprowadzić takiego czegoś w sofcie więc stoję w miejscu i rozważam wymianę sterowania.
Tak samo przerabiając starą maszynę na śrubach które są wyrobione nie da się wymienić sterowania na piko z powodu tego zasranego luzu i trzeba iść po inne rozwiązanie. Kwintesencja tego jest taka ze 4 maszyny i 4 różne sterowania.

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

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

mc2kwacz pisze:Wcześniej złożona propozycja, celem znalezienia kłopotu w systemie, jest stale aktualna
Celowo użyłem tego peceta. Jestem z piko na etapie poznawania i przyzwyczajania się, i wolę być zaskakiwanym na tym etapie niż później, przy wielogodzinnych pracach. Już teraz wiem, że tego peceta po prostu używać z piko nie mogę. I jest to też dla mnie ostrzeżenie, że zawsze coś takiego się może zdarzyć.
Rzadkość, rzecz względna. Jeśli mam system, który składa się z 30 urządzeń 3 rodzajów, i od 9 lat działa non stop bez problemu, to w takim przypadku zwieszenie się jednego modułu to rzadkość. Albo urządzenie sprzedane w ilości kilkunastu tysięcy i raz na rok reklamacja że coś padło, to tez rzadkość. Ale jeśli włączam i pierwszego dnia mi 2 razy zwisa port a za drugim razem zawiesza się sterownik, to oznacza błąd łatwy do wywołania. Bardzo możliwe, najprawdopodobniej, że to ten pecet go wywołał. Ale tylko wywołał, a sterownik zawiesił się sam. Gdyby to było ma Microchipie to bym podpowiedział co może być i jak uniknąć, ale tego procesora nie znam.

mc2kwacz pisze:Tylko raz włączyłem coś co się cięło kilkanaście minut. I na tej większej pracy system 2 razy się wyłożył. Najpierw w połowie a za drugim razem pod koniec. Na szczęście udało się ustawić narzędzie do częściowo wykonanej pracy i nie było strat.
Bardziej zaniepokoiło współdziałanie PC-piko. Użyłem tego peceta, który wywalał aplikację przy próbie wciągnięcia STL. Ale tym razem to był prosty HPGL. Za pierwszym razem zawiesił się program na PC. "Program nie odpowiada". Trzeba było zamknąć managerem zadań. Ale za drugim razem zawiesił się sterownik piko. I to zawiesił się dokumentnie. Nie pomogło ponowne odpalanie aplikacji, odłączanie USB. Pomogło dopiero odłączenie zasilania od piko i ponowne włączenie. Przyjrzałem się co się z płytką dzieje w tym czasie, kiedy system wisiał - jedna z 2 sąsiednich diod, ta czerwona migała krótko raz na około 10 sekund. Zielona była wygaszona.
A może to po prostu FTDI się zawiesił?