BŁĘDY w Piko

Mam wniosek jak koledzy wyżej, żeby parametry zapisywały się w locie. Żeby nei było tak, że reset peceta albo nawet zamknięcie programu przez wyłączenie systemu (bez wcześniejszego ręcznego zamknięcia aplikacji) powoduje, że program traci wszelkie informacje o poczynionych zmianach. Czyli sugeruję operacje dyskowe automatycznie w momencie wprowadzenia jakiejkolwiek modyfikacji w stanie programu i sterownika.

Dokładnie! Podpisuję się obiema rękoma.

Co do wcześniejszego - dysk systemowy mam D: - magazynowy C: - piko pierwotnie miałem na systemowym (czyli D:) Teraz przerzuciłem na C: - zobaczymy co będzie.

Zauważyłem dzisiaj dziwne wskazanie piko dla prędkości G0. Mimo że mam dla osi ustawione maksymalne prędkości 2400mm/min, to przy jeździe G0 na przeciwległy róg kwadratu osiągnąłem prędkość 3390mm/min. W symulacji wskazania były prawidłowe.

Nie jestem pewien czy osie poruszały się szybciej, czy tylko wskazania były przekłamane.
Wersja programu 3.0.2. W załączniku daję plik CAM, problem występował przy linii N1190.

Hmmm może dla tego ponieważ oś X jak i Y jechały z 2400mm/min więc prędkość g0 w ruchu wynosi 2400mm/min*√2= ~3390mm/min?

Tak ma być.
https://www.cnc.info.pl/topics121/pikob ... htm#479309

Robert

MarcinxD, RobWan
faktycznie, podstawowa fizyka się kłania i składowe wektora prędkości na płaszczyźnie
W przestrzeni trójwymiarowej prędkość byłaby jeszcze większa i wynosiła 4160mm/min.
Dzięki za wyjaśnienie i przypomnienie

Już raz miałem zapytać, ale to ...jowe forum się zacięło i straciłem pracowicie napisany post a potem mi się nie chciało go odtwarzać.
Otóż obecnie używam wersji 3.02 i niestety zacząłem mieć problemy ze zwieszaniem się systemu pecet-maszyna.
Od razu zaznaczam, że nie ma pewności że to wina kolejnych wersji softu, choć sam pecet do niczego innego nie służy i NIC nie jest na nim instalowane ani zmieniane.
Jak wcześniej mogłem powiedzieć, że zacięcia były tak rzadkie że pomijalne, to teraz szacuję jeden "zwiech" na 2 godziny pracy. To jest, dla odmiany, częstością absolutnie nie do przyjęcia.
Czasami "słychać" że niedługo będą problemy, bo daje się słyszeć "stuknięcia" w napędach spowodowane zacinaniem się transmisji po USB. I wiadomo że prędzej czy później będzie koniec pracy.
A wygląda to tak jak pisał mumin: nagle sterownik staje i na nic nie reaguje, LED-y przy USB gasną a LED przy procesorze miga ~2Hz. Sterownik "zamraża się" ale nie do końca jest to prawda. Bo na przykład wczoraj na guzikach zapaliła mi się lampka "pauza" mimo że przycisku nie tknąłem.
Często zawieszenie następuje w momencie bezczynności, np w przerwie między detalami. Ale często też tuż po skończeniu pracy podczas odjazdu do G28. Stosunkowo rzadko w trakcie samej pracy ale tez się zdarza.
Nie zawsze można wznowić pracę bez operacji bazowania, ponieważ jeśli zatrzymanie było podczas ruchu osi to oś jest w innym miejscu niż wydaje się pecetowi.

Samo wznowienie wygląda następująco:
- zamykam program, aplikacja pisze że trwa połączenie z kontrolerem, ja potwierdzam że chcę zakończyć
- aplikacja nie zamyka się jednak, dopóki fizycznie nie rozepnę USB (typowy objaw dla programów obsługujących USB, kiedy komunikacja padła bez wyjęcia wtyczki)
- odczekuję chwilę aż system rozpozna i przemiele brak wtyczki USB, po czym łącze ponownie
- odpalam aplikację, tabulator, potwierdzam guzikiem reset -> komunikacja wraca do normy (do następnego zwisu)
Ale co mnie w tym niepokoi najbardziej.
Jedno, że aplikacja twierdzi że ma połączenie z kontrolerem mimo że port USB nie działa ewidentnie. To jednak jest problem do rozwiązania, tylko trzeba się przyłożyć a nie bazować na flagach systemu
Drugie, znacznie poważniejsze, że Piko zawiesza się z błędem i trwa w tym błędzie dopóki albo nie wyłączy się mu zasilania albo nie przywróci transmisji opisaną wyżej procedurą.
Zdarzyło mi się też takie zawieszenie, które nastąpiło podczas ręcznego poruszania osiami, i po zawieszeniu oś jechała dalej!

I teraz pytanie do którego zmierzam. Czy w związku ze zmianą firmware na 3.00 zostały takie błędy poprawione? Jeśli tak, to mam motywację żeby przejść na soft 4.1.0 i bujać się z PLC na co szczerze nie mam ochoty (bo nie mam potrzeby żeby to mieć a nikt mi straconego czasu nie zwróci).
Boję się też utraty nastaw maszyny, listy narzędzi i punktów referencyjnych, z czym miałem problemy przy przeprowadzce na wersję 3.02 (konieczna była niestety ręczna edycja INI)
Ale najważniejsze jest to, czy w nowym firmware reakcja sterownika na utratę komunikacji została poprawiona?

mc2kwacz pisze:bujać się z PLC

To jest moment. Edycja może trzech linii.
Opisane w instrukcji co zmienić należy.

mc2kwacz pisze:ręczna edycja INI

Skopiować katalogi ProfilDef i Init Files

Robert

To dobrze że tym razem kompatybilność plików jest zachowana. Bo przy ostatniej zmianie softu okazało się że nie jest.
Ale to nie jest to co mnie interesuje. Interesuje mnie stabilność i poziom dopracowania zabezpieczeń. Bo jeśli ma mi się zawieszać nowa wersja tak jak obecna, to nie widzę żadnego sensu żeby cokolwiek zmieniać. Ja wymieniam oprogramowanie jakiekolwiek wtedy kiedy zachodzi potrzeba a nie tylko dlatego, że pojawiło się nowe.

Ostatnio robiłem reliefy i też miałem takie zawiechy, że musiałem pogłówkować, jak nie stracić dwóch godzin roboty. Jeden detal miałem do wyrzucenia, drugi dało radę odzyskać, bo dwie osie były bez zmian przez dłuższy czas (stała Z na stałym Y), a podróżujący Z sobie zbazowałem do krawędzi reliefu.

Również nie potrafię odgadnąć, na czym polega błąd.
W wersji 4.0 jedyną nowością jest to, że pokazuje się mrugający komunikat Po którym trzeba się rozłączyć i ponownie połączyć ze sterownikiem, żeby go używać.