Der Befehl nennt sich XOR in der Informlist des TP.
Beiträge von Se.bastian
-
-
Alles klar dann weiß ich jetzt alles was ich wissen muss Danke dir vielmals für die super Auskunft!
-
Und das wobj0 ist fest wo? Denn aktuell verwendet das Programm ausschließlich wobj0 bei den move-Befehlen. Brauche ich dann ein neues wobj wenn der Robotersockel gedreht ist?
Wenn du mir das noch beantwortest sollte ich alles für den Auftrag wissen.
-
Alles klar, Trotzdem gibt man die Quaternionen und nicht die eulerschen Winkel ein. Aber das kann ich ja mit dem Code auf irgendein neues wobj anwenden, damit ich die 4 Quaternionen rausfinde und dann dort eingeben kann. Und das wobj0 ist fest wo? Denn aktuell verwendet das Programm ausschließlich wobj0 bei den move-Befehlen. Brauche ich dann ein neues wobj wenn der Robotersockel gedreht ist?
Sollte so Funktionieren oder?
-
Alles klar. Ich habe mittlerweile auch die Einstellungen im RobotStudio gefunden.
Noch eine Frage: Kann ich das wobj0 (ich hoffe mal, das ist das Basiskoordinatensystem?) einfach mit
VAR num RZ := EULERZYX(\Z, wobj0.oframe.rot);
RZ := RZ + 135;
wobj0.oframe.rot := Orient(RZ, 0, 0);
drehen?
Oder muss das über irgendwelche Menüpunkte geschehen?
PS: Die Zeilen habe ich im Eilverfahren geschrieben, müssten aber funktionieren.
-
Genau, 135° um die Z-Achse des Basis-Koordinatensystems.
Man kann das Basis-Koordinatensystem anpassen? Ist das denn so empfehlenswert? Ich dachte immer, das Basis-Koordinatensystem entspricht immer der Basis, wie es halt werksmäßig das tut und das kann/sollte man nicht ändern.Dass sich die Zonen auf die Base beziehen ist kein Problem, kann man ja einfach umstellen. (Hoffentlich)
-
Hallo liebe Community,
ich weiß, mein Titel ist etwas eigenartig aber so ist auch mein Anliegen:
Der Kunde will den Roboter (ICR2600) um 135° drehen, das Programm gehört aber dann natürlich entsprechend angepasst. Für die Positionen werde ich wohl einfach ein neues, um 135° gedrehtes Werkobjekt machen und gut ists. Aber was mache ich mit der SafeMove-Konfiguration? Muss ich die ernsthaft neu machen, oder gibt es da auch eine Möglichkeit, die ganze Konfiguration samt der Bereiche "einfach" um das Basiskoordinatensystem (und nur nach dem richtet es sich glaube ich) zu drehen?
Ich suche nach einer einfachen Lösung. Alles neu machen nur weil der Roboter um 135° gedreht auf dem selben Fleck steht, ist echt verdammt aufwendig und ich hoffe ihr könnt mir da helfen.
Danke und liebe GrüßeSebastian
-
Gruppenausgänge sind bei Yaskawa OG#(Gruppennummer). Es gibt auch die Möglichkeit der Halfgroup, was 4 Bits setzt oder eben nur ein Bit. Die genaue Syntax müsste ich morgen nachschlagen. Aber irgendsowas Richtung DOUT OG#(Gruppennummer), sollte in der Informlist leicht zu finden sein.
-
Hallo.
Mit dem Befehl CALL JOB werden Jobs aufgerufen. Wenn du am Teachpanel arbeitest, findest du den Befehl in der Inform-list.
LG
-
Die erste Annahme ist ungefähr richtig (siehe Einschränkungen im Handbuch und Svens Ergänzungen). Die zweite ist das Problem. Das "danach" ist nicht wirklich danach.
Der IF-Abfrageblock ist schon längst vom Programmzeiger durchlaufen worden, bevor der Bewegungszeiger in die Nähe Deiner MoveJSync kommt. Das Problem stellt sich häufig auch bei Eingangs-Signalabfragen und ist Quelle endlosen Ungemachs.
Im Grunde ist es nicht möglich, eine logische Entscheidung auf diese Weise zu treffen, ohne den Satzvorlauf zu synchronisieren. WaitTime \InPos,0; z. B., oder man wartet vor der IF-Entscheidung so lange, bis die SYNC-Routine durch einen dritten Merker zu verstehen gegeben hat, dass sie durch ist.
Wenn es darauf ankommt, dass die _Position_ erreicht wurde, ist Move*Sync sinnvoll und nötig. Wenn Du nur sichergehen willst, dass der _Programmteil durchlaufen_ wurde, brauchst Du kein Sync
Danke vielmals für die Antwort. Auf meiner To-Do-Liste steht bereits, die ganzen Move*Sync aus dem Programm zu verbannen. Ich denke ich habe die Funktionsweise jetzt verstanden. Ihr habt mir sehr geholfen!
LG Sebastian
-
1. du verwendest FINE -> Damit ist ein MoveSync überflüssig da der PZ eh erst nach erreichen und einregeln der Position weiter macht.
Bei z<> fine passiert leider das selbe. Ich habe einfach einen der vielen MoveJSync/MoveLSync kopiert, der hatte zufällig fine.
2. MoveSync verwendet den Verschleifbogen, da hier der Aufruf der Routine gestartet wird und je nach Prozessorauslastung du hier nach diesem Punkt eine Abarbeitung der Routine erwarten kannst. Achtung diese Abarbeitung hat nichts mit dem Pfad vom Roboter zu tun sondern ist Prozessorauslastungsabhängig. s.h. Referenzhandbuch -> MoveL/JSync
Wenn ich die Prozedur nach der Bewegung Aufrufe funktionierts. Soweit klar weil er ja Satz für Satz abarbeitet. Nur was ist der Unterschied zu MoveJSync/MoveLSync? Aus dem Referenzhandbuch werde ich zwar schlauer, aber so ganz hatte ich noch nicht die erleuchtung.
LG
-
Vielen Dank für deine Antwort!
Kurze Frage: Warum hast du dich hier für ein MoveSync entschieden?
Das Programm ist (leider) nicht von mir, ich darf "nur" die Fehler ausbessern.
-
Danke für deine Antwort!
Gar nie nicht oder nur nicht zum richtigen Zeitpunkt?
Kommt drauf an. Wenn ich das Programm kurz darauf stoppe, sind die Bits nicht richtig gesetzt. Wenn der Roboter aber nach der IF-Abfrage mit den falsch gesetzten Bits in den falschen Block spring und einen Crash fährt, dann sind die Bits im nachhinein richtig gewesen, was mir natürlich Kopfschmerzen bereitet hat, weil der IF-Block, in dem er da gestanden ist, ja dann eigentlich nicht mehr erfüllt war und den Bits währenddessen nichts anderes zugewiesen worden ist (Also der hätte da nicht sein sollen). Also es hat schon gedauert, bis ich die MoveJSync/MoveLSync als Problem identifizieren konnte.
Asynchron?
Ich arbeite genau einen Task ab. Ich bin noch kein Spezialist auf dem Gebiet, aber ich denke, da der Roboter das Programm ja Satz für Satz abarbeitet, sollte es ja Grundsätzlich funktionieren.
Wie bald ist bald?
Bald heißt, dass das Bit gesetzt wird und ein paar Sätze darauf (ist schwer zu sagen wie viele weil das Abhängig vom Programmablauf ist) in einer IF abgefragt wird.
Könnte mir vorstellen, dass Du in eines der typischen Satzvorlauf-Probleme gefallen bist. Wenn Du Bits bewegungssynchron setzt, aber "bald danach" asynchron abfragst, erfolgt die Abfrage u. U. lange bevor die Bewegung überhaupt an der Synchron-Position ankommt.
Wenn Du sie ebenfalls asynchron setzt, stimmt die Reihenfolge natürlich wieder.
Heißt das, dass ich in meinem Fall den MoveJSync/MoveLSync-Befehl nicht verwenden darf? Oder wie genau darf ich das verstehen? Ich dachte, dass der Synchron zur Bewegung die Bits setzt. Und wenn ich die Nach der Bewegung abfrage, sind die gesetzt wie gewollt?
LG Sebastian
-
Hallo liebe Roboter-Community,
leider konnte ich zu meinem Problem keine passende Lösung finden, also versuche ich es hier.
Mein ABB IRB2600 (Robotware 6.13.04.00) macht Probleme beim Abarbeiten des MoveJSync/MoveLSync.
Einer der Befehle, der Probleme macht:
MoveJSync pHome,vVorpos,fine,toGreifer\WObj:=wobj0,"MerkerHome";
PROC MerkerHome()
!
bVorposLL:=FALSE;
bVorposLR:=FALSE;
!
ENDPROC
Die Bits, die die Prozedur (in diesem Fall) auf FALSE setzt, werden im Programmablauf für die Steuerung der Abfolge der Funktionsaufrufe verwendet. Das Problem ist jedoch, dass die Bits im Automatikbetrieb definitiv nicht FALSE gesetzt werden (habe ich mehrmals verfolgt und kontrolliert). Die Bits werden ziemlich bald nach dem Aufruf der MerkerHome-Prozedur in einer IF abgefragt.
Ich habe daraufhin folgendes ins Programm hinzugefügt:
MoveJSync pHome,vVorpos,fine,toGreifer\WObj:=wobj0,"MerkerHome";
bVorposLL:=FALSE;
bVorposLR:=FALSE;
So setzt der Roboter nach der Prozedur "MerkerHome" die Bits definitiv wie gewünscht und alles läuft so wie es soll. Das Problem hatte ich bei allen MoveJSync/MoveLSync-Befehlen im Programm. Ich habe überall die Bitzuweisung darunter eingefügt und es passt.
Frage nun:
Warum funktioniert das Zuweisen mit MoveJSync (selbes Spiel mit MoveLSync) nicht? An der Funktion des Programms habe ich ja nichts geändert, nur weil ich die Zuweisung unter den MoveJSync/MoveLSync-Befehl geschrieben habe.Danke für eure Hilfe!
LG Sebastian
-
Ich konnte hier auch wieder was dazulernen, danke dir, Maverick, für die Frage und danke El Cattivo für deinen Beitrag dazu, das werde ich nicht mehr vergessen
Jetzt würde ich nur noch gerne wissen, ob ihr noch wisst wie man TCPON freischaltet. Das könnte ich vielleicht mal gebrauchen
-
Wenns son kleines unterprogramm schreibst reicht doch ein call nach jedem greiferwechsel.
Mit tcpon kenn ich mich nicht aus. Wenns unbedingt das sein muss, werde ich navhher nochmal alle meine unterlagen danach durchsuchen
-
Hallo,
ich mische mich auch mal ein. Ich glaube, du verwechselst zwei Befehle.
Es gibt beide Befehle:
Tool ON/OFF: Schalten eines Werkzeuges (z.B. Greifer) über Ausgänge, wobei dieses Werkzeug vorab definiert werden muss (Zuweisung der Ausgänge)
TCP ON/OFF: Anwahl eines TCP's im Programm. D.h. die gleichen Punktkoordinaten können mit unterschiedlichen TCP's angefahren werden, unabhängig davon, mit welchem TCP der Punkt geteacht wurde.
Den Befehl TCP ON/OFF finde ich auf dem Bediengerät gar nicht 🤔
-
Klick mal im job auf die taste 3, da steht "tool on job" bei mir. Automatisch kannst du dann den call job: toolon einfügen. Den müsstest du definieren und da drin könntest du dann folgendes einfügen:
NOP
'Bitcodierung prüfen
IF IG#(1)=1 THEN //Greifer 1
SET LB000 1 //LB000 = Greifernummer
ELSEIF IG#(1)=2 //Greifer 2
SET LB000 2
*
*Bis IG#(1)=255 erweiterbar
*
ELSE
SETUALM //Falls keine der Abfragen zutrifft, Fehlermeldung um Crash zu vermeiden
ENDIF
SETE P000 TL#(LB000) //Werkzeugnummer ändern
SETE P001 TL#(LB000)
.
.nur geht das mit den lokalen Variablen nicht, die müsste man als P var definieren
.
END
Was besseres fällt mir leider nicht ein
-
Hallöchen, endlich mal wieder eine Frage zu einem Yaskawa Roboter
Also ich habe mal meine Unterlagen durchforstet und herausgefunden, dass TOOLON dafür da ist, um eben ein Werkzeug einzuschalten, nicht um den TCP zu ändern. Hier ist ein Auszug dazu:
Den TCP kann man aber dennoch automatisch ändern:
Dazu muss man die Koordinaten des TCP auf eine P-Variable schreiben, so wie man den TCP eben auch ermittelt. Dann kann man , ich bin mir da jetzt aber nicht ganz sicher, mit einem SET-Befehl die Koordinaten der TCP-P-Variable auf eine Werkzeugnummer kopieren. So kannst du einem TCP unterschiedliche Koordinaten zuweisen und in der P-Variable, die du anfährst, kann dann immer die selbe Werkzeugnummer drinstehen. Mit einer Abfrage der Bitcodierung kannst du mit einem IF/THEN einfach nach der Abfrage der Codierung den TCP entsprechend setzen lassen.
Hab das selber erst einmal gemacht im Programmierkurs, brauchte das nie aber ich werde es morgen testen und hier davon berichten, sofern hier noch nichts anderen in den Antworten steht.
Bis dahin liebe Grüße,
Sebastian
Edit: Ich habe jetzt meinen Haufen an Unterlagen nach der Lösung abgesucht:
Ich schreibe jetzt ein kleines Programm hier auf, wie man das machen könnte mit den verschiedenen TCPs:
Ich gehe im folgenden Beispiel davon aus, dass die Bitcodierung des Greifers auf IG#(1) geschrieben wird. Kann natürlich ganz einfach angepasst werden, wenn dafür keine IG sondern z.B. eine B-Variable verwendet wird.
NOP
'Bitcodierung prüfen
IF IG#(1)=1 THEN //Prüfen, ob die Bitcodierung Wert "1" ist
SETE TL#(1) P001 //Wenn ja, setzt er die Koordinaten von P001 auf Tool1
ELSEIF IG#(1)=2 //Prüfen, ob die Bitcodierung Wert "2" ist
SETE TL#(1) P002 //Wenn ja, Koordinaten von P002 auf Tool1
*
*Bis IG#(1)=255 erweiterbar
*
ELSE
SETUALM //Falls keine der Abfragen zutrifft, Fehlermeldung um Crash zu vermeiden
ENDIF
'Bahn frei für den Roboter
MoveJ
MoveJ P012
MoveL
END
Für Syntaxfehler übernehme ich keine Verantwortung
-
Hallo!
Also die Endposition, welche der Roboter zum Einlegen anfährt, ist ja eine P-Variable mit einer bestimmten Ausrichtung.
Du könntest dir mit der Einlegeposition eine Vorposition mit Z-Offset (sofern Z die Koordinate zum Anfahren ist) errechnen, die dann die selbe Ausrichtung wie die Einlegeposition hat. So fährt der Roboter immer geradlinig zur endgültigen Position. Wenn er nach einer Kollision zurück zur Vorposition fährt, dann die T Ausrichtung ändert und erneut die Vorposition berechnet, fährt der Roboter dann auch nach einer erneuten Kollision wieder gerade nach oben. So würd ich es versuchen und so habe ich schon mehrmals Vorpositionen berechnen lassen und hat immer gut funktioniert..
LG Sebastian
PS: Ich denke, das Problem hat sich erledigt da der Beitrag von Juni ist.