Beiträge von fubini

Hallo Roboman,

lange Frage, kurze Antwort: Das kann er nicht.

Was du haben willst sind bedingte Arbeitsräume, d.h. der Achsbereich für Achse zwei soll nur aktiv sein, falls sich Achse 1 in einem bestimmten Bereich befindet. SafeRobot stoppt aber den Roboter sobald auch nur eine überwachte Achse außerhalb ihres aktuell erlaubten Bewegungsbereichs aufhält.

Eventuell kannst du ja einen dritten Achsbereich nutzen, der nur dann den zugehörigen Eingang aktiviert des eingeschränkten Bereichs 1, falls sich der Roboter mit Achse 1 gerade im Bereich -104-122° befindet. Ich stell mir das in etwa so vor:

Gesamter Arbeitsbereich bleibt wie gehabt.

Dein schon vorhandener eingeschrankter Arbeitsbereich bekommt für alle Achsen außer Achse 2 +-180° und Achse 2 -142-0°.

Der zweite eingeschränkte Arbeitsbereich (muss einer der Bereiche 8-10 sein, da diese den Zustand nur über einen Ausgang melden aber den Roboter nicht stoppen) wird für Achse 1 auf 104-122° konfiguriert und für alle anderen auf +- 180°. Deine SPS kann dann (falls vorhanden) auf den Ausgang diese Bereichs horchen und falls dieser anzeigt, dass sich Achse 1 in 104-122° befindet den ersten eingeschrankten Arbeitsbereich für Achse 2 über seinen Eingang scharf schalten.

Gruß
Fubini

Hallo,

ich glaube die Einträge sind nicht umsonst in $DYNDATs verschlüsselt, da es sich dabei um KUKA Interna handelt. Daher meine Empfehlung: such dir das Datenblatt zu deinem Robotertyp, da stehen wohl die wichtigsten Abmessungen auch drin.

Gruß,
Fubini

@LindPaul:

Was du auch im Urlaub, da kann unser Brötchengeber ja dicht machen!

Gruß
Fubini

Hallo,

[Klugscheißmodus ein]
eine einfache Vektoraddition tut es alleine nicht! Das gilt nur falls die beiden Frames gleich orientiert sind: A=B=C. Die einfachste Methode das nachzustellen ist deine gegebenen Frames in ZYX-Eulerwinkeln erstmal in eine homogene (4x4)-Transformationsmatrix umzuwandeln:

Angenommen du hast zwei Frames P={X1,Y1,Z1,A1 B1,C1} und Q={X2,Y2,Z2,A2,B2,C2} beschrieben bezüglich eines festen Weltkoordinatensystems (in der Steurung ist das das aktuelle $BASE). Dann ergibt sich die zugehoerige Transformationsmatrix für P bzw. Q durch Rotation des festen Weltkoordinatensystems als Ausgangssystems erst um den Winkel AX um die Z-Achse, dann eine um den Winkel BX um die Y-Achse und zuletzt um den Winkel CX umd die X-Achse als (X=1 oder 2, ca=cos(AX), sa=sin(AX), cb = cos(BX),...):

| ca*cb ca*sb*sc - sa*cc ca*sb*cc + sa*sc | XX |
| sa*cb sa*sb*sc + ca*cc sa*sb*cc - ca*sc | YX |
| -sb cb*sc cb*cc | ZX |
| 0 0 0 | 1 |

Die beiden so erhaltenen Matrizen musst du dann einfach miteinander multiplizieren. Um dann wieder auf die Darstellung als ZYX Eulerwinkel zu kommen musst du die so erhaltene Matrix wieder rückübersetzen in {X,Y,Z,A,B,C} (A11 Matrixelment erste Zeile erste Spalte, A12 Matrixelement erste Zeile zweite Spalte, ...):

X = A14
Y = A24
Z = A34

norm := sqrt( A11*A11 + A21*A21 );

Eulersingularität bei B=90°
Falls norm > 1E-5
sa = A21/norm;
ca = A11/norm;
A = atan2(sa, ca);
sonst
sa = 0.0;
ca = 1.0;
A = 0.0;

B = atan2( -A21, ca*A11 + sa*A21 );
C = atan2( sa*A13 - ca*A23, -sa*A12 + ca*A22 );

atan2 ist dabei der Arkustangens mit zwei Argumenten, der entgegen dem normalen Arkustangens am Taschenrechner anhand der Vorzeichen der beiden Argumente auch eine Unterscheidung nach dem Quadranten in dem das Ergebnis liegen muss vornimmt.
[Klugscheißmodus aus]

Wie man sieht ist das alles nicht so einfach, mann kann aber auchmal in Wikipedia nach Eulerwinkel und Denavit-Hardenberg suchen, da ist auch Platz für längere Erklärungen warum das so ist.

Gruß
Fubini

Hallo,

der Filter wird von KUKA für jeden Robotertyp individuell festgelegt und soweit ich weis im INITMOV() vom BAS.src auf $FILTER=$DEF_FLT_PTP gesetzt. Das hat unter anderem auch mit Schwingungsvermeidung (Eigenfrequenzen des Roboters) zu tun.

Falls du etwas anderes haben willst musst du daher nur nach der INI Zeile einen Wert setzen der dir genehm ist. Also z.B. einfach $FILTER = $DEF_FLT_CP vor einem CIRC oder LIN. Du kannst natürlich auch andere beliebige Werte, die ein Vielfaches von 12 (ms Ipotakt) sind, verwenden, z.B. $FILTER=24. Wichtig ist nur, dass für alle folgenden Bewegungen dieser Wert beibehalten wird solange du nicht durch den INITMOV Aufruf $FILTER wieder überschreibst.

Gruß
Fubini

Hallo,

das ist der klassische Filtereffekt. Bei KUKA werden alle Achspositionen durch einen Mittelwertfilter geschickt. Bei kartesischen Kreisbewegungen kommt es dadurch zu einem "einschnüren" je schneller man fährt. Du kannst ja mal probieren was passiert, wenn du den Filter runtersetzt ($FILTER=xxx vor dem Bewegungssatz setzen). Normalerweise nimmt der KUKA nämlich $FILTER=DEF_FLT_PTP aus R1/$machine.dat. Dort gibt es auch einen wert DEF_FLT_CP der für kartesiche Bewegungen besser geieignet ist, weil kleiner. Du kannst sogar $FILTER=0 Null setzen, dann fährt der Roboter aber ziemlich ruppig. Also Merke: je kleiner $FILTER umso ruppiger die Fahrweise (kann sogar zum Zuschlagen von Überwachungen führen). Je größer $FILTER umso weicheres Verfahren, aber größeres "Einschnüren" von kartessichen Bewegungen.

Gruß
Fubini

Hallo,

PosMult gibt es natürlich beim KUKA auch, da ist das der :: Operator (Framemultiplikation).

Gruß
Fubini

Hallo,

erstmal muss ich mich korrigieren. INV_POS (inverses Frame) ist natürlich falsch. Es muss INVERSE heissen:

E6AXIS INVERSE (E6POS POSITION: IN, E6AXIS START_AXIS: IN, INT ERR_STATUS: OUT)

Der Funktion INVERSE wird als erste Parameter die kart. Position mit Zusatzachswinkel übergeben, worauf sie die passenden Roboter-Achswinkel berechnet und als return-Wert liefert.
Mit dem zweiten Parameter „START_AXIS“ sind die Achswinkel des Startpunktes der Bewegung zu übergeben. Dieser Parameter wird unter Umständen gar nicht ausgewertet. Er wird nur gebraucht, wenn der Status bzw. Turn von POSITION nicht definiert sind.
mit dem dritten Parameter kann übergeben werden, ob auf SW-Endschalte geprüft werden soll:
ERR_STATUS = 0: Alle Achswinkel werden geprüft, ob sie innerhalb der SW-Endschaltergrenzen liegen. Wenn nicht, dann wird über ERR_STATUS ein entsprechender Fehlercode zurückgeliefert.
ERR_STATUS <>0: Es findet keine Überprüfung der Achswinkel statt.

ERR_STATUS kannst du zusätzlich als Rückgabewert auswerten, falls die Rücktrafo nicht erfolgreich ist steht da ein Code drin wass schief gegangen ist:

-1: Nicht alle wesentlichen Komponenten der Variablen POSITION (X, Y, Z, A, B, C, ggf. E1, E2..) sind definiert. (S und T müssen nicht unbedingt definiert sein.)
oder:
wenn der STATUS von POSITION ungültig ist, waren nicht alle Komponenten von START_AXIS gültig.
-2: ERR_STATUS besitzt noch keinen gültigen Wert.
-3: $BASE (Vorlaufvariable) ungültig.
-4: $TOOL (Vorlaufvariable) ungültig.

Gruß
Fubini

Hallo,

die einfachste Möglichkeit hierzu ist ein Aufruf der Funktion INV_POS(...). Die ruft intern einfach die inverse Kinematik auf und errechnet die Achswinkel einer gegebenen kartesichen Position. Die genaue Syntax kann ich gerade - bin nicht im Büro - nicht nachschlagen, ich glaube aber man gibt dem Aufruf zwei E6POS mit. Der erste Punkt ist der Startpunkt der Bewegung. Der zweite Punkt sollte dann der Zielpunkt sein, da dann der STATUS und TURN automatisch richtig angepasst werden. Ich glaub als Dritten Parameter gibt es dann noch einen INT Wert, der Fehlerinformationen zurückliefert.

Gruß
Fubini

Hallo,

ich kenn mich zwar beim auch ABB nicht aus, aber bei KUKA ist die Reihenfolge der Drehungen in ZYX-Eulerwinkeln anzugeben, d.h. zuerst die Drehung um Z(=A Winkel), dann die um Y (=B-Winkel) und zuletzt die um X(=C-Winkel).

Kontrolliert vielleicht in eurem Programm ob diese Reihenfolge auch eingehalten ist.

Gruß
Fubini

Hallo,

warum macht ihr das so kompliziert? Ein einfaches LIN_REL {A 180} sollte auch funktionieren.

Gruß
Fubini

Hallo,

mit einem EX_BASE hab ich es selbst noch nie probiert. Ohne externe Zusatzachsen funktioniert es einfach mit $BASE=BASE_DATA[1] aus der config.dat. Ich nehme aber an das die EX_BASE Einträge analog funktionieren. Hab leider gerade keinen Zugang zu einer Steuerung damit ich nachschauen könnte.

Gruß,
Fubini

Hallo,

du musst nur das entsprechende Base aktivieren. Im Programm kannst das durch eine Zuweisung an $BASE erreichen, beim Handverfahren durch das Menü im Unterpunkt aktuelles Werkzeug/Base.

Gruß
Fubini

Hallo,

zu Punkt 2:
Prinizipiell ist das natürlich möglich. Allerdings stellt die Robotersteuerung das nicht als Funktionlität zur Verfügung, d.h. du musst die kartesiche Position der für dich relevanten Punkte am Roboter in Abhängigkeit von den aktuellen Achswinkeln selbst berechnen. Erfordert allerdings etwas Mathematik (Matrizenrechnung). Stichworte hierzu sind Denavit-Hardenberg-Transformation und Vorwärtskinematik (z.B. in Wikipedia). Allerdings brauchst du - sollte die Mathematik umgesetzt sein - noch einige Zusatzdaten aus den Maschinendaten (z.B. wie lang genau ist der Roboterarm und andere relevante Verbindungen zwischen den Robotergelenken). Ob KUKA diese selbst herausgibt oder du ein Massband ansetzen musst musst du dich mal bei KUKA erkundigen.

Gruß,
Fubini

Hallo,

hab gestern ganz vergessen, dass es noch ein zweite Möglichkeit zur Arbeitsraumüberwachung gibt. Ich glaube in R1/$machine.dat gibt es $AX_WORKSPACE oder so ähnlich. Damit kann man mehrere Achsarbeitsräume definieren und auch festlegen, was bei einer Verletzung passieren soll (stoppen oder Ausgang setzen). Das gleiche gibt es auch für kartesische Arbeitsräume definiert als Quader ($WORKSPACE[] ?). Hier liegen die Systemvariablen aber soweit ich weis in der $config.dat.

Gruß
Fubini

Hallo,

natürlich ist das möglich. Du brauchst nur in R1/$machine.dat die Softwareendschalter $SOFTN_END bzw. $SOFTP_END anzupassen. Die Frage ist nur was ihr unter sicherheitstechnisch versteht. Falls bei euch im Bezug auf Arbeitssicherheit höhere Anforderungen notwendig sind, dann könntet ihr euch eventuell mal die Option SafeRobot anschauen. Da könnt ihr situationsabhängig verschiedene Bewegungsbereiche für den Roboter sicher überwachen. Der Trick dabei ist im wesentlichen, dass bei SafeRobot alles redundant ausgelegt ist. Das erfüllt dann höhere Sicherheitsstandards als beim normalen Roboter.

Gruß
Fubini

Hallo,

SafeRobot 2.0 hat eine ganze Latte neuer Funktionen. Ich zähle mal die meines Erachtens wichtigsten auf:

1) 7 Arbeitsräume die jetzt auch kartesisch als Quader definiert werden können. SR1.1: 10 nur achsspezifische Arbeitsräume

2) Einen Zellenbereich als globalen Arbeitsraum, der über einen konvexen geschlossenen Polygonzug mit bis zu 6 Stützstellen definiert wird.

3) Für jeden der insgesamt 8 Arbeitsräume kann zusätzlich eine Geschwindigkeit eingestellt werden, die dann entweder innerhalb oder außerhalb des erlaubten Bewegzungsbereichs des Roboters sicher überwacht wird.

4) Sicheres Überwachen von bis zu 3 Werkzeugen gegen verlassen von erlaubten achspezifischen bzw. kartesischen Arbeitsräumen. Jedes dieser Werkzeuge ist definiert über 2 konfigurierbare Kugeln. Zusätzlich kann für jedes Werkzeug ein TCP festgelegt werden, an dem kartesische Geschwindigkeiten sicher überwacht werden. Werkzeugwechsel ist online über sichere Eingänge möglich.

5) Für jeden Raum ist definierbar wie auf eine Verletzung des erlaubten Bewegungsbereichs durch das Werkzeug reagiert werden soll (Roboter stillsetzen, nur über einen Ausgang melden). Ferner kann für jeden Bereich (ausser dem Zellenbereich) festgelegt werden über welchen sicheren Eingang er aktiviert werden kann oder ob er immer aktiv ist oder immer deaktiviert sein soll.

6) Über eine nicht sichere automatische Overrideregelung können kartesiche Geschwindigkeiten vom System atomatisch eingehalten werden. D.h. der Roboter regelt seine kartesische Geschwindigkeit automatisch auf die aktuell niedrigste sicher zu überwachende Geschwindigkeit.

Gruß
Fubini

Die Orientierungsänderung bezieht sich immer auf die Stossrichtung, d.h. beim KUKA die x-Achse eures $TOOL Systems. Drehgeschwindigkeit ist dann dass drehen um diese Achse und Schwenkgeschwindigkeit eben das schwenken.

Fubini

Hallo,

ich bin in der VRS zwar nicht so fit, wenn es aber wie sonst immer bei KUKA ist, dann ist x+ nach unten, d.h. in HOME zeigt im Flanschsystem x auf den Boden, z steht senkrecht auf dem Flansch und y zeigt nach rechts (falls du vor dem Roboter stehst). Sofern du bei der Tooldefinition keine Orientierung angegeben hast stimmt dass dann auch bei deinem Tool.

Gruß
Fubini

Hallo,

hlq.c steht für Hauptlaufque. Der Ablauf ist folgendermaßen:
1) Planung einer Bewegung
2) Die fertig geplante Bewegung wird in die Que gesteckt.
3) Nehmen der geplanten Bewegung aus der Hauplaufque und interpolieren, d.h. Abfahren der Bewegung.

Beim Herausnehmen aus der Que scheint es einen Fehler zu geben.

Wenn der Fehler Auftritt solltet ihr mal in den LOG-Ordner schauen dort sollte ein tt<Datum>.log angelegt werden. Ferner gibt es dort auch ein tsm<*>.Log und ein System<*>.log. die braucht KUKA zur Analyse solch eines Fehlers. Am besten ihr erstellt ein Archiv und schickt es an KUKA.

Gruß
Fubini