Beiträge von R.Bartels

Hallo Kollegen,

Wir haben hier an einigen Stellen die Suchlauffunktion mit SKIP CONDITION im Einsatz.

Da es am Ende ja immer um Taktzeit geht, moechten wir den gelben Kollegen etwas auf die Spruenge helfen.

Dafuer verwenden wir beim Suchlauf bis zu einer bestimmten Stelle eine hoehere Geschwindigkeit und
schalten dann auf ca. 10% der ersten Geschwindigkeit um.

Unser Problem an der Stelle ist, dass der Roboter nach Erreichen des ersten Schaltpunktes ueber 300mm nachlaeuft.

Den Sensor welcher fuer uns die SKIP CONDITION ausloest, hatten wir zuerst auf ca. 100mm vor dem Bauteil als Position
zum langsamen Fahren eingestellt und sind dann mit 500mm/s in Automatik das Teil angefahren. (bloed gelaufen aber nichts kaputt) J

Hier mal ein Programmauszug:

32: !Search pounce ;

33:L P[2] 500mm/sec CNT0 ACC100 TB .10sec,P-SPS ;

1: TC_ONLINE (ON) ;

2: DO[23]=OFF ;

3: WAIT (DI[23]) ;

4: DO[23]=ON ;

5: TC_ONLINE (M[30] AND M[31] AND M[33] AND DI[79] AND DI[202]) ;

------ ;

34: ;

35: !Definiere Fernsensor ;

36: SKIP CONDITION DI[619]=ON OR DI[623]=ON ;

37: ;

38: !Fahre mit Fern-Sensorkontrolle ;

39: !Punkt muss gelernt werden !!! ;

40:L P[3:FN] 200mm/sec CNT0 ACC100 Skip,LBL[1] ;

41: LBL[1] ;

42: PR[69]=LPOS ;

43: ;

44: !Definiere Nah-Sensor ;

45: SKIP CONDITION DI[619]=ON OR DI[624]=ON ;

46: ;

47: !Fahre mit Nah-Sensorkontrolle ;

48:L P[4:FN] 50mm/sec CNT0 ACC100 Skip,LBL[2],PR[80]=LPOS ;

49: ;

50: LBL[2] ;

51: ;

52: !Setze Position ;

53: PR[80]=LPOS ;

54: ;

55: ! Pick position ;

56: ! Job 2 done ;

57:L PR[80] 100mm/sec CNT0 ACC100 TB 0.00sec,P-SPS Offset,PR[81] ;

Wie man oben sehen kann, haben wir die Geschwindigkeit zum ersten SKIP-Punkt von 500mm/s auf 200mm/s zurueckgenommen.
Der Sensor wurde auch angepasst und auf ca. 400mm Abstand eingestellt.

Das hilft mir aber nicht bei meiner Taktzeitoptimierung.

Hier jetzt die Frage:

Kann der Nachlaufweg beim ersten SKIP z.B. durch irgendwelche Systemvariablen (Einstellungen) verkuerzt werden,
so dass der Roboter eine andere Rampe faehrt und nicht augenscheinlich austrudelt.

Einen leichten Nachlauf wuerde ich ja akzeptieren aber keine 300mm und mehr…! Das hat mit geregeltem Anhalten wenig zu tun.

Die zweite SKIP Anweisung, die ich mit 50mm/s anfahre ist es ja kein Problem. Dort liege ich gut in der Mitte der erlaubten 100mm/s
fuer diese unterschiedliche Programmierweise, die auch zu einem sofortigen Stop des Roboters fuehrt.

Es waere klasse, wenn von euch jemand schon mal aehnliche Probleme hatte und eine Loesung gefunden hat und diese gerne teilen wuerde.

Danke fuer eure Hilfe und viele Gruesse und allen einen guten Rutsch

Ralf

Hallo Leute,

erstmal ein Dankeschön an luke321.
Leider hat uns das nicht geholfen.

Der Fehler liegt beim Vermessen des Roboters zur ext. Achse. Wenn man das überhaupt einen Fehler nennen kann. Die zwei gespiegelten Anlagen wurden
von unterschiedlichen Leuten vermessen. Der eine hat die Winkel der Achsen mehr als der andere verändert. Mann soll aber die Winkel so wenig wie möglich verändern. Die Drehrichtung der ext. Achse ist dabei egal. Die externe Achse kann von + nach - oder von - nach + verfahren werden. Das macht keinen Unterschied. Dieses steht auch so bei Motoman in der Beschreibung. Wir haben das getestet und konnten keinen Unterschied feststellen.
Zufriedenstellend war die Erkenntnis, dass es am Vermessen liegt jedoch nicht, da man beim Überprüfen des synchronen Verfahrens vom System nicht merkt, wie sich die TCP-Geschwindigkeit verhält. Beide Führungsroboter (R1 oder R2) hielten die Position zur externen Achse gleich gut. Wenn man also die TCP-Geschwindigkeit überprüfen will, muss man schon etwas mehr anstellen. In unserm Fall beträgt die zu verfahrende Strecke einer Rundnaht 130mm. Die geteachte Geschwindigkeit beträgt 13mm/s und die externe Achse muss dabei um die 360° drehen. Dazu kommt noch, dass das Bauteil nicht im Achsmittelpunkt der drehenden Achse liegt. Wenn man sein Programm sauber und immer mit dem gleichen Abstand geteacht hat, sollte man ziemlich genau nach 10s mit dem Umlauf fertig sein. Bei uns betrug die Zeit jedoch ca 25s. Das System hat die TCP-Geschwindigkeit komplett in den Keller gerechnet.
Also immer schön aufpassen wie ihr zu externen Achsen vermesst. Wenn ihr grosse Radien verfahrt, werdet ihr es evtl. nicht merken, dass die TCP-Geschwindigkeit nicht stimmt. Ich habe es auf einem grossen Radius mit unterschiedlichen Geschwindigkeiten ausprobiert und bin bei unterschiedlich vermessenen Systemen (grosse Winkeländerungen) auf das Gleiche Ergebnis gekommen.
Bei kleinen Radien ist es aber gravierend, da dort ganz andere Beschleunigungen gefahren werden müssen.

Im Handbuch von Motoman steht leider nur etwas über die Genauigkeit und nichts zur TCP-Geschwindigkeit beim Vermessen von externen Achsen.
Hätte das dort gestanden, könnte man eher Rückschlüsse auf ein evtl. (nicht korrektes) Vermessen ziehen. So mussten wir leider den Service von Motoman bemühen.

Viele Grüsse
Ralf

Hallo Leute,

Erstmal frohes neues Jahr.

und jetzt folgendes Problem

Steuerung: NX100 mit zwei Robotern und einem Drehtisch.
Anwendung: gekoppeltes Schweissen mit externer Achse

Wir haben hier eine Schweissanwendung bei der wir mit einem Roboter gekoppelt auf einer drehenden Achse schweissen und der andere warten muss.
Der Führungsroboter (in der ersten Anlage R1) bewegt sich beim Schweissen auf der drehenden Achse. Wir können ihn nicht stehen
lassen, da die Zugänglichkeit fehlt. Das Ergebnis der Schweissnaht ist eigentlich prima.
Nachdem wir das Programm fertiggestellt hatten, haben wir dieses in einen anderen, gespiegelten Anlagenteil eingespielt. Dort ist die Vorrichtung eigentlich komplett identisch. Der einzige Unterschied ist, dass dort alles gespiegelt aufgebaut ist. Hier haben wir also auch unsere Programmteile gespiegelt. Jetzt führt nicht mehr R1 die Achse sondern R2.
Nachdem alles verschoben und nachgeteacht war, mussten wir beim Schweissen feststellen, dass das gekoppelte Schweissen auf der drehenden Achse
viel langsamer war als bei der anderen Anlage wo R1 die Achse führt. Die Geschwindigkeiten und Parameter sind aber identisch.
Das Getriebeübersetzungsverhältnis, die Motordaten, die Werkzeugdaten und diverse andere Parameter sind in beiden Anlagenteilen identisch.

Ich sollte noch dazu sagen, dass der jeweils zweite Roboter warten muss solange der andere die Rundnaht schweisst. Wir fahren hier also nicht
Synchron mit beiden Robotern auf einer drehenden Achse. Die Bewegungsarten sind bei der Rundnaht mit SMOV programmiert.
Wir können uns leider nicht erklären, warum es in der Anlage, in der R1 die Achse führt sauber läuft und in der Anlage in der R2 die Achse führt, total langsam ist.
Es sieht fast aus, als ob wir mit Teachgeschwindigkeit fahren. Wir haben auch schon einige Test-Job's erstellt, in denen wir nur die Achse mit
100% MovJ fahren. Keine erkenntlichen Probleme hierbei. komisch!

Hat jemand eine Idee? Die Hotline von Motoman war leider nicht sehr hilfreich. Das ist doch bestimmt wieder einer dieser netten Parameter.

Vielen Dank für Eure Hilfe

Viele Grüsse
Ralf

Hallo HRU26011,

Das Problem lag daran, dass jemand an der Q8 Steuerung die Parameter auf AUS gestellt hatte.
Der Robi konnte somit nicht mehr zugreifen.
Wir haben die Parameter wieder freigegeben und der Fehler war weg.

Danke für Deine Antwort.

Gruss
R.Bartels

Hallo Leute,

wer weiss, wie ich den Alarm 4454 beheben kann.
Reicht es eine alte Datensicherung einzuspielen? Wenn ja, welche Datei?
Habe leider nur eine englische Fehlerliste.

Es geht um eine Twin Schweissanlage.
R2 will Zünden (zündet auch kurz) und R1 kommt sofort mit dem Fehler 4454.

Danke für Eure Hilfe