Woher weiss der robi wo er steht

  • ANZEIGE
  • Die manipulationssicherste Variante sind übrigens Weltzonen, die bei Erreichen einen Ausgang setzen. Der kann dann im Programm abgefragt werden.

    Erfordert aber eine Zusatzoption und hängt auch von der Steuerungsgeneration ab.

  • Ich rede nicht von sicherheitsrelevanten Funktionen. Dafür sind Weltzonen keineswegs geeinigt und es muss SafeMove eingesetzt werden. Manipulationssicher ist natürlich nichts, was nicht sicherheitsgeprüft ist aber es ist sicherer als reiner Code im Anwenderprogramm, da Weltzonen nur nach Neustart neu definiert werden können.

    Wenn ich etwas manipulieren will und das System kenne, schaff ich es auch.

  • Ich rede nicht von sicherheitsrelevanten Funktionen.

    Ich auch nicht.


    aber es ist sicherer als reiner Code im Anwenderprogramm

    Nein, jedenfalls nicht bei Verwendung kartesischer Zonen (Quader, Kugel, Zylinder). Das wollte ich nur anmeckern, da ich es oft genug schon anders gesehen habe.


    Szenario 1, eher unwahrscheinlich, aber nicht unmöglich, weil zumindest was den Bediener angeht schon selbst erlebt:

    Robbi steht auf dem zonenüberwachten Punkt. Bediener kommt her, will in bester Absicht was machen, Bewegungsart steht auf "Umorientieren". Bediener rudert mit Steuerknüppel um den aktiven TCP, das ist der, der beim Anfahren dieses Punktes aktiv war. Der Ausgang der Zonenüberwachung steht eisern auf 1. Bediener findet, dass der Roboter sich heute eher komisch bewegt, gibt auf, lässt alles so stehen und startet nach - bumm.


    Szenario 2, mir selbst schon passiert:

    ConfL und ConfJ arbeiten modal. Bei Abarbeitung einer Bearbeitungsroutine mit abgeschalteter Konfigurationsüberwachung bleibt irgendwas stecken. Der Bediener löst das Problem lokal und übergeht den nachfolgenden Teil der Bearbeitung, indem er den Programmzeiger direkt auf den zonenüberwachten Punkt setzt und anfährt. Der Ausgang wird 1. Leider hat der Bediener aber übersehen, dass bei der normalen Bearbeitung sich die Handachsen unter der Achse 4 wegbewegt hätten und die Handachsenkonfiguration jetzt, durch das versetzte Anfahren, auf dem Kopf steht. Bediener startet nach - bumm.


    Szenario 3, hab' ich auch schon mal gesehen:

    Beim Hochfahren des Systems geht irgendwas schief und die Ereignisroutine, die die Weltzonen definiert, wird nicht vollständig abgearbeitet. Infolgedessen wird auch kein Ausgang gesetzt. Der Fehler wird quittiert, jemand versucht, die Maschine zu starten. Das selbstbewusste Roboterprogramm hat zwar den Manipulator in der Homeposition, ist aber drauf dressiert, immer dann, wenn der Home-Ausgang wie jetzt nicht da ist, erst eine automatische Homefahrt zu versuchen. Die ebenfalls etwas zu selbstbewusste SPS hingegen kommt zu eigenen Schlüssen und hat nie daran gedacht, dass der Roboter so etwas tun wollen könnte und stellt ihm mal eben einen Antrieb in den Weg - bumm.


    Da bin ich mit einem durchdachten CJointT besser dabei.


    Grüße,

    Michael

  • Nur nochmal zu der oben bebilderten Progammlösung. Man könnte auch einfach schreiben:

    Code
     Func bool TestRobotOnPos(pos CurrentPos,pos PosToCheck, num Tol)
      return ((abs(currentpos.x-postocheck.x)<Tol) and (abs(currentpos.y-postocheck.y)<Tol) and (abs(currentpos.z-postocheck.z)<Tol));
     endfunc

    Und wenn man die Parameter als robtarget deklariert, dann kann man sich im Hauptprogramm auch noch diverse Zeilen sparen:

    Code
     Func bool TestRobotOnPos(robtarget CurrentPos,robtarget PosToCheck, num Tol)
      return ((abs(currentpos.trans.x-postocheck.trans.x)<Tol) and (abs(currentpos.trans.y-postocheck.trans.y)<Tol) and (abs(currentpos.trans.z-postocheck.trans.z)<Tol));
     endfunc

    Bilder vom Quellcode im Post sind auch nicht so prickelnd, da sollte man lieber den Code per copy/paste einfügen.

  • Hermann Es gibt da auch eine mitgelieferte Distance() Funktion.


    Es bleibt hier das Problem der unendlich vielen möglichen Orientierungen, die dem Roboter melden, dass er in Position ist, auch wenn die Orientierung so ungünstig liegt, dass es einen Crash gibt. Liegt daran, dass der TCP nur auf Translation geprüft wird. Das Risiko, dass dies passiert hält sich jedoch auch in Grenzen.

Hilfe und Support für ABB Roboter Programmierung, Konfiguration, Inbetriebnahme finden Sie hier im ABB Roboter Forum. ABB Rapid Programmierung ist einfach, die Roboterforum Community hilft sehr gerne.

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden