Beiträge von BauAnd01

Hallo Robotergemeinde,

zuerst wünsche ich ein gesundes und erfolgreiches Neues Jahr. Ich habe eine Aufgabe, die ich zwischen den Jahren mal eben lösen wollte. Bisher scheitere ich allerdings. Folgende Situation:

Ich habe einen KR200 mit KRC2 ed05 Steuerung. Der Roboter hat eine rotationssymmetrische Vorrichtung angeflanscht, an der um jeweils 90° verdreht (Verdrehung um die Vertikale) die gleichen Bewegungen erforderlich sind (Roboter bewegt sich in BASE-KOS). Die Vorrichtung ist so angeflanscht, dass der Roboterflansch horizontal steht (Z-Achse des TOOL-KOS zeigt aus dem Flansch heraus). Aufgrund der Medienführung musste ich die A6 sowohl in + als auch in - auf 210° beschränken (Software-Endschalter).

Mein Plan war nun die Bewegungn z.B. an der 0°-Position zu teachen und diese über die Drehung des TOOL KOS (um A) auf die anderen Positionen zu spiegeln. Um die Sache zu testen habe ich es mit einem einzelnen Punkt versucht.

Nun zum Problem:

Versuche ich eine Drehung im TOOL KOS komme ich damit max. um 90° (abhängig von der Orientierung der Vorrichtung im Punkt P1). Gebe ich größere Offsets ein kommt immer Unerreichbarer Punkt wegen Software-Endschalter, obwohl die Position in beiden Drehrichtungen noch erreichbar wäre. Leider kann ich die Softwareendschalter nicht erweitern, um zu sehen ob es daran liegt.

Folgende Varianten habe ich getestet. Leider beide mit dem selben Ergebnis:

Variante 1:

$BASE = BASE_DATA[5]

...

TOOL_DATA[2].A = 0

$TOOL = TOOL_DATA[2]

PTP XP1

TOOL_DATA[2].A = 90

$TOOL = TOOL_DATA[2]

PTP XP1

...

Variante 2:

...

$BASE = BASE_DATA[5]

Rotation = $nullframe

Rotation.A = 90

TOOL_DATA[2] = TOOL_DATA[2] : Rotation

$TOOL = TOOL_DATA[2]

PTP XP1

TOOL_DATA[2] = TOOL_DATA[2] : Rotation

$TOOL = TOOL_DATA[2]

PTP XP1

...

Wenn ich diesen einzelnen Punkt mit dem geometrischen Operator "drehe" funktioniert es seltsamerweise ohne Probleme. Leider ist das keine Lösung für die Aufgabe, da ich im Voraus nicht weiß aus wie vielen Punkten die Bewegungsfolge besteht und ich auch diese Weise immer nur einzelne Punkte ansprechen kann.

Folgendes funktioniert:

...

$BASE = BASE_DATA[5]

Rotation = $nullframe

Rotation.A = 90

$TOOL = TOOL_DATA[2]

PTP XP1:Rotation

Rotation.A = 180

TOOL_DATA[2] = TOOL_DATA[2] : Rotation

$TOOL = TOOL_DATA[2]

PTP XP1:Rotation

...

Ich hoffe, ihr versteht das Problem und freue mich auf eure Rückmeldungen. Könnte es an den SW-Endschaltern liegen?!

Vielen Dank im Voraus.

VG

Andreas

Hallo zusammen,
vielen Dank erstmal, dass ihr euch die Mühe macht euch da einzudenken. Mein Hauptproblem ist, dass der Programmierer des Offline Programmiersystems die Teachpunkte, die er dort erzeugt PTP DS_R_A (das Offlinesystem erzeugt einen INLINE Befehl). Er braucht diese Bezeichnung, damit er bei 70 Punkten und mehr noch durchblickt. Wenn ich zu ihm sagen würde, er solle einen einheitlichen Grundnamen also z.B. DS einfach mit einer fortlaufenden Nummer durchnummerieren also z.B. DS1 ... DS70, wird er mir ins Genick springen. Er weiß dann nicht mehr welche Position wo auf dem Teil ist. Also will er seine Nomenklatur beibehalten.
Ich habe nun also eine Punkteliste (im *.src als Inline (das brauche ich eigentlich nicht, aber gibt das System so raus) und in der *.dat:
Nehmen wir an Teil 1 hat 5 Punkte:
DS_R_A
DS_R_M
ES_L_A
FL_L
L_L

das Teil 2 hat 6 Punkte:
DS_R_A
DS_R_I
DS_R_M
FL_R
Ihr seht, dass es Punkte dgibt, die gleich heissen. Diese haben aber bei Teil 1 andere Koordinaten als bei Teil 2, definieren aber denselben Bereich auf dem Teil, der eben geometrisch etwas anders aussieht. Ich habe also eine Gesamtmenge von ca. 100 Punkten, deren Name aus einer Kombination des Strebentyps (DS, ES, FL, L), der Seite des Teils (R, L) und dem Teilbereich auf der entsprechenden Seite (I, M, A) besteht.
Es kann also jeder Name auftreten, muss aber nicht. Das heisst, dass die Punkte eines Teils stets eine Teilmenge aus der Gesamtmenge darstellen.
Mit der Lösung von Twister müsste ich ja immer Koordinaten für die Gesamtmenge an Punkten haben (sofern ich den Ansatz richtig verstanden habe)
Mein Plan war nun aus dem Unterprogrammaufruf den CHAR zu nehmen und damit 2 Dinge zu tun:
1. In der STRUC Variablen mit der StrComp Funktion nach einer Übereinstimmung zu suchen (damit ich die richtigen Parameter an die Peripherie zuweisen kann)
2. Den Punkt mit dem Namen des CHAR (der muss dann auch genauso heissen, aber das bringe ich an den Offline Programmierer ran) anfahren. An diesem wird dann mit den Parametern, die ich über die STRUC zugewiesen habe geschweißt.
Ich habe mal einen Entwurf des UPs angehängt. Bitte nicht so sehr auf die Syntax achten (;-)) Da sind mit Sicherheit noch Fehler drin.

neue globale Variablen

DECL STRUC PosDaten_Typ CHAR ORT[4], TYP[4], INT SCHWENK, WIP, LSR_PRG,PFO_PRG, FRAME PktName[10]
DECL PosDaten_Typ PosPara[16]

PosPara[1] ={ORT “DS_R_I”, TYP „DS“, SCHWENK 20, WIP 5, LSR_PRG 10,PFO_PRG 12, PktName XPunkt_DS_R_I}
PosPara[2] ={ORT “DS_R_A”, TYP „DS“, SCHWENK 20, WIP 7, LSR_PRG 11,PFO_PRG 14, PktName XPunkt_DS_R_A }

INT PFO_PRG $OUT[513] To $OUT[528]

DEF Schweißpunkte_32915(Position[]:IN, Schwenken:IN )

INT Schwenken, WIP, LSR_PRG, PFO_PRG, k, i, c
CHAR Position[10]
POS ROBPOS

;Ini
k=0
;Parameterzuweisung abhängig von Position

For i = 1 TO 70 ; Anzahl der Gesamtpositionen
b=StrComp(PosPara[i].Ort[],Position,#NOT_CASE_SENSE)
IF b AND (PosPara[i].SCHWENK == Schwenken)THEN
k=i
EXIT
ENDIF
EndFor

IF k <>0 THEN
WIP = Pos.Para[k].WIP
LSR_PRG = Pos.Para[k].LSR_PRG
PFO_PRG= Pos.Para[k].PFO_PRG
ROBPOS = Pos.Para[k].PktName Problem: Dies ist ein String und kein Pos!!! Alternativ:
ELSE
Fehlermeldung „Position nicht existent“
UP Abbruch
ENDIF

;Zuweisung Laserparameter
;Zuweisung Laserleistung
If LsrPartSet.Mark THEN
LPLS2.LSR_MAX_PWR=LsrPartSet.LSR_PWR_MARK
Else
LPLS2.LSR_MAX_PWR=LsrPartSet.LSR_PWR_DS
EndIf

;Zuweisung Lichtweg und WIP
If LsrPartSet.BV Then
UEBERGABE_WIP= WIP
LICHTWEG = 0 ;Absorber
LPLS2.LSR_MAX_PWR=100
Else
UEBERGABE_WIP=0
LICHTWEG=1
EndIf

;Zuweisung Laserprogrammnummer
LPLS2.LSR_PRG = LSR_RPG
;Zuweisung PFO Programmnummer
PFO_PRG = PFO_PRG

PFO START (Standard RPFO Befehl)
LIN ROBPOS

PFO END (Standard RPFO Befehl)
LIN ROBPOS

END

Ich hoffe das Problem wurde etwas klarer.

Vielen Dank erstmal im Voraus.

Mit freundlichen Grüßen
Andy

... ich sollte mir einfach mehr Zeit nehmen um die Beiträge zu lesen. Twister du hast natürlich eine Superidee gehabt, die mir erst jetzt klar geworden ist.
Das ist ein sehr guter Ansatz. So werde ich es erstmal umsetzen.
Trotzdem würde mich interessieren ob man mit CHAR hier irgendetwas zustande kriegt.

Danke nochmals.
MfG
Andy

Hallo zusammen,
danke Twister für den guten Vorschlag. Es geht mir tatsächlich darum das Programm pragmatisch zu gestalten. DIe Bezeichnung DS_R_I steht für Doppelstrebe rechts innen. Somit ist es für den Programmierer der das Ablaufprogramm schreibt (ein Laie) sehr anschaulich. Wenn ich den Umweg über die Nummern gehe braucht er eine Tabelle, wo er sich die Nummern rauslesen muss. Das es 70 Roboterpositionen und mehr gibt, ist dort die Wahrscheinlichkeit sehr groß, dass er Fehler einbaut, die dann erst an der Anlage sichtbar werden. Deswegen wollte ich es aus dem String lesen.
Seht ihr diesbezüglich irgendeine Möglichkeit.
PS: Bei den anderen Parametern handelt es sich um Schweißparameter, die aber durch di STRUC fest zugeordnet sind, d.h. wenn ich die richtige STRUC im Feld gefunden habe ist der Rest eine einfache Zuweisung.

Vielen Dank euch im Voraus.

MfG
Andy

Hallo Forumuser,
ich habe eine Aufgabe, bei der ich nicht weiterkomme:
Wir haben auf einem Teil eine Vielzahl von Bewegungspunkten. Diese werden über ein Offlineprogrammiersystem „geteacht“. Von diesen Teilen existieren ca. 400 verschiedene, bei denen zwar die Punkte woanders liegen, diese aber durch das Offlineprogrammiersystem gleich heissen. Nicht auf jedem Teil sind alle Punkte vorhanden. Die Reihenfolge in der die Punkte angefahren werden, wird in einem übergeordneten Programm festgelegt. Die Punkte aus dem Offline Programmiersytem werden in einer *.dat heraus geschrieben.

Ich habe nun folgendes vor:
Ich habe eine globale STRUC generiert, die folgendermaßen aussehen soll:
DECL STRUC PosDaten_Typ CHAR ORT[4], INT WIP, LSR_PRG,PFO_PRG, CHAR PktName[10]
DECL PosDaten_Typ PosPara[16]

PosPara[1] ={ORT “DS_R_I”, WIP 5, LSR_PRG 10,PFO_PRG 12, PktName[] “XPunkt_DS_R_I”}
PosPara[2] ={ORT “DS_R_A”, WIP 7, LSR_PRG 11,PFO_PRG 14, PktName[] “XPunkt_DS_R_A“}
Usw.

Der Anwender gibt nun in seinem Ablaufprogramm die Reihenfolge mit einem Unterprogrammaufruf an in dem ein String übergeben wird:
Schweißen („DS_R_I“)
Schweißen („DS_R_A“)
In dem UP wird der String über eine FOR Schleife mit dem pospara[].ORT verglichen. Sobald der richtige pospara.ORT gefunden wird, werden einerseits die restlichen Parameter (WIP,LSR_PRG,PFO_PRG) an die Peripherie übergeben und andererseits soll der Punkt angefahren werden, dessen Name in der Variablen pospara[].PktName hinterlegt ist. Da aber nicht bei jedem Teil alle Namen vorhanden sind, kann ich die Punktnamen nicht direkt als Frame zuweisen. Den Punktnamen in der STRUC zu hinterlegen halte ich für sinnvoll, weil dadurch der komplette Parametersatz eindeutig definiert ist und somit global gültig.
Nun zu meiner Frage:
Besteht die Möglichkeit einen Punkt über seinen Namen mit einer CHAR Variable aufzurufen?
Also: LIN “DS_R_A“
Aber „DS_R_A“ repräsentiert in diesem Fall nur den Punktname als CHAR. Evtl. ist hier mit SREAD etwas zu machen?! Oder gibt es die Möglichkeit wie in VB der Steuerung über „ oder ` klar zu machen, dass es sich hierbei nur um den Namen und nicht um das Frame handelt?!
Ich hoffe es kann mir hierbei jemand helfen. Evtl. denke ich auch zu kompliziert und es geht viel einfacher.

Auf jeden Fall schon einmal vielen Dank im Voraus
Viele Grüße
Andy

Hallo Martin,
dass wäre genau das was ich vorhabe. Ist dort mit irgendwelchen unkontrollierten Reaktionen zu rechnen? Es darf beispielsweise nicht passieren, die Achse ihre Position ungenau anfährt oder über die Position hinausfährt. Das könnte sonst unschön enden.
Was passiert wenn während dieser Bewegung das Roboterprogramm abgebrochen wird? Läuft die Bewegung trotzdem weiter?

Vielen Dank im Voraus.

MfG
Andy

Hallo Martin,
danke für die Antwort, da ich bestimmte Positionen erreichen muss, muss der Ablauf mit programmierter Position durchgeführt werden. Außerdem wird der Tisch verriegelt und darf dann nicht mehr bewegt werden. Daher ist die Lösung mit den Freigabetastern zwar möglich, beinhaltet aber zusätzliche Risiken.

MfG

Andy

Hallo zusammen,
ich programmiere gerade eine Anlage mit 6 Zusatzachsen. Es handelt sich um eine Anlage mit 2 Bearbeitungszellen mit je 3 ext. Achsen. Während in der einen Zelle bestückt wird, wird in der anderen vom Roboter bearbeitet. Die ext. Achsen werden alle asynchron bewegt. Jeweils eine ext. Achse ist für die Kippung des Bearbeitungstisches zuständig (ist erforderlich, dass der Werker die Teile einlegen kann). Da der Tisch sehr schwer ist und dieser über Bolzen pneumatisch arretiert wird, dauert der Vorgang recht lange, so dass bei der sequentiellen Bearbeitung lange Totzeiten in Kauf zu nehmen sind.
Ich möchte diesen Kipp- und Arretiervorgang gerne schon durchführen, während der Roboter in der anderen Zelle noch bearbeitet. Ich würde hier versuchen über die sps.sub die Bewegung durchzuführen, habe aber keinerlei Erfahrung damit. Da die Anlage schon produziert, würde ich die Nebenwirkungen ungern im laufenden Betrieb erkunden wollen.
Kennt sich damit jemand aus? Ist das der richtige Ansatz? Gibt es kritische Punkte (z.B. Positioniergenauigkeit)? Was passiert bei Programmabbruch etc?
Es handelt sich um einen KR 100 HA mit KRC 2 Steuerung (Safe)

Vielen Dank für eure Hilfe im Voraus.

MfG
Andy

Ne wir haben einen normalen Roboter. Bringt der HA Roboter bei der Wiederholgenauigkeit überhaupt Vorteile? So richtig verstanden habe ich dessen Vorteile noch nicht, den Sie sich für teuer Geld bezahlen lassen. Ich weiß nur soviel, dass der Roboter "absolutvermessen" ist und dort Getriebe mit besonders guten Fertigungstoleranzen verwendet werden. Ansonsten weißt der HA Roboter lt KUKA Vertrieb keine Besonderheiten auf (ggf. noch spezielle Softwarefeatures). Den Vorteil mit den Getrieben kann ich mir noch erklären, aber was genau bringt diese Absolutvermessung? Werden damit Toleranzen korrigiert, die bspw. aus nicht exakten Achslängen und -spielen resultieren? Wenn ja, bringt diese Absolutvermessung etwas für die Wiederholgenauigkeit?!

In Bezug auf die Werkzeugvermessung denken wir auch über eine kombinierte Lösung mit CAD nach, um die groben Werkzeugdaten zu ermitteln. Wie gesagt, das Hauptproblem liegt derzeit in der Erkennung des Strahlmittelpunktes. Die Sensorgeschichte ist mit "Hausmitteln" nicht einfach umzusetzen. Wenn man entsprechende Sensoren kauft ist man schnell mal 1000€ und mehr los.
Den Fehler der Roboterpositionsgeber rausrechnen? Diese sind doch dynamisch und daher nicht immer konstant oder?

wir sind momentan noch auf der Lösungssuche. Wir überlegen, ob wir es über eine iterative Optimierung machen. Das Problem dabei ist dass die Genauigkeit bei ca. 0,1mm liegen sollte. Aber wie kann man das messen?! Überlegungen gehen auch zu lichtempfindlichen Sensoren, die einem den Strahlmittelpunkt ausgeben.

Hallo Roboterfreunde,
ich habe eine Problemstellung zum Thema Werkzeugvermessung. Wir müssen eine Laseroptik als Roboterwerkzeug einmessen. Da wir soweit wie möglich offline (zumindest vor-)programmieren möchten, sollte hierbei eine möglichst hohe Genauigkeit erreicht werden. Das "Werkzeug" wird während der Bearbeitung um den TCP um die A, B, und C Achse verdreht (dieser liegt ca. 450 mm unterhalb der "Hardware" der Optik). Eine taktile Vermessung des TCPs scheidet also leider aus.
Bei meiner Recherche bin ich auf verschiedene Systeme gestossen. U.a. das LASERLAB der Firma Wiest. Allerdings erscheint es mir auch nur für die Vermessung von taktilen Werkzeugen geeignet.
Derzeit vermessen wir Laserwerkzeuge mit Hilfe des Pilotlasers und eines adaptierten Laserdistanzsensors an einer Kegelspitze. Die erreichbaren Genauigkeiten sind bei dieser Messmethode allerdings nicht ausreichend, da zum einen eine Laserdistanzmessung auf eine Spitze ungenau und schwierig ist und zum anderen der Pilotlaser auf der Spitze gebrochen wird und die Mitte nicht mehr eindeutig sichtbar ist. Diese Ungenauigkeiten addieren sich dann beim Anfahren von insgesamt 4 Punkten zu einer relative großen Gesamtabweichung. Auch das Vermessen nach dieser Methode auf einer ebenen Platte mit einem markierten Fadenkreuz ergibt nicht ausreichende Genauigkeiten.
Gibt es nach euerem Kenntnisstand Systeme oder Techniken um solche Werkzeuge mit hoher Genauigkeit einzumessen?

Vielen Dank für eure Hilfe.

Andy