Beiträge von fubini

Hallo John,

Ist es vielleicht 3072?

Unsere Vermutung für den Fehler ist dann, dass es mit einem schon bekannten Problem der Denso-Antriebstechnik zu tun hat. Beim Hochlauf der Steuerung schickt diese fälschlicherweise gültige Positionen an die KUKA-Seite obwohl die Antriebe noch nicht richtig initialisiert sind. Quasi ist dann die Position der Achsen beim Hochlauf kurzzeitig irgendwo. Zufälligerweise könnte es jetzt sein, dass diese Lage des Roboters einen Arbeitsraum verletzt. Sind daher bei euch auch wirklich alle Arbeitsräume ($AXWORKSPACE[], $CYLWORKSPACE[] und $WORKSPACE[]) deaktiviert?

Die zylindrischen Arbeitsräume $CYLWORKSPACE sind dabei neu für die Denso-Kinematik ins System gekommen und in den Maschinendaten zum Teil immer aktiv. Das liegt daran, dass die Kinematik sonst aufgrund ihrer Bauweise mit dem eigenen Sockel kollidieren könnte. Bei KUKA Kinematiken ist das so nicht notwendig, da dort bereits über die Lage der Endanschläge der Achsen eine solche Kollision ausgeschlossen werden kann.

In einem neueren Softwarestand hat Denso dieses Problem inzwischen behoben.

Gruß
Fubini

Hallo John,

wie lautet die genaue Meldungsnummer? Ist es eine größer 31000, dann ist das die Arbeitsraumüberwachung der Densoseite ansonsten die von KUKA. Für eine genauere Analyse wäre das noch wichtig.

Danke,
Fubini

Hallo Jens,

das steht in der R1/$machine.dat unter $ACC_MA. Normalerweise stehen da im Defaultfall für alle Robotertypen 10 m/s^2 lineare Beschleunigung und je 1000 Grad/s^2 für drehen und schwenken bei der Orientierungsführung.

Gruß
Fubini

Hallo Bert,

die Kurzschlussanforderung RDW steht z.B. immer dann an wenn die SafeRDW einen Stopp 0 auslöst, d.h. genauer den Ausgang QE auf der SafeRDW setzt. Beim Hochlauf ist das solange der Fall bis die Sicherheitskonfiguration erfolgreich verifiziert ist. Nachdem ihr die Konfiguration noch nicht gemacht habt kann das also gut sein, dass diese noch ungültig ist. Das müsste man aber an einer zusätzlichen Meldung (Text hab ich leider gerade nicht parat, irgendetwas mit Ungültige konfiguration) erkennen. Auch kann es sein, dass ihr noch keine Justagereferenzierung gemacht habt und in einer Betriebsart ungleich T1 seid, dann gibt es auch einen Stopp Null.

Das maximale Getriebmoment hat nichts speziell mit der SafeRDW zu tun bzw. wird von dieser nicht überwacht. Insofern (mal einen Hardwarefehler des Boards ausgeschlossen) ist hier das Verhalten identisch mit einer RDW2.

Gruß
Fubini

Hallo Eagle,

zunächst Arbeitsraumfehler hat nichts mit Arbeitsraumüberwachung zu tun, sondern nur ob der Roboter diese Position anfahren kann oder nicht. Wie genau fährst du den Punkt an?

Eventuell hast du deine Position im BASE mit einem falschen Status geteacht so dass der Robbi die Position nicht erreichen kann. Nachdem der Status bei CP-Bewegungen immer beibehalten wird ist dieser durch den letzten davor liegenden PTP-Punkt bereits festgelegt.

Eventuell muss der Roboter auch nur auf dem Weg zu deinem BASE irgendwo durch wo er physikalisch nicht hin kann. Die Meldung kommt nicht nur wegen dem Endpunkt der Bewegung, sondern - zumindest beim CP-Fahren - auch für Punkte auf der Bewegungsbahn.

Gruß
Fubini

Hallo,

eine einfache Formel oder Tabelle für diese Problem wird es wohl kaum geben, da der Sicherheitsabstand wohl kaum nur von den (Achs-)-Geschwindigkeiten abhängt, sondern sicher noch von den Lastdaten und Abmessungen deines Werkzeugs sowie der Dynamik des Roboters.

Siehe auch die Diskussion bei

http://www.roboterforum.de/rob….0.html;msg17530#msg17530

Dort findest du ein paar Normen, die sich mit so etwas befassen. Allerdings kommst du da immer auf sehr große Abstände.

Gruß
Fubini

Hallo,

so ungefähr heisst z.B. dass es nie eine Parabel wird, sondern immer ein Kreisbogen bleibt, wobei der Radius des Kreises immer größer wird je näher der Hilfspunkt an die Verbindungsgerade von Start- und Zielpunkt heranrückt.

Gruß
Fubini

Hallo HarryH,

ich seh gerade, dass du einen 4-Achspalletierer hast. Kontrollier mal in der SafeRobot Konfiguration bei der Justagereferenzposition den Winkel der Achse 5. Der muss für simulierte Achsen, was beim Palletierer für Achse 4 und 5 der Fall ist, immer der Wert Null drinstehen. Falls dem nicht so ist editier ihn mal auf Null um und schau ob es dann klappt. Eventuell schreibt da der TouchUp der Konfigurationsoberfläche pi/2 - Achse 2 Winkel - Achse 3 Winkel rein, was ein Fehler von KUKA ist.

Gruß
Fubini

Hallo HarryH,

$MASTERINGTEST_INPRO ist keine der Variablen denen in STEU/$machine.dat ein Ausgang zugewiesen werden muss, sondern sie wird nur intern verwendet. Dabei ist der Ablauf in etwas so, dass die Applikation MasRefReq, die SafeRDW in den Justagereferenzierungsmodus bringt. Die Rückmeldung der SafeRDW, dass sie dieses Kommando verstanden hat wird über $MASTERINGTEST_INPRO = TRUE an die Applikation gemeldet.

Grund dafür, dass $MASTERINGTEST_INPRO nie gesetzt wird können u.a. Kommunikationsprobleme zwischen Grundsysytem <-> DSE <-> SafeRDW sein. Schau dir in der Variablenansicht mal den Wert von $MASTERINGTEST_WORK an, der sollte true werden, sobald die Applikation das Kommando für die Justagereferenzierung an die SafeRDW losschickt. Wird er true und es klappt trotzdem nicht würde ich, falls noch nicht geschehen einen Kaltstart empfehlen, da eventuell die SafeRDW nicht richtig hochgefahren wurde (Blinklichter auf der Platine gemäß Anleitung mal kontrollieren). Falls das nichts bringt mal Inbetriebnahme -> Service -> DSE-RDW nachschauen ob da Kommunikationsfehler auftauchen.

Gruß
Fubini

Hallo snoop,

das kannst du bequem über Anzeige -> Variable -> Übersicht -> Konfiguration oder ConfigMon.ini bearbeiten einstellen. In der ConfigMon.ini findest du in etwa so einen Eintrag:

[Group1] ; 1. Reiter
GroupTitle=Example1 ; Titel des Reiters
Editable=Expert ; wer darf editieren (Benutzergruppe)
Visible=Operator ; wer darf anschauen (Benutzergruppe)
ColWidthState=35
ColWidthName=100
ColWidthVariable=100
ColWidthValue=51
ConfigWindowWidth=310
ShowWindowWidth=306
Item1=NMOV;Bewegungen;0;3;20 ; Item1=<Variablenname>; <AnzeigeName>; <Aktualisierung 1=an 0 = aus>;...
Item2=JERKVIOL;Max. Ruckverletzung;1;3;30
Item3=GETMOM;Max. Getriebemomentenverletzung;1;3;30
Item4=MOTMOM;Max. Motormomentenverletzung;1;3;30

den du entweder selber editierst. Alternativ kanns du das aber auch alles über die Oberfläche unter Konfiguration einstellen. Du musst aber soweit ich weis als Experte angemeldet sein um etwas einstellen zu können.

Gruß
Fubini

Hallo Schui,

wegen des nicht-bahntruen Notaus:
Kontrollier mal in R1/$machine.dat den Wert $EMSTOP_PATH. Da ist in Abhängigkeit von der Betriebsart konfiguriert ob der Notaus Bahntreu oder nicht bahntreu (d.h. Drehzahlstopp) ausgeführt werden soll.

Ansonsten kann es auch bei einem bahntreuen Notaus vorkommen, dass während des Stopps auf Drehzahlstopp umgeschalten werden muss, da die Notausrampe zu starke Verzögerungen hervorruft, die Momentengrenzen des Roboters verletzen. Eventuell kannst du dazu in R1/$robcor.dat mal auf $EMSTOP_ADAP schauen. Steht da true drin ist die Notausrampe modellbasiert und in eurer Anwendung könnten dann die Lastdaten nicht korrekt programmiert sein.

Gruß
Fubini

Hallo Sven,

das geht so natürlich nur bei bei LIN_REL.

Bei PTP macht das doch auch gar keinen Sinn, da du ja bei PTP vorgibst wie die Achsen verfahren (Gerade im Achsraum) und nicht wie der TCP kartesisch verfährt. Daher verstehe ich die Aussage er fährt in $TOOL bei deiner Bewegung nicht. Es wird doch erst die Startposition in Achswinkel umgerechnet und dann in die Achswinkel der Zielposition angefahren.

Die einzige Rolle die bei PTP TOOL und BASE spielen ist doch, dass die eventuell kartesisch und im .dat-File als Position im Toolsystem bzgl. Base abgespeicherten Positionen in Achswinkel übersetzt werden. Hierzu braucht man TOOL und BASE um einerseits auf den Flansch und andereiseits auf den Roboterfuss zurückrechnen zu können, da man nur aus Flansch bezüglich Roboterfuss dann auf die Achswinkel kommt.

Gruß
Fubini

Hallo

default ist, dass die Relativbewegung in $BASE gefahren wird. Durch Anhängen von #TOOL an die Befehlszeile, d.h.

LIN_REL {X 300.0} #TOOL

wird im aktuellen $TOOL-System gefahren.

Gruß
Fubini

Hallo roboprog,

die Signale geben nur an ob die Tests schon erforderlich sind. Nach setzen dieser Anforderung hast du aber (siehe Doku SafeRobot) noch zwei Stunden Zeit (in denen der Roboter noch nicht gestoppt wird!!) diese durchzuführen.

Gruß
Fubini

Hallo roboprog,

das sind Signale die, falls Bremsentest bzw. Justagereferenzierung notwendig sind auf true gehen.

IF $MASTERINGTEST_REQ_INT == TRUE then

testfahrt()

endif

Gruß
Fubini

Hallo roboprog,

alternativ kannst du auch die Variablen $MASTERINGTEST_REQ_INT bzw. $BRAKETEST_REQ_INT auswerten.

Gruß
Fubini

Hallo Martin,

deine Formel gilt nicht bei einem generatorischen Stopp sondern bei einem Drehzahlstopp. Im Falle eines sicherheitsgerichteten Stopps 0 steht aber die DSE als nicht sichere Bauteilgruppe nicht zur Verfügung.

Gruß
Fubini

Hallo,

kannst du die Formel bitte hier posten, da hätte ich auch Interesse dran.

Gruß
Fubini

Hallo Eagle,

ob das Verhalten nun schön ist oder nicht, es lässt sich bei der Darstellung von Orientierungen über Eulerwinkel leider nicht vermeiden. Konkret passiert das bei der KUKA-Konvention von ZYX-Eulerwinkeln immer für den Wert B ungefähr 90°. Dort fallen dann rein mathematisch Z und X-Achse aufeinander und nur noch die Summe von A und C ist eindeutig definiert. Du kannst ja mal in Wikipedia nach Eulerwinkel, Eulersingularität oder Gimbal Lock suchen.

Einzige Abhilfe wären hier wie Herrmann schon sagt Quaternionen oder 3x3-Rotationsmatrizen zu verwenden. Quaternionen sind aber in ihrer Darstellung deutlich schwieriger handzuhaben und Rotationsmatrizen, die KUKA übrigens intern zur Darstellung der Orientierung verwendet, durch die notwendige Angabe von 9 Werte unpraktikabel.

Fazit: Die auch für nicht-Cracks einfach interpretierbare Darstellung über ZYX-Eulerwinkel funktioniert gut splange man von B=90° weg bleibt.

Gruß
Fubini

Hallo Jumbo,

bei CP-Bewegungen LIN/CIRC $VEL.CP = ... (m/s) bei PTP-Bewegunen $VEL_AXIS[AxisNo] = ... (0-100%).

Gruß
Fubini