Hallo,
ich habe auch häufiger einen Spannungsverlust.. Immen beim Verriegeln des Sicherheitskäfigs..
Ist AEG wirklich die einzige Lösung???
Gruß
Hallo,
ich habe auch häufiger einen Spannungsverlust.. Immen beim Verriegeln des Sicherheitskäfigs..
Ist AEG wirklich die einzige Lösung???
Gruß
danke für die Antworten! Habe jetzt eine Lösung (danke Loipe!) implementiert, die - denke ich - MRL-konform ist. Habe es nochmal von einem Sicherheitstypen bei uns überprüfen lassen.
Grob gesagt habe ich vier Ausgänge mit vier Eingängen verdrahtet und entsprechend mit den vier Kuka-Variablen (Drives_on, drives_off, conf_mess, ext_start) konfiguriert. Über einen extra Taster wird die Tür verriegelt. In der sps.sub werden entsprechend Signallaufdiagramm aus der Doku die Ausgänge gesetzt.
...die MRL erlaubt nach meinem Kentnisstand nicht, dass ein Quittier-Taster (sei dies nun eine Quittierung für eine Tür, eine Lichtschranke, oder eine Störungsquittierung) gleichzeitig auch einen Prozess startet. Quittier- und Start-Taste müssen funktional getrennt sein.
das würde mich allerdings auch interessieren
Es ist eine KR C2 sr Steuerung
ja genau es gibt keine externe SPS.
Ich sehe da kein Sicherheitsrisiko, da der Roboter erst loslegen soll, sobald die Tür wirklich verriegelt wurde (per digitalem Ausgang). Und dann kann ja nichts passieren
danke für deine Antwort! Wie konfiguriert man denn automatik extern?
Mein Plan war eigentlich keine übergeordnete SPS-Steuerung zu benutzen, sondern sps.sub.
Dort wollte ich die drei Variablen DRIVE_ON, CONF_MESS und EXT_START abprüfen und dann mein entsprechendes Programm aufrufen.
Was genau mein Problem ist:
Während des Automatik-Betriebes wird die Tür vom Sicherheitskäfig entriegelt. Der Benutzer tauscht irgendwelche Werkstücke aus und schließt anschließend wieder die Tür und drückt dann einen Taster, der die Tür verriegelt. Jetzt müsste der Benutzer am KCP die Meldung "Bedien-/Schutzgitter offen" quittieren und die "Ein"-Taste betätigen, bevor es weitergehen kann. Das möchte ich vermeiden.
Hallo,
mein Ziel ist ein automatischer Wiederanlauf der Roboters. Ich habe herausgefunden, dass man das über den Modus Automatik Extern realisieren kann. Doch sobald ich in den Modus wechsle, erhalte ich die Fehlermeldung: "MOVE_ENABLE Eingang (1025) nicht erlaubt". Hat jemand eine Idee, was der Fehler sein könnte?
Viele Grüße,
Johanna
alles klar danke. Ich werds mal ausprobieren.
Aber wüsste gerne, ob die andere Möglichkeit mit den Differenzen bilden auch geht.
Sorry, ich verstehe überhaupt nicht, was du meinst. Ich denke du meinst mit feststehendes Werkzeug das feststehende Objekt?!
Warum soll ich mir variablen -> einzeln -> tool_data anzeigen lassen, wenn ich damit nichts berechne? Meinst du vielleicht die aktuelle Istposition bei gewähltem $Tool = 0 anzeigen lassen?
Reicht es nicht doch einfach, wenn ich auch noch die Differenz der beiden C-Werte nehme?! Das müsste doch genau die Verdrehung zum UrsprungsTCP sein.
Ich bin mir doch noch unsicher bei einem Aspekt:
Die gemerkte Position des feststehenden Punktes ist auch wenn ich um C drehe die gleiche.
Aber wenn ich jetzt mit dem stark verbogenen Werkzeug zu dem feststehenden Punkt fahre, kommt es darauf an welchen Winkel ich bei dem C ausgewählt habe, denn das C dreht ja um den ausgewählten TCP. Das ist in dem Fall $TOOL = 0. Also um die Spindel.
Man kann sich das ganze als Kreis vorstellen: Der Mittelpunkt ist der feststehende Punkt, auf den die Spitze des zu vermessenen Werkzeuges zeigt. Die Kontur des Kreises entspricht der Position des Ursprungs-TCPs, dessen Position ich angezeigt haben möchte.
Es gibt also 360 verschiedene Positionsmöglichkeiten.. und damit bekomme ich wenn ich die Differenz zum feststehenden Punkt bekommen will, nicht die Maße des Werkzeuges raus.
Ich bekomme höchstens die direkte Distanz zwischen Werkzeugspitze und UrsprungsTCP raus. Aber nicht den X-, Y- und Z-Wert, den ich bei numerische Eingabe eingeben müsste. Der hängt ja von dem C ab..
Hatte meine letzten Post korrigiert. Wenn das stimmt was da steht, hab ichs denke ich verstanden =)) Danke
Wichtig ist halt dass ich den feststehenden Punkt in der Welt kenne ($BASE= $TOOL=$NULLFRAME).
hm die Orientierung ist eigentlich egal oder?
Was mir einfach wichtig ist, dass ich das Tool später um die Achse C drehen kann und es bleibt genau am gleichen Punkt, ohne dass es eiert. Deswgen auch das Nachkorrigieren, damit das immer gewährleistet ist.
ZitatWenn man die Koordinaten des feststehenden Punktes in World-Koordinaten abspeichert,
Meinst du, dass man mit dem Referenzwerkzeug zum feststehenden Punkt fährt und dann $BASE= $TOOL=$NULLFRAME auswählt und sich die aktuelle Position anzeigen lässt. Da sich das Referenzwerkzeug nur um eine Translation in Z-Richtung vom Ursprungs-TCP (Ende der Spindel) unterscheidet, muss diese noch abgezogen werden. Diese Werte merkt man sich dann.
Dann fährt man mit dem neuen Werkzeug zum Punkt und lässt sich ebenfalls die Istposition anzeigen mit $BASE= $TOOL=$NULLFRAME und erhält die Maße des Werkzeuges?
Alles anzeigen
Der Ansatz mit dem ortsfesten Werkzeug ist wohl schon mal in die richtige Richtung gedacht.
Allerdings geht es dann nicht mehr mit dem Standard-Vermessungsverfahren weiter.
Ich würde mir da ein Programm schreiben, das so was ähnliches leistet:
Ein Teachpunkt mit dem korrekt vermessenen TCP auf einer ortsfesten Spitze. Der muss konstant bleiben, dazu den dort gültigen TCP in einer separaten Variablen merken.
Für das Vermessen einen zweiten Punkt anlegen und teachen, dann aus den gemerkten Werten, und dem neuen Teachpunkt die Differenzen auf den TCP aufschlagen, dann sollte der TCP wieder stimmen.
Es gab da mal so ein Beispielprogramm auf den alten Robotern Cor_T1, oder so ähnlich.
Ich bin mir nicht ganz sicher, ob ich dich richtig verstanden habe:
Ich vermesse einmal am Anfang mein zu vermessenes Werkzeug mit der xyz-Referenzmethode.
Wenn es vermessen wurde zeige ich mir die Istposition mit ausgewähltem vermessenen Tool an und merke sie mir (I1).
Dann verbiegt sich irgendwann das Werkzeug und um zu korrigieren fahre ich wieder an den feststehenden Referenzpunkt und zeige mir wieder die aktuelle Istposition (I2).
Jetzt bilde ich die Differenzen:
I1.x-I2.x
I1.y-I2.y
I1.z-I2.z
Die Differenz rechne ich dann mit "Werkzeug - Vermessen - Numerische Eingabe" auf die Tooldaten drauf.
Was ist denn mit der Orientierung C?
Hey,
ich würde gerne ein Werkzeug an meinem Scara-Roboter vermessen. Das mache ich momentan nach der XYZ-Referenzmethode. Das heißt am Ursprungs-TCP (unteres Ende der Spindel) ist ein Referenzwerkzeug montiert, von dem die Abmaße bekannt sind. Mit diesem fahre ich auf ein Referenzobjekt und anschließend montiere ich es wieder ab und montiere das zu vermessene Werkzeug an den Flansch. Mit dem zu vermessenen Werkzeug fahre ich dann auch zu dem Referenzobjekt.
Diese Methode scheint zu funktionieren, obwohl in der Kuka Doku steht, dass die XYZ- und ABC-Methoden für einen Palettierroboter mit vier Achsen nicht verwendet werden können.
Jetzt kann es aber sein, dass sich das neu vermessene Werkzeug im Laufe der Zeit ein bisschen "verbiegt". Daher möchte ich regelmäßig nachkorrigieren. Doch dann wäre es zu aufwändig immer das vermessene Werkzeug abzubauen, ein Referenzwerkezug anzubringen usw.
Gibt es da auch eine andere Möglichkeit, sodass ich ohne das Referenzwerkzeug an der Spindel auskomme?
Ich hatte schon mal überlegt ein feststehenden Werkzeug zu vermessen und dann dieses als Referenzwerkzeug und Referenzobjekt in einem bei der XYZ-Methode zu verwenden. Aber das scheint auch nicht zu klappen, da dieses als Basis-System geteached wird.
Gibt es noch andere Möglichkeiten?
Viele Grüße
Es ist klar warum.
ja funktioniert jetzt =)
hä?!
Die Werte der Ist-Position kommen doch dadurch zustande, dass eben mittendrin der Arbeitsraumfehler kommt. Die Bewegung ist ja eigentlich noch nicht abgeschlossen
super danke! Dann kann ich mir wirklich nur erklären, dass sich die Basis ein wenig verschoben hat
Ist denn dieses R 245 genau der gesuchte Wert von mir? Also der Radius von dem Kreis um den Roboterfuß?
siehe oben
wusste nicht, dass es ein Feld ist
$CYLWORKSPACE[1] klappt dann natürlich
mittlerweile habe ich die Datei doch gefunden.. sie ist im Ordner "Mada"
es gibt insgesamt 8 mal Einträge für $CYLWORKSPACE, welcher davon ist denn relevant?
der 1. sieht zum Beispiel so aus:
$CYLWORKSPACE[1]={X -39.0, Y 0.0, Z 0.0, A 0.0, B 0.0, C 0.0, Z1 0.0, Z2 340.0, R 245.0, MODE #INSIDE_STOP, REFERENCE #WORLD}
Ist der Wert 245.0 der relevante? Weil das würde ja dann hinkommen....