Möglicherweise mechanisches Problem an Achse 4?

Welche Achsstellung hat in diesem Moment die Achse 5?

Nun, also nahe 0 Grad...

Ich vermute mal, Du rennst in eine der Fallen, die immermal wieder auftreten.
Das nennt sich Singularität. Der Roboter kann das einfach nicht. Sieh zu, daß Deine 5. Achse immer mindestens 5 Grad von 0 wegbleibt oder fahre PTP

Nun, wenn die Vierte ihre Höchstgeschwindigkeit erreicht, jault sie schonmal.
Das ist beim Auto auch so, daß es laut wird, wenn mann vollgas gibt...
...und da gibt es eben auch Tempolimits: Schneller gehts einfach net. Wenn nun Deine Bewegung schnellere Drehungen verlangt, steigt die Achse einfach aus. Der Robot bleibt mit Fehler Sollgeschwindigkeit stehen.

Das kannst Du nur umgehen, wenn Du Deine Bewegung umteachst.
Du machst Lichtbogenschweißen? Dann dreh doch einfach um die Drahtachse. Schon sollte ein Winkel an der 5. realisiert sein.
Dem Brenner ist's egal wierum er fährt, Hauptsache, die Winkel zum Blech stimmen.

Das Problem ist wie schon erwähnt (und nach Deiner Beschreibung und meiner Meinung nach) ein Singularitätsproblem. Das ist nicht anders zu lösen. Siehe Handbuch. Könntest höchstens den Winkel, in dem das Werkzeug angebaut ist ändern. Dann musst Du die Bewegungen aber alle auch ändern, jedoch zumindest das Tool ändern und alle Bewegungen überprüfen.

Daß Deine Simulation klappt, besagt gar nichts. Simulation ist nicht das richtige Leben.
Willkommen in der realen Welt... (und hier erkennt man wieder was ich von Simulationen halte)

Nichts für Ungut, aber so ist es eben.

....das sieht mir nach nem fatalen Alpha 5 Problem aus

die Variable $SINGUL_POS[3] in der R1\Mada\$machine.dat würde ich mal versuchsweise auf 1 setzen und dann würd ich mal noch mit der Variablen $SINGUL_STRATEGY in der Steu\Mada\$option.dat spielen, d.h. Versuchsweise auf 1 setzen

Versuch macht Kluch

Dann berechne Deine Bahnen so, daß es vernünftig ist. Auch das geht normalerweise problemlos. Wenn die A5 nahe 0 kommt mußt Du halt die Orientierung ändern.

Und "schön gerade" gibts net. Ein Robbi findet ne gerade 5. eben net schön. Er ist halt auch nur n Mensch...

joooo, das kommt hin. So soll ein Roboter klingen...
...außer in der Autoindustrie. Da sollte das alles nur eine Oktave höher sein.

Hallo,

das Du in OfficeLite durch die Singularitaet durchfahren kannst, und mit dem echten Roboter nicht, kann vom Softwarestand abhaengen.
Auf jeden Fall hab ich einem Mitarbeiter vor nicht allzulanger Zeit demonstrieren wollen, was eine Singularitaet ist und was die fuer Konsequenzen hat. Ich bin einfach linear Alpha5 = O durchgefahren. Und musste mit entsetzen feststellen, das der Roboter nur die Geschwindigkeit reduziert und gewaltig von der Bahn abweicht (ich bin davon ausgegangen, das Achse 4 oder 6 mit Sollbeschleunigung oder Sollgeschwindigkeit aussteigt - was auch frueher so war).

Mathematisch ist das eben nur mit Mogeln moeglich.
Soviel zum Thema Singularitaetsstrategie - ich denke fuer deine Anwendung waere das Verhalten sogar toedlich.

Gruss Stefan

Hallo

Der Override bestimmt ja die Verfahrgeschwindigkeit des TCPs. Wenn aber die einzelnen Achsen, hier die A4, sich aber so schnell drehen müssen, das diese Geschwindigkeit des TCPs erreicht werden muss, dann steigen die natürlich aus. Also, Override ist nicht auf einzelne Achsen bezogen !!!!!

Hallo Eagle,

es ist keine Einbildung von deiner Seite.
Auch kein mechanisches Problem deines Roboters.
Ich habe bereits zwei KR30L16 in Betrieb und beide haben (hatten)
dieses Problem. Am ersten haben wir sogar den Getriebestrang
der Achse A4 gewechselt. Da dieser aber als reiner Handlingsroboter
läuft konnte unser Kunde "damit leben".
Jemand aus der Maschinendatenabteilung von KUKA schaute
sich unseren Roboter an und fixte das Problem.

Das Problem kommt aus meiner Sicht, und ich hab mich genug damit
rum geärgert, daher dass wenn du im T2 den Roboter anhälst er mit
einem "kleinen Sprung" wieder auf die Position will auf der du den
Stop verursacht hast. Sprich die Verzögerungsbewegung wieder
zurückfahren will, aber halt mit hoher Beschleunigung. Dies schafft er
nicht und löst somit einen Fehler aus.

Nun läuft er wie alle seine Kameraden. Verdammt gute Maschinen
diese KUKAs...

Hi...
Selbe Problem war bei uns mit KR30L16.
Erst neue Maschinendaten half, das Problem zu beseitigen.
Bis dato war das fahren nicht so richtig in Produktion möglich.
Deshalb hatten wir solange die $Geartorq_Mon auf false gesetzt.

nur mal kurz zur allgemeinen Veranschaulichung von wegen POV, Achsgeschwindigkeit und Singularität soweit ich das verstehe:

Wenn also z.B. 10% POV aktiviert ist, dann heisst das: Der TCP bewegt sich 0.2 m/s, sofern die Bewegung bei voller Geschwindigkeit gemacht werden soll.
Nehmen wir mal an der Roboterinterpreter berechnet die Bahnpunkte mit 1mm Distanz, dann hat der Roboter also 5 millisekunden Zeit um von Punkt zu Punkt zu fahren.
Wenn du nun in eine Singularität kommst und die Achse 4 beim Punkt P(x) auf 0° steht, durch die unendliche Anzahl Lösungen der Interpreter beim Punkt P(x+1) aber 180° für die Achse 4 berechnet, bedeutet das, dass die Achse 4 180° in 0.005 sec machen muss. Das wären dann 100 Umdrehungen pro Sekunde (!) für Achse 4 um die geforderten 0.2 m/s am TCP sicher zu stellen.
Da aber die Achse 4 beim Punkt P(x) eigentlich stillsteht, erhöht sich die zu erreichende Geschwindigkeit auf 200 Umdrehungen pro Sekunde bei einer Beschleunigung von 400 Umdrehungen / s^2 (!!) Das aber nur, wenn die Achse in P(x+2) auch noch auf 180° stehen muss. Dabei ist die Trägheit aber noch nicht miteingerechnet.
Einer groben Schätzrechnung nach wären das ca. 450 km/h für die Achse 4.
Ich bin mir aber nicht ganz sicher ob die Mechanik solcher Dynamik gewachsen ist?

So das habe ich jetzt einfach mal so geschrieben. Ich weiss nicht ob ich richtig gerechnet habe und ich weiss dass einige Annahmen nicht 100% korrekt sind. Doch denke ich sieht man so ein wenig woher das Sollgeschwindigkeitsproblem bei Singularitäten kommt.