Beiträge von RacingHell

Bei allem was man mit Palletizing anstellen kann hat es aber auch so seinen dicken Nachteil: Wenn man etwas an der Palettierung korrigieren muss ist man eeewig am nachteachen: 3x Pos für Koordinaten, min. 3x Eckpos. für Palettierfläche und Anfahr+Rückzugspunkt. Das macht 8 Positionen, wogegen die eigene (sicher auch wesentlich einfacher gehaltene) Palettierung meist über das Korrigieren eines einzigen Punkts zur Lösung führt.

Was ich bei Fanuc ja ganz nett finde ist, dass man mit den lokalen Positionsvariablen P[] vollwertig arbeiten kann als wären es globale PR[]'s.

Die Datensätze für verschiedene Artikel legst du dabei in einem jew. Format an die im ersten Part den kompletten Teileablauf als Teachabfolge beinhaltet.

Du suchst dir einen Bereich heraus der die sich nicht ändernden Umgebungspunkte vor deinen Stationen sowie für immer gleichbleibende Offsetwerte beinhaltet und schliesst den Bereich aus dem Teiletypabhängigen aus.

Das Format hat dann folgende Bestandteile:
- JMPLBL über den Teachablauf (hier zum Teachen nach der Sprungmarke manuell abfahren)
- Positionsablauf mit Remark (z.B.: !Hier mit Shift+TouchUp teachen! (Pxxx) <-Angabe wichtig falss jmd. falsch teacht und die Pos.nummer geändert wird!) ) vor und nach den zum Teachen erlaubten P[]'s (die P[]'s bekommen die Nummer der künftigen PR[]'s des Hauptprogrammablaufs)
-LBL
- evtl. Plausibilitätsprüfung ob Typ/Typwechsel erlaubt
- Schreiben der Offsetwerte und Register die sich teiletypabhängig ändern
- Schleife zum Kopieren der P[]'s in die PR[]'s
(bei sinnvoll aneinandergereihter Positionsliste
R[200]=x (Startpos.nr.)
LBL:1111
PR[[R]200]=PR[[R]200]
R[200]=R[200]+1
IF R[200]<=y (Endpos.nr.) , JMP LBL:1111
)

Im Hauptprogramm wechselst du den Teiletyp dann durch Einlesen des entsprechenden Formats.

Es gibt neben der CPU-Einheit ein Klemmbrett Names X18 (beim Schwedenschrank, beim Japaner unten mittig auf dem Boden des Schaltschranks). Dort findest du die Sicherheitskanäle SAFF1 und SAFF2 (o.ä.). Wenn du rechts davon die beiden Jumper rausnimmst und die Schranke über ein Sicherheitsrelais 2-kanalig anklemmst bremst der Roboter beim Betreten des Bereichs sofort bahntreu ab und schaltet die Servos aus.. das ist auch zwingend nach Vorschrift notwendig. Selbiges findest du auch für den Not-Stop unter andere Bezeichnung mit dem Unterschied, dass hier nicht bahngetreu & härter angehalten wird - wiederrum gesetzl. Vorschrift. Die Servos kannst du über Ext.ServoOn (müsste auch auf X18 sein) als Hardware verdrahten wenn du ein TCP/IP-E/A-Modul in der Nähe hast oder im SPS lösen - Selbiges gilt für Reset/Start/Stop. usw..

Das freut mich zu hören

Generell muss beim Teachen des Koordinatensystems der Winkel - also die Werkzeugorientierung NICHT plan zur geteachten Oberfläche sein. Es muss lediglich die gewählte Orientierung (klein x,y,z) für ORG, XX und XY gleich bleiben da der Bezug der geteachten Ebene sich durch die drei Bezugspunkte die man ja ergo ablegt ergibt.

Korrekturen sind einfach, die werden direkt im Setup des Userframes gemacht. Hierzu einfach (wissentlich in welcher Richtung der Fehler liegt und dem Wissen wieviel man in etwa korrigieren muss) den Punkt (NICHT ORG!) XX und/oder XY abgleichen indem man ihn im Setup anwählt und mit FWD anfährt, den Korrekturwert von Hand verfährt und wieder mit Modify+Enter speichert. Nach jeder Korrektur durch amnuelles Abfahren erneut prüfen, ist im Prinzip ein Annäherungsverfahren.
Wenn nichts hilft, alle drei Punkte neu teachen -> mit dem Wissen, dass sich alle Positionen die in dem UFrame abgelegt wurden um den Versatz zwischen ORGalt->ORGneu verschieben werden.
Bsp.:
Beim Abfahren des Frames ergibt sich ein Fehler in X-Richtung:

= = tatsächliche Frame-Ebene
- = abgefahrene Ebene

ORG======================XX ^
------------- Fehlerdistanz und Richtung
--------------
-----------XX _____

Alternativ könnte ich mir vorstellen, dass so eine Korrektur auch über Zahlenwerte machbar ist. Hierzu bitte näher mit dem Befehl MFRAME PXxxx PXxxx PXxxx (make Frame) auseinandersetzen. Wenn es Möglich ist, die drei Positionen aus dem Frame in drei Positionen auszulesen könnte man sie evtl. (wenn nicht schon in UF#(x) ) ins bestehende Frame konvertieren, aus den nötigen Positionen die korrekturrelevante/n Daten in eine Double auslesen, den Korrekturfaktor den der Kunde über eine Double oder Integervariable definiert addieren->Wert zurück in Position, die drei Pos. wieder ins Frame zurückspielen. Hierfür würde ich dann einen "Korrekturjob" basteln den der Kunde nach Korrekturwerteingabe im Teachbetrieb ausführt.

Generell kannst du dann eben auch jeden der geteachten Punkt nach erfolgreichem einrichten wieder mit FWD anfahren und in eine Pos.variable packen (und dem Bediener Korrektur über die Direkwerte der Positionen überlassen - Vorteil hierran wäre, das Progr. ist nur ein Einzeiler bestehend aus MFRAME. Nur um den Winkel der Ebene zu korrigieren wirst du nicht über div. Winkelfunktionen deren Berechnung du selbst erstellen musst herumkommen.

Ich weiss nicht was du mit der Pos. P098 machst. Das scheint wenn überhaupt eine alte Position von irgendenem Versuch zu sein die dort noch abgelegt ist und zufällig anfahrbar ist. Du solltest wahrscheinlich CNVRT P097 P099 eintragen.

Sinnvollste Lösung wäre:
P099 auf Greifposition teachen (in Pulsdaten),

im Ablaufprogramm dann:
CNVRT P098 P099 UF#(1)
GETE D0xx (3) P098
ADD D099 xxxxx <---- Hier die Distanz eintragen die in Z über das Teil gefahren werden soll
(1000 = 1mm)
SETE P098 (3) D0xx

Jetzt kannst du die Positionen fahren:
MOVJ P098...
MOVL P099...
.....
MOVL P098...

Es kommt vor, dass sich nach einem Crash das Motorritzel einer Achse leicht löst und je nach Belastungsgrad oder Temparatur etwas durchrutscht.

Mit Vorsicht zu geniesen, aber: War es nicht so, dass NWAIT (NoWait) "lediglich" den Satzvorlaufzeiger weiterlesen lässt wenn alle folgenden Wait-Bedingungen erfüllt sind?

Würde den Befehl nicht raten, wenn danach auch Ausgänge geschalten werden. Da der "verfrühte" Schaltzeitpunkt dann undefiniert in die Roboterbewegungszeit mit eingeht. .. kann von Vorteil sein, ist aber gefährlich wenn man nicht genau weiss was man tut!

NWAIT ist dazu da, einen unnötigen Bewegungshalt durch diverse Befehle !nicht einzuleiten. Meiner Erfahrung nach ist:

MOVJ P000 NWait
WAIT IN#(25)=ON
MOVJ P001

durchaus möglich und lässt bei gegebenem IN25 die Fahrt von P000 nach P001 überschleifen.

Mit leichter Gewalt lassen sie die Karten leider falschrum stecken, das bitte beachten.

Ab und zu gibt es auch Probleme mit den CF-Card-Adaptern. Dann einen anderen versuchen.

Umso grösser die Karte, je länger geht es bis man nach dem Einstecken ohne Fehlermeldung Zugriff darauf hat. Bei Karten >64mb also ruhig 10Sekunden gedulden.

Karte kann auf der XRC direkt im FD/CF-Menu formatiert werden.

Dort auch kontrollieren ob ab Laufwerk CF-Card eingestellt ist.

Kontakte und Pins reinigen/Sichtprüfung.

Sonst hilft nur noch der Service.

Programmiermodus oder Erweiterter Modus:

Externes Koordinatensystem auf die Kiste legen. Zu finden unter Roboter -> Anwenderkordinaten - Freies Koordinatensystem UF#(x) mit "Kiste" beschriften, in das Koordinatensystem hinein, Framepunkte ORG(Ursprung)/XX(Pos. X-Richtung und Ebene/XY(Pos. Y-Richtung und Lage) jeweils mit einer Bezugsspitze im/vom Greifer teachen und jew. mit Modify->Enter Punkte schreiben -> Menü bestätigen. Taste Koord bis oben rechts in der Statusleiste Userframe angewählt. Wenn nicht das eben eingerichtete (Nummer im Bild des Frame) U-Frame angewählt -> Shift+Coord -> Frame "x" (Kiste) mit Cursor markieren und ebenfalls mit Shift+Koord wieder aus der Auswahl raus. Jetzt den Roboter manuell in X/Y/Z verfahren und kontrollieren ob das U-Frame zur Ebene der Kiste stimmt. Ansonsten erneut Frame einrichten. Wenn Z+ nach unten fährt liegt XY auf der falschen Seite der ORG->XX-Strecke.

Positionen der Framepunkte. XY ist nicht richtungsweisend und bestimmt nur noch die Lage, kann also beliebig auf der Ebene platziert werden.
_____________
| |
| XY |
| Kiste |
| |
| |
|ORG_____XX_|

Teachen ist nun im U-Frame "x" auf der Ebene möglich. Für Berechnungen mit dem Ursprungspunkt muss dieser in UF#(x) konvertiert werden, nun können Distanzen usw. in dem Frame verrechnet werden falls notwendig.

Hallo,

leider unterscheidet sich die Programmierweise zwischen Motoman und Kuka. Wie du schon richtig sagst, baut Kuka auf C auf, Motoman dagegen auf Basic (sehr einfach gehalten). Wenn du z.B. Code ausblenden möchtest um der Übersicht ein Gutes zu tun schneid doch den Programmpart aus dem Hauptprogramm aus und pack ihn in einen neuen Job welchen du dann per Unterprogrammaufruf über "CALL JOB" anschubst. Vorteil daran ist auch, dass du den selben Code wenn er mehrmalig verwendet wird immer wieder aufrufen kannst. Generell tendierte ich immer Richtung "Baukastensystem".

Wenn der Code den du ausblenden möchtest nicht zeitsynchron zum Hauptprogramm ablaufen muss und keine Bewegungsanweisung enthält kannst du auch einen Paralleljob erstellen und diesen mit PSTART "JOBNAME" SUB1(-6) starten und mit PWAIT SUB1(-6) auf dessen Ende warten. Vorteil daran ist, dass du beim Einrichten und zeilenweiser Abarbeitung nicht den Code des Unterprogramms durchsteppen musst und Geschwindigkeitsvorteile im Automatik erzielst.

Auch alt, sry.. ich finde das ist aber ein recht wichtiges Thema, da aus Erfahrung heraus viele Kunden Schwiereigkeiten beim sehr genauen Teachen haben.

Was Positioniergenauigkeit angeht wissen viele, dass es so manches mal schwierig ist ein prozess-sicheres Ergebniss hinzubekommen wenn spielfrei eingelegt/entnommen werden muss.. hierzu is vorallem wichtig:

- steht der Roboter nicht 100%ig waagrecht/parallel zur Quelle in die eingeführt werden soll und somit auch keine lineare Fahrbahn beim teachen im Roboterkoordinatensystem "parallel" zur Vorrichtung gegeben ist, rentiert sich für längere Distanzen ein Anwenderkoordinatensystem welches auf diese ausgerichtet ist.

- die Greiferbacken müssen das Werkstück spielfrei zentrieren, wenn es Möglichkeiten zu kippeln hat, verklemmt es sich u.U. ...ist je nach Anwendungsfall unterschiedlich

- die Werkstückorientierung muss bestmöglich zur Vorrichtung stimmen, das ist im schrittweisen Positionieren über klein xyz in Geschwindigkeitsvorwahl "I" nicht möglich da die Schritte zu grob verfahren werden, Abhilfe schafft kurzes Antippen der Richtungstasten in Vorwahl "L"

- das Zentrum lässt sich wesentlich besser treffen, wenn man den Parameter S1xG031 auf 3 stellt, somit hat man je Tastendruck in gross XYZ in den kartesischen Koordinatensystemen Geschwindigkeitsvorwahl "I" eine Bewegung von 3/100 mm.

- bei schweren Teilen ist oft ersichtlich, wie sich der Roboter beim Greifen durch das zusätzliche Gewicht neigt, dieser Neigung sollte entgegen gewirkt werden indem man die Werkzeuglage entgegen der Neigung ausrichtet, somit zentriert sich eben diese Werkzeugorientierung nach dem Greifen auf's Soll. Trifft z.B. beim senkrechten Entnehmen eines Teils bei vertikaler Greiferausrichtung aus einem Passdorn zu.

Entschuldigt, das Thema ist schon alt, aber anbei wollte ich bemerken dass der wohl schnellste Weg einfaches kopieren der Variable über:

SET P013 P001

ist.
Hiermit überträgt sich übrigens auch die Formatierung der Positionsvariable. (Pulse, RF, UF ...)

mfg