Beiträge von atw11m92

    Der Grund ist dafür, dass der Roboter im Prinzip irgendwo stehen könnte.
    Dann würdest du den schnellsten Weg mit dem Roboter in die Home-Positoin anfahren.
    Da wird es wahrscheinlich krachen!!
    Darum solltest du vorher im Handmodus den Roboter in die Home fahren.
    Das Programm ist schon richtig so!!

    $pos_act_mes -> liefert also dann die Position über die Incremente gerechnet
    und nicht den Sollwert - ist dies richtig?
    Diese Variable wäre dann im Momentenbetrieb hilfreich um zu prüfen, ob wir den Zielpunkt annähernd erreicht haben.


    Haben heute versucht, über den sps.sub die curr_red[,] Werte zu ändern.
    Der Gedanke wäre folgender: Wir fahren den Zielpunkt im Momentenbetrieb mit sehr hohen Strömen an, damit wir ihn sicher erreichen. Im sps.sub prüfen wir, ob die Ströme diese Schranken erreichen und verringern dann dort die curr_red[] Werte wieder, damit wir keine I2t Stopmeldungen bekommen.
    Bei uns ist es zb. die A1, die am Ende der Bewegung auf 60% steht. Anschliessend wird im sps.sub auf einen Wert >59% geprüft und der
    curr_red[1,x] dann auf 40% herrunter gestellt. Entspannt sich dann die A1 auf 40% - oder muss erst ein Bewegungssatz gestartet werden!?!?

    Hallo,


    also wir stellen die curr_red[x,x] Werte für die Achsen ein.
    Machen dann ein $torque_axis='xxxxxx' für die entsprechenden Achsen
    und dann einen Bewegungssatz $pos_act um den Momentenbetrieb zu starten.
    Ab einem bestimmten erreichten Punkt wirkt dann eine Kraft auf den Roboter.
    Anschliessend schalten wir diese Achsen völlig weich - curr_red[x,x] auf 0.
    Haben anstatt von $pos_act auch lin_rel{z 0} versucht - durch das "Soft" schalten möchten wir erreichen, dass sich der Roboter entspannt.
    Daraufhin schalten wir die Achsen wir auf Standard und fallen bei Bewegungssatz auf $pos_act durch Überlast aus der Automatik!!


    Unsere aktuelle Lösung sieht nun mal so aus, dass wir den Roboter völlig in den Momentenbetrieb schalten - leider steigt er uns nun manchmal durch einen I2t Fehler aus!!

    Wir machen mit unserem Roboter, mit seinem Werkzeug, eine Art Fügevorgang.
    Dazu schalten wir den Roboter in den Momentenbetrieb(A1,A4,A5,A6,E1), damit sich der
    Roboter beim Einfügen etwas vergehen kann.
    Danach schalten wir die genannten Achsen völlig weich, warten eine Sekunden und schalten
    wieder alles auf Standardwerte.
    Anschließend haben wir als Bewegung ein $pos_act - bei diesem Bewegungssatz steigt uns dann fast
    jedesmal eine dieser Achsen aus!!


    Wohin versucht der Roboter beim $pos_act zu fahren?
    Möchte er zum Sollwert(ohne Momentenbetrieb) oder wirklich auf die aktuelle Position!?!?

    Hurra,


    wir haben zumindest eine Ursache gefunden für die Fehlstellungen.
    Leider ist es ein mechanisches Problem und nicht steuerungstechnich zu beheben ;)
    Wir haben bemerkt, dass sich das Getriebe minimal verdreht. Anscheinend wurden zur Befestigung keine Passchrauben bzw. Passstifte verschwendet. Darum kann sich das Getriebe innerhalb der Differenz zwischen Bohrungsdurchmesser und Befestigungsschrauben verdrehen.
    Somit läßt sich auch erklären, warum es zur Fehlstellungen in beide Richtungen kommt und warum es nie mehr wurden.
    Werden jetzt mal die Mechanikprobleme beheben und schauen was dann passiert!!

    so, hab jetzt mal selbst in die MADA rein geschaut.
    bei IN_POS_MA[7] steht 0.1; IN_POS_CAR=0.1


    heisst dies, dass alle Achsen 0.1° falsch stehen dürfen, aber wenn die Kartesische Position trotzdem auf 0.1mm passt, ist es dem System auch recht!?!?
    lt. KUKA regelt die KRC im 0.001° Bereich, warum erlaubt man dann 0.1°??



    REAL $IN_POS_CAR=0.100000001 ;KARTESISCHES POSITIONIERFENSTER (TRANSLATIONSSTEIL) [MM]
    REAL $IN_POS_ORI=0.100000001 ;KARTESISCHES POSITIONIERFENSTER (ORIENTIERUNGSTEIL) [DEG]
    REAL $IN_POS_MA[12] ;POSITIONIERFENSTER ACHSE[I] (I=1:A1,I=7:E1) [MM,GRAD]
    $IN_POS_MA[1]=0.100000001
    $IN_POS_MA[2]=0.100000001
    $IN_POS_MA[3]=0.100000001
    $IN_POS_MA[4]=0.100000001
    $IN_POS_MA[5]=0.100000001
    $IN_POS_MA[6]=0.100000001
    $IN_POS_MA[7]=0.100000001
    $IN_POS_MA[8]=0.100000001

    Gestern wars wieder mal soweit, dass die Abweichung an den Werkzeugablagen "zu hören" war.
    Darauf hin hatten wir den Referenztest wieder durchgeführt -> der Abstand vom ursprünglich geteachten Punkt war ca. 10mm.
    Nach geprüfter Justage stellten wir fest, dass die E1 eine Abweichung von 0.09° hatte -> Nach Korrektur passten die Referenzpositon und die Werkzeugablagen wieder perfekt.


    Nach ca. einer Stunde teachen und ein paar mal Schutzraumverletzungen -STOP0, war die E1 wieder falsch. Nur diesmal ca. 0.04° in die andere Richtung.


    Unsere E1 ist mit KUKA Motor(Evolventenverzahnung) angetrieben. Dann ein Cyclogetriebe und ein Antriebsritzel mit Verzahnungsqualität 5/6 - also spielfrei. Die gesamte Übersetzung ist 8092/10.


    Die 0.09° entsprechen ca. 3000 Resolverinkremente - dies entspricht ca. einer 3/4 Umdrehung der Antriebs.


    Wie kann dies sein??

    Genau dies ist unser Problem - wir verstehen es auch nicht.
    Wir machen einfach jeden Morgen den Referenztest.
    Mal passt die Position mal nicht - das kann doch nicht sein, wenn an der Mechanik alles gleich bleibt!?!?!?

    OK, leider muss die E1 auch "Safe" sein - ist ein synchrone Zusatzachse, dh
    unser Roboter hat 7 Achsen die sich gleichzeitig bewegen.
    Das Problem ist, dass der Roboter somit falsch positioniert wird und wir unsere Punkte natürlich
    falsch anfahren. Der Roboter macht dann eine optische Vermessung mit einem Stereokamerasystem.
    Leider wissen wir dann nicht, ob der Roboter falsch steht, oder ob sich das Objekt verschoben hat.!!!!

    Der Roboter steht selbst auf der Achse (wie lineare Zusatzachse - nur rotatorisch eben)
    Die Achse hat vom Drehtpunkt zum Drehpunkt A1 einen Abstand von 2.75m.
    Die Punkte haben wir ganz normal mit Inlineformularen geteacht - also nichts aufregendes.
    Wir untersuchen gerade nebenbei, ob sich die STAKO wo das Zeugs steht etwas verschiebt, weil ja bei uns Dinge mit bis zu 250T vorbeifahren!!

    Beim Oszi kann man leider keine Variablen mitloggen.
    Der Fehler tritt bis jetzt ca. 2x pro Monat auf.
    Kann man so lange Perioden aufzeichnen?

    Bei einer unserer Anlagen tritt sporadisch ein Fehler auf, denn wir absolut nicht nachvollziehen können.
    Deshalb möchten wir die Parameter, die wir mit unserer externen Steuerung austauschen selbst mitloggen, weil wir dem Logging der ext. Steuerung noch nicht 100% glauben schenken.
    Gibt es zum Loggen von I/O's etwas Brauchbares? Hat jemand eine Idee wie wir dies realisieren könnten?
    Wir hatten zb. daran gedacht, die Paramter als Art Hinweismeldung abzufeuern, dann werden sie ja automatisch von der KRC2 geloggt.

    Ganz überraschend haben wir gestern bei unserer KRC2 keine Module mehr anlegen können.
    System hat gemeldet, dass kein physikalischer Speicher mehr frei ist.
    Gibt es eine Beschränkung, wieviele Module vorhanden sein können? Oder haben wir wirklich unsere Festplatte zugemüllt?

    Hallo,


    ja wir haben die Achse vermessen lassen, weil die Fertigung etwas "schlampig - chinesisch" war.


    Eigentlich sollte es doch egal sein, ob die Werte exakt sind - der Punkt beim Referenztest wird ja wiederholgenau und nicht absolutgenau angefahren - oder?

    Wir nehmen gerade einen KR500 incl. Zusatzachse(rotatorisch - RobRootKinematik) in Betrieb. System ist mit SafeOperation ausgestattet.
    Jetzt haben wir ab und zu das Problem, dass der Referenztest fehl schlägt, weil der Roboter(offensichtlich ist es die Zusatzachse) nicht richtig steht.
    Wir haben natürlich beim ersten mal, als dies passiert ist, die Justage geprüft - war einwandfrei.
    Das Getriebe bzw. die Verzahnung für die Zusatzachse ist "spielfrei" gefertigt.
    Hat jemand schon etwas ähnliches beobachtet. Der Fehler kann bis zu 10mm betragen, wobei der Abstand auf einer Kreisbahn liegt - deshalb ist der Grund offensichtlich in der Zusatzachse zu finden - die Position in "Z-Richtung - WORLD" passt immer perfekt.
    Beim Referenztest sollte doch die Wiederholgenauigkeit ausschlaggebend sein? Der Antrieb ist ebenfalls ein KUKA Motor mit Cyclogetriebe!