Witam

[adasko007]

Witam
Od dwóch lat pracuję jako programista robotów u jednego z polskich integratorów. Pracuję głównie na robotach Fanuc i Kawasaki, w przeszłości (czasy studenckie ;p) też działałem na robotach Kuka i Staubli...

Mam nadzieję, że znajdę na tym forum odpowiedzi na nurtujące mnie pytania ;p

W tej chwili zastanawiam się nad monitorowaniem warunków w robotach Fanuc. Kiedyś używałem funkcji Monitor do sprawdzania sygnału i wystawiania odpowiednich flag. Zauważyłem wtedy, że nie można wywołać funkcją monitor programów z grupą ruchu... Czy to jest kwestia jakichś ustawień? Czy też faktycznie się nie da...?

Pozdrawiam

[joker]

Elo, a jak chcesz sprawdzac cyklicznie program z instrukcjami ruchu? Submit na kuka tez ma z tym problemy, comau z nohold rowniez - to zreszta zrozumiale.

[adasko007]

Tzn. w robotach fanuc jest instrukcja monitor, działa ona trochę jak przerwanie, czyli jeśli warunek monitor będzie spełniony, to ruch jest przerywany (sprawdzałem to kiedyś). Następnie realizowany jest program wywoływany przez monitor - tyle, że nie da się wywołać programu z grupą ruchu i tu jest zonk...

[joker]

Wiem co to monitor  ale z instrukcja ruchu to dzialac nie bedzie bo monitor musilaby dzialac jak skip condition a z tego co wiem to tak nie dziala. No chyba ze sie myle.

[adasko007]

kombinowałem swego czasu z alarmami użytkownika - nadałem im poziom abort, w podprogramie wywoływanym przez monitor dawałem UALM, zaraz za tym call program glowny. W ten sposób można wywołać program z grupą ruchu, ale jest to rozwiązanie toporne ;p

[joker]

Tylko jest pewien problem, nie wiem jakiej aplikacji uzywasz ale jesli np spota z dosc skomplikowana sciezka i wywolasz w opisany przez Ciebie sposob program glowny to co sie stanie po aborcie?? Moim zdaniem crash az milo. Takie rozwiazania sa dobre przy mig/mag albo pick/place i to niezbyt skomplikowanym.
Monitory maja pomoc przy kontroli sygnalow, rejestrow itd. przynajmniej takie moje zdanie.
Osobiscie uzywam opcji fault recovery, tyle ze to zagniezdza program w programie i robi sie nieciekawie jak sie cos popieprzy po drodze.

Przepraszam, ze tak pytam ale pracujesz w Fanuc Polska??

[adasko007]

Nie, nie w Fanucu, choć mocno z nimi wpółpracujemy.
Wiem, że monitor służy do monitorowania sygnału, szukam po prostu jakiegoś rozwiązania, które pozwoliłoby mi na zrobienie "niby - przerwania". W więkzoci aplikacji które robimy, jeśli w trakcie ruchu np. wypadnie karton to muszę o tym wiedzieć - póki co sprawdzam sygnał na czujnikach między ruchami, ale czasem przydałoby się takie sprawdzenie w trakcie ruchu ( i nie chce tu używać skip condition - tego zanadto już jestem zmuszony używać do wszelkiego rodzaju wysokości przedmiotów i wszystkiego co sobie tutaj projektanci wymyślą...)

Co do fault recovery - opcja przydatna, ale płatna, a u mnie w firmie to jest zawsze "minimalizacja kosztów", więc muszę się obywać bez takich rzeczy. Nie mówiąc o tym, że faktycznie są z tym zonki.

Zresztą - raczej działam na zasadzie, że sam robię "reset robota" - czyli w jakiejkolwiek by nie był sytuacji, robot musi wyjechać do pozycji bezpiecznej i usunąć to co mam w chwytaku. Przy 4 osiówce to jest luz, ale 6 osiowe to masakra ;p

[joker]

Jakiego uzywasz kontrolera i jaki jest na nim soft zainstalowany??
Jakies rozwiazanie na pewno istnieje tylko dobrze by bylo wiedziec czym dysponujesz w opcjach softu.
Moze w karelu prosta rutyne napisz, bedziesz mial pewnosc ze nikt tego nie ruszy jak nie udostepnisz zrodla ;)

[adasko007]

W tej chwili to głównie R-30iA. W sumie myślałem o tym faktycznie by napisać coś pomocnego w karelu. Myślałem też nad tym by po prostu w tle uruchomiony był program, gdzie np. w głównym programie w odpowiednim momencie, gdy chce by sygnał był monitorowany, ustawiam sobie jakąś flagę, i na podstawie tej flagi w programie uruchomionym w tle monitoruję sobie sygnał - jeśli sygnał zadziała (karton wypadnie) to przekazuję alarm do PLC i pauzuję robota. W takiej sytuacji i tak wg standardów w naszych aplikacjach należy zrobić reset robota by odłożył to co ma w chwytaku. Miałbym sprawę monitoringu załatwioną.
Tyle, że jakoś nie mam zaufania do załączania więcej niż jednego programu w tle - swego czasu przy dwóch programach w tle robot mi się zawieszał XD (serio - takie rozbudowane aplikacje mi się dostają =.=). A jeden program w tle to zawsze wymiana sygnałów między mną a PLC.

[adasko007]

Zapomniałem dopisać - soft jest różny w zależności od umowy z klientem. Zawsze najnowsza dostępna wersja, z HSCD, podstawowym DCS i paroma innymi drobiazgami. Generalnie standard.

[joker]

Dlaczego wiecej?? Wrzuc jeden, ktory bedzie monitorowal wiecej warunkow, ktore chcesz. Tyle, ze od jump lbl to sobie idzie zyly otworzyc... wiec lepiej karel chyba.
Bardziej przejrzysty jak dla mnie.

[adasko007]

A jak wynajdujesz bugi w karelu? W sensie takim, że z tego co pamiętam nie da się podejrzeć programów z TP (a to czasem przydatne info do diagnostyki- w jakiej jest linijce i co akurat robi robot) - ustawiasz jakies flagi albo coś?

To chyba takie moje zboczenie, że komunikacja MUSI być osobno ;p stąd wolę nie dawać w niej innych warunków monitorujących ;p

[joker]

Niestety nie mam jakiegos cudownego sposobu.

[adasko007]

Właśnie dlatego większość aplikacji u nas jest pisana w TP ;p