Posts by yuminist

    Hallo Jens,


    soweit ich mich erinnere, finden diese Einstellungen in den Sicherheitseinstellungen statt. Dort können Motormomente, Leistungen und andere Einstellungen vorgenommen werden.

    Diese findest du (achtung meins ist englisch) unter Program Robot => Installation => Safety (passwortgeschützt) => General Limits => Advanced Settings


    Anbei ein Screenshot wie das aussehen sollte:


    Dort kannst du jetzt ihm Rahmen der Möglichkeiten deine Einstellungen vornehmen.

    Wofür soll die Weltzone eingesetzt werden?


    Wie ich das sehe ist eine bewegte Zone nicht möglich. Aber wenn du nur abfragen möchtest, ob das Tool in der Zone ist oder nicht, was spräche dagegen das Werkobjekt welches sich zum Toolbewegt abzufragen?


    Oder habe ich da etwas gänzlich missverstanden?

    meines wissens nach brauchst du ein signal welches dem roboter die aktuelle stellung mitteilen kann (beispielsweise ein inkrementalgeber)


    ich wüsste nicht ob und wie es ohne gehen könnte.


    wenn es eine konventionelle drehbank ist, stehen die chancen denke ich schlecht - mit cnc maschinen kenne ich mich leider nicht genug aus um eine aussage treffen zu können

    was bekommst du denn an werten von deiner externen achse?


    beispiel: werte kommen von -180 bis 180
    dann könntest du bei jedem sprung von 180 auf -180 einen zähler inkrementieren und hättest somit deine umdrehungen die du nach lust und laune weiterverwenden kannst

    Wenn ich das richtig verstanden habe...


    nimmst du mit CrobT die aktuelle Position auf (beispielsweise in eine PERS pTemp)....dann kannst du vergleichen ob es dieses target schon gibt (hierzu würden ja die trans und rot werde ggfs. reichen) ... falls diese prüfung negativ ausfällt kannst du es ggfs. als neues RobTarget erstellen.... da bin ich allerdings überfragt - allerdings könnte dir eventuell dieser thread hier weiterhelfen
    https://www.roboterforum.de/ro…laufzeit-erstellen/13705/

    Hängt vom Netzwerk ab in dem die Steuerung läuft - der Serviceport schreit recht laut und vor allem schnell als DHCP ins Netzwerk.


    Ich hatte das Problem hier mal versehentlich verursacht und die ganzen Rechner im Netzwerk bekamten die IP dann vom Serviceport weil dieser wesentlich schneller war als der eigentliche Router

    Moin,


    folgende Situation:


    auf einem Förderband werden Produkte klassifiziert - iO nIO halb iO oder was es da noch so geben soll. Das ganze wird über DI übergeben (beispiel alle aus heisst nio - di1 an ist dann io usw...)
    soweit ist das auch klar...aber


    für die Klassifizierung wird das Förderband nicht angehalten. Erst am Roboter selbst werden die Produkte zur Entnahme gestoppt (denn soweit ich das sehe kann UR noch kein ConveyorTracking)


    demzufolge entstand die Idee, dass eine FiFo Liste angelegt wird, anhand derer der UR dann erkennen kann, welche Klassifizierung das aktuell ankommende Produkt nun hat. Das Ganze hat nun zwei Haken:
    1. Ich bin mir noch unschlüssig wie ich sicherstelle, dass ich merke sobald die Liste durcheinander kommt (beispielsweise bleibt ein Produkt aus irgendeinem Grund hängen und wird zwei mal klassifiziert)


    2. muss auf die FiFo Liste parallel zugegriffen werden. Und zwar einmal schreibend am Ende sodass für die fortlaufende Produktnummer eine Klassifizierung hinterlegt wird, und einmal Lesend vom UR (ja und später auch schreibend um den Eintrag zu entfernen) um dem aktuellen Bauteil die Klassifizierung entnehmen zu können.


    bei den großen (teuren) stellt das kein Problem dar. Parallele Prozesse beim UR ist allerdings meine persönliche Premiere und ich frage mich, wie das dort ablaufen könnte. Geht das direkt über das Linux-System in einem Hintergrund-Task oder läuft das über die Python-Scripte in der UR Oberfläche? Diese werden meines Wissens nach ja auch seriell und nicht parallel abgearbeitet?


    //EDIT
    okay wer das Handbuch richtig liest, entdeckt auch den 'Thread'-Befehl :pfeif:

    muss zwingend das gesamte koordinatensystem gedreht werden?


    so wie ich das sehe, reicht es den oframe zu drehen/schieben denn dieser ist der der angefahren wird.


    Code
    1. ptemp:=pdeinreferenzpunkt
    2. wtemp:=wdeinwerkobjekt
    3. wtemp.oframe.rot:=OrientZYX(90,0,0);
    4. MoveL ptemp, v1000, z30, tool1\wobj:=wtemp;
    5. wtemp.oframe.trans.x:=30; !hier deine inkremente die du abtasten willst in einer achse


    das ganze kannst du dir in eine kleine routine packen und den referenzpunkt übergeben sowie ggfs die dreheung
    hier fehlt natürlich noch die palettierungsfunktion die entscheidet, nach wievielen punkten oder welchem maß das raster eine zeile weiter springen soll.


    habe ich das so korrekt aufgefasst?


    alternativ:
    du sagtest du da hast einen geteachten (referenz-) punkt.
    wieso drehst du diesen nicht und schiebst ihn mittels offsets? das ginge sicher auch

    Micky


    vielen Dank für diese Aufschlussreichen Infos


    Dass robtargets nicht pers sein müssen war mir neu -.-


    Quote

    Da deine Zone kein optionaler Parameter ist, macht die Abfrage "IF Present(Zone)" keinen Sinn, da dieser Parameter immer vorhanden ist.


    das hätte ich fast übersehen - war ein überbleibsel und natürlich völlig korrekt dass das so keinen sinn macht :)



    @was
    auch das funktioniert :)


    ich danke euch

    Moin,


    auch wenn so kurz vor dem Wochenende:


    Ich habe mir folgendes geschrieben: (über Sinn und Unsinn kann man sicher streiten)

    Code
    1. PROC Test_Move2Pos(PERS robtarget pTarget,PERS tooldata tTool,PERS wobjdata wWobj,num Offset{*},speeddata TravelSpeed,zonedata Zone\switch Finepoint)
    2. IF NOT Present(Zone) THEN
    3. MoveJ Offs(pTarget,offset{1},offset{2},offset{3}),TravelSpeed,z5,tTool,\WObj:=wWobj;
    4. ELSE
    5. MoveJ Offs(pTarget,offset{1},offset{2},offset{3}),TravelSpeed,Zone,tTool,\WObj:=wWobj;
    6. ENDIF
    7. IF Present(Finepoint) MoveL pTarget,TravelSpeed,fine,tLocal\WObj:=wWobj;
    8. ENDPROC


    jetzt habe ich folgendes im weiteren Verlauf versucht:

    Code
    1. Test_Move2Pos RelTool(pReorient,0,0,-20),tGripper,wReorient,[0,0,0],vPlace,z0\Finepoint;


    und bekomme dann

    Quote

    [...](38,22): Argument error(123): Argument for 'PERS' parameter pTarget is not a persistent reference or is read only. 17.05.2019 14:08:24 General


    mein Problem liegt nun darin, dass ich mir zwar denken kann worüber er sich beschwert (vermutlich werden die Daten nicht als robtarget wie gewünscht übergeben), aber leider keinen Ansatz habe wie ich das beheben kann ohne 400 weitere Funktionen oder Routinen zu schreiben.


    Ist das so überhaupt machbar oder sehen die Praxiserfahreren Damen und Herren da einen besseren Weg?


    Grund ist im Übrigen dass ich das Programm schlank und lesbar halten möchte.


    Ein schönes Wochenende wer hat

    so - sorry für die verzögerung


    Sebastian78
    du hast mich da etwas falsch verstanden - ich bekomme von zwei kameras je einmal translations- und rotationsdaten
    diese werden dann getrennt voneinander verarbeitet.
    pro kamera bekomme ich also x und y sowie ein rotationsoffset


    im grunde also genau das, was posemult braucht (eine pose)


    mittlerweile habe ich das problem des versatzes gefunden und behoben


    es lag wie programmiersklave schon richtig anmerkte, an kleinigkeiten. das koordinatensystem von kamera und roboter war nicht exakt synchron (da muss ich mal schauen wie man das besser einrichten kann) und der TCP war nicht zu 100% rotationssicher (wird dann wohl in naher zukunft elektronisch vermessen)


    alles in allem also die summe kleinerer abweichungen

    Sebastian78


    Die Stoßrichtung des Werkzeugs ist korrekt (ich weiß gar nicht wie oft ich das mittlerweile geprüft habe XD) und ich habe es sogar soweit dass es "rotationstreu" ist. Sprich drehe ich das Tool um Z um eine Spitze, bleibt diese wo sie ist (ist bei händischer Kalibrierung nicht selbstverständlich)


    Warum ich die Translation im oFrame und die Rotation im uFrame machen sollte, erschließt sich mir noch nicht.
    Im Grunde gibt es doch genau für solche Zwecke "PoseMult", oder nicht?


    Mit der Rotation an sich habe ich weniger Probleme (die Rotatorische Ausrichtung passt ja) - nur der Versatz in XY irritiert mich.


    Ich denke das Hauptproblem ist - wie Programmiersklave schon anmerkte - dass dies ein Grenzbereich ist. Ich versuche mich hier so weit es geht unter einem Zehntel genauigkeit zu bewegen.


    Nachdem ich mich die letzten Tage wesentlich mit den Tools, dem Referenzobjekt und den Objektträgern beschäftigt habe, komme ich langsam zum Schluss, dass man über eine rein elektronische Kalibrierung nicht drum herum zu kommen scheint wenn man sich in diesem Bereich zuverlässig bewegen will.


    Ah, jetzt wird es klarer, hatte Dich da falsch verstanden.


    Okay, bei solchen "Winzigkeiten" bin ich raus, das sind Laborbedingungen, die man m. E. einer Industrieanlage eher nicht aufbürden kann, jedenfalls nicht ohne pragmatisch funktionierender Kalibrierlösung.


    Grüße,
    Michael


    Ja leider geht es genau darum. Das ganze hat noch lange keinen Stand den man in einer industriellen Umgebung einsetzen könnte. Aktuell geht es nur um "klappt das generell" und das erheben von Daten um diese auswerten zu können.


    Solange ich da aber solche "Krankheiten" drin habe, ist dan reproduzierbare Daten leider nicht zu denken.

    Zunächst einmal vielen Dank für die Mühe


    Sebastian78
    Ich habe es auf einen Versuch ankommen lassen - ohne Erfolg. Für mich möchte ich eine Re-Orientierung nicht auf UFrame und OFrame aufteilen.
    Der UFrame ist der Träger und der OFrame die "Zielposition"


    Programmiersklave
    Ganz durchblickt habe ich noch nicht wie du deinen Ansatz meinst.
    Allerdings habe ich den Eindruck, was nicht richtig beschrieben zu haben.


    Das Kamerasystem an sich gibt nur eine Translatorische und Rotatorische Abweichung des Objektträgers heraus inwieweit er vom "ideal" abweicht.


    Die Verrechnung des OFrame beinhaltet die Setzpositionen aus einem Array (CAD-Daten)
    Die X/Y Koordinaten sowie die Orientierung (Teile 3-7 werden 180° gedreht gesetzt) kommen also aus diesem Array und nicht aus dem Kamerasystem.
    Das Kamerasystem erfasst lediglich die fixen Punkte von denen aus bemaßt wurde.


    Wenn ich deinen Ansatz korrekt verstanden habe, müsste der Fehler bei Positionen 1 und 2 jedoch auch sichtbar sein. Denn die Positionen 3-7 weichen ja >1mm vom soll ab.
    Wir bewegen uns hier im Zehntelbereich was die Positionierung angeht.


    Was genau du mit "rauskalibriert" meinst, ist mir nicht gänzlich klar.


    //EDIT
    Kurzer Nachtrag:
    ich habe die Tools soweit nochmal eingemessen und mir kamen die Werte etwas eigenartig vor => also nochmal eine Feinkalibrierung durchgeführt.
    Das Ergebnis der Einmessung danach lautet für tGripper 0.23 mittlere Abweichung.


    Der Fehler an sich hat sich verändert. Nun passen Punkte 1 und 2 zwar nach wie vor, allerdings nicht mehr ganz so "perfekt" wie vorher. Punkte 3-7 hingegen sind in y gewandert (zum soll hin)


    sobald alle Punkte die gleiche Abweichung haben, ist es einfach - dann muss der UFrame nur noch deckungsgleich mit dem Rest gebracht werden und es sollte passen.


    Leider haben wir keine Hardware zum Einmessen der Tools => also versuche ich das Einmessen "Spitze-Spitze" mit 4 Punkten.
    Hat jemand eine bessere Strategie?

    Guten Morgen,


    seit ein paar Tagen verfolgt mich ein Problem für das mir die Lösungsansätze ausgehen...


    Folgendes Szenatio. (Roboter ist ein IRB14000)


    Auf einem Objekttäger, welcher mittels Kamera eine Positionsvermessung durchläuft (Lage und Rotation) sollen Objekte Platziert werden.
    Die Plätze stammen aus dem CAD und wurden auch verifiziert. (Plätze 1-7)


    Im Zuge der Fehlersuche habe ich mit einem Tool welches an dem Saugeranschluss des Smartgrippers ("Daumen") angebracht ist (Spitze), die Positionen abgefahren. (name "tCalib")
    Diese Spitze fährt die Kalibrierte (fixe) Aufnahmeposition an, und dann jede Setzposition für sich ohne zur Aufnahmeposition zurückzukehren.


    Fahre ich diesen Test, wird jede Position so angefahren wie gewünscht. Hier findet keine Umorientierung statt.


    Mache ich einen ähnlichen Test mit dem Greifwerkzeug (angebracht am Servo - Name "tGripper") bekomme ich Probleme.
    Diese Routine nimmt ein "ideales" Objekt mit tGripper aus der selben definierten Position und fährt ebenfalls über die Setzpositionen.
    Positionen 1 und 2 werden normal angefahren, 3 bis 7 um Z 180° gedreht.


    Soweit hoffentlich verständlich.
    Das Problem ist nun, dass Positionen 1 und 2 wie gewünscht "getroffen" werden, Positionen 3 bis 7 allerdings in X und Y um jeweils >1mm verschoben sind.


    Die Positionsbestimmung wird folgendermaßen durchgeführt:
    Kamera und UFrame haben den selben Ursprung.
    Der OFrame wird mit PoseMult an die jeweilige Setzposition verschoben und dann der Punkt 0,0,0 angefahren (also der OFrame selbst). Hierbei sind der Versatz und die Rotation welche die Kamera mitteilt bereits eingerechnet (das würde nun zu weit führen denke ich)


    Meine bisherigen Ansätze waren:
    - Würde das Tool nicht passen, hätte ich den selben Versatz an allen Positionen
    - Würde die "Kalibrieraufnahme" nicht passen, hätte ich den selben Versatz ebenfalls an allen Positionen
    - Würde die Kamera und damit das PoseMult falsch arbeiten, hätte ich variierenden Versatz an allen Positionen


    Die Tools habe ich Rotatorisch geprüft (Spitze - Spitze und dann rotieren lassen => blieben aufeinander)


    Vielleicht gibt es hier eine Muse die den entscheidenden Hinweis geben kann...