Beiträge von Sven Weyer

    Soweit ich mich erinnern kann muss auf jeden fall der Slave wissen wo sich zu Ihm die Base0 des Masters befindet.

    Was ja an sich logisch ist, sonst weiß er ja im koordinierten Verfahren nicht in welchem Bezug sich sein Master bewegt.

    Und das muss, je nach Anforderung schon hübsch genau sein, linear wie rotatorisch.

    Ist einfach,

    Tool einmessen mit Verfahren deiner Wahl, hängt davon ab ob du Z und X bestimmen möchtest in der Orientierung.


    Anschließend Tooldaten ein ein robtarget schieben und die Funktion RelTool zur Berechnung der Verschiebung benutzen. Das zur Verschiebung benötigte Tool sollte aktiv sein in der Steuerung.

    Anschließend kannst du die Daten vom pToolNeu ersetzen in deinem Tool bzw. in einem neuen um die orginal Daten nicht zu verlieren.


    z.Bsp::

    pToolAlt.trans:=tToolMessung.tframe.trans;

    pToolAlt.rot:=tToolMessung.tframe.rot;


    pToolNeu:=RelTool(pToolAlt,0,0,-25);


    tToolCalc.tframe.trans:=pToolNeu.trans;

    tToolCalc.tframe.rot:=pToolNeu.rot;


    So sollte es gehen ohne das du manuel etwas schieben bzw. kopieren musst.


    Voraussetzung für mein Bsp. ist das Z+ die Stoßrichtung vom eigentlichen Tool ist und die Messspitze 25 mm lang war. ;)


    Gruß

    Sven

    Moin,

    ich hatte RoboTeam 2009/2010 bei BMW in München, und mir war so das beide Roboter voneinander wissen müssen wo die Base0 sich im Bezug zum anderen Roboter befindet.

    Zumindest musste der Slave wissen wo die Base0 sich vom Master befindet.

    Unsere Roboter standen damals ca. 8m auseinander und haben die Karosse vom 5er Touring miteinander bewegt.

    Hier gab es versuche mittels Messspitzen beide Roboter miteinander auszumessen, was von der Genauigkeit her nie gegangen wäre.

    Wir haben die Roboter dann per Laser miteinander vermessen, dann hat es funktioniert.


    Was damals aber auch ein riesen Thema war, die koordinierte Bewegung der beiden, da hat KUKA ganz schon zu tun gehabt.


    Ich hatte dort beide mit Referenzen ausgestattet und miteinander bewegt und man konnte sehen wie groß die Abweichungen waren bei liniearer aber auch rotatorischer Bewegung, trotz Vermessung per Laser.

    War damals recht knifflig für KUKA.


    Gruß


    Sven

    Servus,

    soweit ich weiß unterliegen die einzelnen Achsen gewissen Stopp-Toleranzen, das ist explizit bei externen Achsen wohl etwas gröber ausgelegt als bei den allgm. 6 Achsen im koordinierten Verfahren.

    Schau einmal bei den Parametern der externen Achse hier sollte eigentlich was zu finden sein was die Stopp-Toleranz angibt.


    Soweit mal aus der Hüfte. ;)

    Lässt vermuten das entweder deine Umdrehungszähler nicht korrekt aktualisiert worden sind oder die Kalibrieroffsets nicht korrekt sind, ist ein typisches Verhalten des Roboters bei einer solchen Thematik.

    das ist ganz simpel


    man nehme: RelTool(Offs(p1,0,0,0),0,0,0\Rx:=0)


    Du schreibst aktuell die Rotation in deine Offset-Funktion, das geht leider so nicht.


    Immer einzeln betrachten!


    RelTool(pBasis,0,0,0\Rx:=0,\Ry:=0,\Rz:=0)

    nun Ersetze pBasis mit einer Offset-Funktion: pBasis:=Offset(pBasis,0,0,0);

    das seiht dann so aus:

    RelTool(Offset(pBasis,0,0,0),0,0,0\Rx:=0,\Ry:=0,\Rz:=0)


    geht natürlich auch anderes herum:


    Offset(pOriginal,0,0,0)

    pBasis:=RelTool(pBasis,0,0,0\Rx:=0,\Ry:=0,\Rz:=0)-> die nicht verwendeten Rotationen kann man auch weg lassen.


    macht dann:

    Offset(RelTool(pBasis,0,0,0\Rx:=0,\Ry:=0,\Rz:=0),0,0,0)


    Den Spaß kann man recht weit treiben, da ist RAPID recht flexibel.

    Na ich würde dies ohne die Instruktion CirPathMode verwenden und die Winkel dann zwischen den Position so anpassen.


    So wie ich das kenne hast du dann seitens der Orientierung bei der Instruktion CirPathMode keine direkte Kontroller mehr darüber.


    Aber ich ging bei meinen Kommentar davon aus das du eine Möglichkeit suchst einen Winkel bei einer Position anzupassen.


    Die Verbindung zu CirPathMode habe ich dabei nicht in Betracht gezogen.

    Du könntest auch die RelTool-Funktion dafür verwenden.

    Diese funktioniert nicht nur in den Move-Instruktionen sondern diese kann auch andersweitig verwendet werden.


    z.Bsp.: pNeu:=RelTool(pOrginal,0,0,0\Rx:=0,\Ry:=0,\Rz:=);

    Moin,

    wir haben uns da scheinbar missverstanden.

    Die Base muss am Schleifer eingemessen werden.

    Du nimmst dein aktuelles Tool und das eingemessen BASE am Schleifer musst du mit #TCP definieren, wie weiter oben beschrieben.


    Aber du kannst durchaus die andere Variante verwenden, wird dir aber Probleme bei Zirkularbewegungen machen, da die Rotation und Berechnung der Bahnplanung dann um deinen normalen TCP stattfinden wird und nicht um den stationären Schleifer.

    Da ja während deines Bewegungsablaufes der Bezug Schleifer <-> normale TCP sich immer ändern, Ändert sich auch der Bezug zu deiner tatsächlichen Werkstückoberfläche und somit wird das die Qualität wie auch die Einstellmöglichkeiten beeinflussen unter Umständen.


    Aber, by the way, is your choice!

    Moin Nuri,

    also ich hätte die Polierscheibe gegen ein Hilfsmittel ausgewechselt mit welchem ich meine BASE einmessen kann, Mittelpunkt der BASE im Drehpunkt und dann X und Y-Richtung definiert.


    Wie die BASE im Raum liegt ist ja erst einmal egal, ich hätte mindesten X oder Y senkrecht aufgestellt, kann man mit einer digitalen Wasserwaage abgleichen, so mal auf die schnelle aber grundsätzlich muss da was genaues her.


    Deine aktuelle TCP am Greifer sollte mal reichen, der wird eh als BASE verwendet wenn du die BASE als stationären TCP definierst. Schau einmal in die config.dat dort gibt es einen Eintrag BASE_TYPE[32], normal unterhalb der BASE Namensvergabe in der Config.dat, hier wird beim einmessen der jeweiligen BASE über die KUKA-Funktion immer #BASE eingetragen, hier muss dann für deine eingemessene BASE #TCP eingetragen werden.


    Anschließend einmal per Hand verfahren, siehe Doku, dann siehst du beim umorientieren das du um den Mittelpunkt deiner Base umorientierst wenn du um das Tool umorientierst.


    Gruß


    Sven

    Naja die Doku ist diesbezüglich etwas grausam.

    Sehen wir uns einmal die beiden Daten an, Tool bzw. Basedaten. Beides sind vom Typ FRAME, x,y,z,a,b,c sonst nix.

    Somit sind beide Datentypen identisch nur der letztliche Bezug der Informationen ist ein andere.

    Die Tooldaten beziehen sich auf das Tool0-Koordsinatensystem und die Basedaten auf das Base0-Koordinatensystem.


    Wenn du jetzt dein Schleifer als Base einmisst und der Steuerung sagst das du dieses als externen TCP nutzen möchtest sollte das schon ausreichen.


    Die Beschreibung in der Doku habe ich mir einmal angesehen und ist teils recht verwirrend.


    Man muss nur wissen das bei einem Wechsel von #BASE auf #TCP in dem BASE_TYPE Daten sich jetzt beim Umorientieren der Focus auf dem Ursprung des BASE liegt und nicht auf dem aktuell verwendeten TCP's


    Somit denke ich, das du dir eine BASE einrichtest in den Mittelpunkt deines Schleifers und dann die Info in den BASE_TYPE für dieses Base auf #TCP änderst.


    Gruß

    Ich denke das du ein Hilfsmittel benötigts um das du den Mittelpunkt deiner Polierscheibe einmessen kannst.


    Du benötigst einen TCP und deine Polierscheibe, Rotationsmitte kannst du als BASE einmessen und bei den Systemdaten in der config.dat BASE_TYPE kannst Du anstatt #BASE -> #TCP verwenden. Die Steuerung wird diesen dann als extern TCP bzw. stationären TCP erkennen und behandeln.


    Soweit einmal aus dem Gedächtnis, aber schau dir bitte noch einmal die Doku dazu an da steht das alles korrekt beschrieben.


    Gruß

    Also ich hab mir das einmal angesehen vorher.

    Denke das du mit Verwendung vom Pythagoras besser wegkommst.

    Vermessen als externes Tool sollte deine Polierscheibe schon sein, oder?

    Bei dem Konzept mit dem Verrechnen sollte sich der Mittelpunkt im Mittelpunkt deiner Polierscheibe befinden da du ja das Zustellen deiner Positionen über die Reduzierung des Radius verrechnen kannst mit Hilfe vom Pythagoras.


    Hast du dir das einmal angesehen mit dem Pythagoras?

    Trigonometrischer Pythagoras – Wikipedia

    Fange doch einmal leicht an.

    Zeichne dir einmal das stationäre Koordinatensystem auf, externe TCP später.

    nun hast du ein zweidimensionales Koordinatensystem, wie früher in Mathe und Geometrie auch, oder.


    Dann hast du verschiedenen Positionen mit dazugehörigen X und Y Werten, daraus ergibt sich ein Winkel zwischen X und Y,

    Den kannst du wieder nehmen und mit cos und sin deine Offsets für die Distanz zum Kreis, deiner Polierscheibe berechnen.

    Oder eventuell einfacher Satz des Pythagoras, c²=a²+b², c wäre dein Radius , a und b dein x und y.

    Umstellen nach c bzw. deines Radius und du kannst diesen Reduzieren und erhältst x und Y je nach dem nach was du umstellst.

    Aber ich hab da immer lieber die Winkelfunktionen verwendet.