Beiträge von Stups

Versuch mal, die "System- Homes" mit deinen Touch- Ups zu überschreiben:

$H_POS = xHome ; für $in_home
$axis_home[1] = xhome1 ; für $in_home1
usw...

Denn die Systemvariablen $in_homexy sind nicht mit deinen Touch- Up Positionen sondern mit den Werten in $h_pos bzw. $axis_home[x] verknüpft.

mfg Stups

So, hier nochmal etwas konkreter:

Alle Angaben natürlich ohne Gewähr und auch die Bewegungsprogramme rund um die Funktionen bitte selbst machen

Ich geh mal davon aus, dass dein Werkstück auch auf der vermessenen Base liegt- also Z liegt normal zu X_Y in der Vertikalen von oben drauf (-Z Richtung bewegt Robi zum Werkstück) und du auch im Base- KS arbeitest.

1) Kontaktfahrt mit TrigByContact:

Stiffness- Parameter belegen:

;defaultstiff =$stiffness      ;einmalige vorbelegung
defaultstiff.strategy =20 ; gewünschter Regler = kart. Steifigkeitsregler
defaultstiff.frametype =#Base ; gewünschtes Koordinatensystem
defaultstiff.cpstiffness ={x 2000.0,y 2000.0,z 2000.0, a 200.0,b 200.0, c 200.0}
defaultstiff.cpdamping ={x 0.7,y 0.7,z 0.7,a 0.7,b 0.7,c 0.7}
defaultstiff.tool =tool_data[1]
defaultstiff.axisstiffness ={a1 2000.0,a2 2000.0,a3 2000.0,a4 2000.2,a5 2000.0,a6 2000.0,e1 2000.0}
defaultstiff.axisdamping ={a1 0.7,a2 0.7,a3 0.7,a4 0.7,a5 0.7,a6 0.7,e1 0.7}
defaultstiff.cpmaxdelta ={x 100,y 100,z 100,a 100,b 100,c 100}
defaultstiff.maxforce ={x 70.0,y 70.0,z 70.0,a 70.0,b 70.0,c 70.0}
defaultstiff.axismaxdelta ={a1 100.0,a2 100.0,a3 100.0,a4 100.0,a5 100.0,a6 100.0,e1 100.0}
defaultstiff.axismaxdeltatrq ={a1 2.0,a2 2.0,a3 2.0,a4 2.0,a5 2.0,a6 2.0,e1 2.0}

Gewünschte Stiffness- Parameter eintragen:

$stiffness.strategy=10 ; zuerst Positions- Regler Aktivieren- muss normal nicht sein da du ja sowieso zuerst im Positionsregler bist- oder?
$stiffness.commit=true ; Regler Bestätigen und Aktivieren


userstiff=defaultstiff ; Gesamten Parametersatz in eigenen Satz kopieren (userstiff muss ggf. deklariert werden...) 
userstiff.cpstiffness.x=1000 ;Gewünschte Steifigkeit in X
userstiff.cpstiffness.y=1000 ; " - " Y
userstiff.cpstiffness.z=1000 ; " - " Z
userstiff.tool=tool_data[1] ; Greifer Zuweisen

Papas Parameter deklarieren (natürlich im Deklarationsteil ganz oben...):

DECL INT md_int[16]
DECL REAL md_float[16]
DECL INT n
DECL INT result
;Initialisieren der Papas- Paramteter:
for n=1 to 16
md_int[n]=0
md_float[n]=0
endfor

TrigByContact aktivieren:
(Hier bitte auf die genaue Vermessung des Werkstücks achten, da sonst schon Kräfte entstehen, die das Auslösen verursachen könnten- sprich Gewicht und Lage des Gewichts)

md_float[1]= 0.5 ; Schwelle in rel.% der maximalen Kräfte an den Gelenken- Sprich Ansprechschwelle fürs Auslösen TbC
result=MD_CMD("PAPAS","TRIGBYCONTACT",md_int[],md_float[]) ; PAPAS- Treiber beschreiben
$stiffness=userstiff ; PAPAS- Treiber wird mit Setzen der Stiffness- Parameter aktiviert
; ab hier Bewegungsfahrt und auf Kontakt warten z.B:
lin_rel{z -100} ; 100mm Richtung Werkstück

Jetzt ist dein Robi bei Kontakt (50% des max. Wertes) mit dem Werkstück im kart. Steifigkeitsregler mit cp- Stiffness jeweils 1000

2) Desired Force:

Damit dein LBR nach dem Kontakt auch stehenbleibt, musst du das natürlich auch programmieren:

Dazu im cell oder sonstigem Oberprogramm einen Interrupt definieren, der auf das Auslösen des kart. Steifigkeitsregler reagiert- etwa so:

;Roboterstop wegen Trig by contact 
INTERRUPT DECL 10 WHEN $stiff_strat_act == 20 DO stopp( ) 
INTERRUPT ON 10

Im Stopp() dann so etwa:

brake	f ;Roboter Stop
ptp $axis_act_mes ;SAK herstellen
INTERRUPT OFF 10

Jetzt Steht der Robi mal (im kart. Steifigkeitsregler) und wartet auf weitere Befehle;

Jetzt Kraft aufschalten:

DEF forceY()
DECL INT md_int[16]
DECL REAL md_real[16]
DECL INT n
DECL INT result


FOR n=1 TO 16
md_int[n] = 0
md_real[n] = 0
ENDFOR


md_int[1] = 1 ;konstantes Kraftprofil
md_int[2] = 0 ;Kraft muss seperat gestartet werden
md_int[3] = 0 ;Zeitbasis: gemeinsam
md_real[1] = 5.0 ;Kraft N
md_real[2] = 2.5 ;Zeit sec
md_real[3] = 100.0 ;Max. Auslenkung 100mm
md_real[4] = 0.2 ;Max Geschwindigkeit 0.2m/s
md_real[5] = 1.5 ;Anstiegszeit sec
md_real[6] = 1.0 ;Abfallzeit sec
md_real[7] = 0 ;


result=MD_CMD("PAPAS","DESIREDFORCEY",md_int[],md_real[])
result=MD_CMD("PAPAS","DESIREDFORCESTART",md_int[],md_real[])
END

3) Ausgang setzten:

$cycflag[1] = $torque_tcp_est.ft.y > 5 ; Hier bitte wieder beachten, dass dein Werkzeug genau vermessen ist, da ja sonst der Robi dessen Gewicht schon als Kraft empfindet. (leicht zu testen mit GravComp- Achtung :-))
interrupt decl 20 when $cycflag[1] do savepoint()

Du kannst statt den Flag normalerweise auch einen Ausgang setzen anstatt dem Programmaufruf. Ich kanns nur jetzt nicht Probieren. Aber beim Ausgang dann bitte ein continue verwenden, damit kein Vorlaufstopp ausgelöst wird.

4) Kraft löschen und wieder in Pos- Regler:

FOR n=1 TO 16
md_int[n] = 0
md_real[n] = 0
ENDFOR
result=MD_CMD("PAPAS","DESIREDFORCECLEAR",md_int[],md_real[])
ptp $pos_act_mes
$stiffness.strategy=10
$stiffness.commit=true

Sollte so funktionieren;

Ob du den Robi anhältst oder direkt auf die Kraft umschaltest musst du selbst wissen (Trial&error).
Ob du vor der Kraftschwelle nochmal in den Positionsregler umschaltest ebenso- bedenke, dass der Robi ja schon mit den eingestellten Parametern weichgeschalten ist. Du müsstest gegebenenfalls die X und Z- Werte vorher auf 5000 schalten, damit er in diese Richtung steif ist. Wo und wie du das Warten einbauen willst überlasse ich auch ganz dir. Hier ist mal ein solider Syntax- Grundstock, mit dem das zu realisieren sein sollte

Ich hoffe ich konnte bissen helfen- für weitere Fragen stehe ich gerne zur Verfügung und auf eine RM obs geklappt hat freue ich mich natürlich...

mfg Stups

Überarbeitet- siehe unten...

Hallo,

beschäftige mich schon seit 2 Jahren mit dem LBR.
Ich denke aber, dass hier die allgemeinen Daten gefragt sind wie Beschleunigung, Geschwindigkeit, Wege usw. Also alles was du für eine genaue Simulation benötigst.
Dazu brauchst du aber auch die genauen Lastdaten und auch das Roboterprogramm usw.
Leider kenne ich kein Tool, dass das 7- Achs Modell des LBRs simulieren kann (offlineprogrammierung&simu).

Welches Datenformat wird den von deiner Software unterstützt?
- Benötigst du auch CAD- Daten?

LG Stups

Hier mal ein paar snippets aus meinem Submit...

;Declarations
decl char progname[50], robint_name[50]
decl int Offset
decl bool dummy, out_cell_angewaehlt


robint_name[] = "CELL"
offset = 0


;Prüfen, ob im Roboterinterpreter "Cell" angewählt ist
if ((varstate("$pro_name1[]") == #initialized) and (StrLen($pro_name1[]) <> 0) and ($PRO_STATE1 <> #P_FREE)) then
	ON_ERROR_PROCEED
	dummy = StrComp($pro_name1[], robint_name[], #NOT_CASE_SENS)
	if $err.number == 0 then
		if dummy == true then
			out_cell_angewaehlt = TRUE
		else
			out_cell_angewaehlt = FALSE
		endif
	else
		err_clear($err)
	endif
else
	out_cell_angewaehlt = FALSE
endif




;Roboterinterpreter abwählen
strclear = strClear(progname[])
swrite(progname[], stat, offset, "CANCEL /R1/%s()",$Pro_NAME1[])
cwrite($cmd, stat, mode, progname[])



;Cell Anwählen
strclear = strClear(progname[])
progname[] = "RUN /R1/cell()"
cwrite($cmd, stat, mode, progname[])

Natürlich ohne Gewähr

Hallo,

warum soll ein IF im Submit- Loop unzulässig sein?
Habe selbst sehr viele in verwendung.
Der Submit soll ja u.a. eine (kleine)Background- SPS für einfache Logistiken darstellen. Das geht ja ohne IF nicht wirklich oder nur umständlich...

Welche Steuerung bzw. KSS hast du denn?

LG
Stups

nochmal- da ist was schief gegangen beim senden...

für LIN-LIN- bewegung:
$apo.cdis = 20 ;Translatorische distanzkriterium in [mm]; Wenn also der tcp 20mm vor pos1 ist, wird überschliffen und der nächste punkt angefahren
lin pos1 c_dis

für PTP-PTP- bewegung:
$apo.cptp = 50 ; Prozentsatz, wenn die führende achse den überschleif- winkel unterschreitet (standard = 90°, also ab 45° rest wird überschliffen)
ptp pos1 c_ptp

Es gibt noch weitere überschleifkriterien für lin-lin...

Beachte aber, dass auch die letzte position überschliffen wird. also nach abbruchbedingung (hier variable_end) ist der letzte punkt nicht genau angefahren worden.

lg
Stups

Hi,

versuchs mal mit überschleifen.

lin pos1 c_dis

Neee, nicht die mit dem Stern, die mit dem Bogen.

Ich glaube auch zu wissen, dass eh nur wir und die Stern- Fima den Robi als Industriekunden bekommen haben. Wir haben mittlerweile auch schon richtig gute Konditionen.
Wenn du genauere Infos/Dokus über die LBR- Features hast, die nicht veröffenlicht wurden (KUKA- Doku), wäre ich dir seeeehr dankbar. Die rücken nämlich immer nur auf Nachdruck und unter vier Augen mit halbfertigen Dokus raus und übernehmen natürlich auch keinerlei Haftung...

Wir sind ein Industriebetrieb und daher eher auf der Anwender- als Entwicklerseite anzusiedeln. Aber aufgrund dessen, dass diese Vorserie sehr anfällig in der Stabilität der HW/SW ist, habe ich mir gezwungenermaßen schon selbst Spezialwissen aneignen können/müssen.

Gehen deine Ergebnisse direkt in den LBR5 ein? Den 5er- Launch haben sie uns auch schon mehrmals verschoben. Dein Gebiet klingt recht interessant. Werden deine Outputs als KRL- Funktionen zur Verfügung stehen? Denn wir haben mit der jetzt zur Verfügung stehenden Kraftmessung ziehmliche Probleme. Wir "wiegen" jedesmal unser Werkstück vor dem Transportieren. Bei falschen Lastdaten bzw. Schwerpunkten/Trägheiten löst dann immer Trig-By-Contact aus.
Oder wenn du paar nützliche Funktionen hast, würden wir sie auch testen- im Dauerbetrieb sozusagen (Natürlich nur, wenn nix passieren kann )

Was die Offenheit der Funktionen betrifft, bin ich deiner Meinung! Bislang haben wir das immer so gelöst, dass wir unsere Probleme bzw. Erfahrungsberichte an KUKA übermittelt haben. Die haben dann lang rumgespielt und irgendwann kam dann wieder eine neue KSS raus. Oder auch oft Mail- Ping-Pong...

Es soll der LBR ja mal mit JAVA zum programmieren gehen. Hast du in diese Richtung vielleicht schon was rausbekommen? Integration in FRI?

LG

Hallo,

nur mal eine allgemeine Frage: mich würde interessieren, welche Aufgaben du mit dem LBR betreibst? Wir haben selbst 13Stk. im Einsatz.
Ist das eine Forschungsarbeit oder geht das in Richtung Produktion?
Welche Funktionen nützt ihr denn vom LBR? Auch einige "hidden- Features"?

Für Erweiterungen unserer LBR in deren Funktionen habe ich immer ein offenes Ohr.

Wir selbst arbeiten nicht mit dem FRI oder anderen. Nach "Aussen" wird nur mit Profibus kommuniziert, sonst könnte ich dir ev. helfen...

LG
Stups

.

Zitat von elias

Hallo,

ich wuerds mal damit versuchen das ich in der Interruptroutine nach der Berechnung, einen Interrupt ausloese mit einer hoehren Prioritaet. Da ich sowas noch nie gemacht habe, und auch nicht weiss wofuer das gut ist, kann ich Dir nicht sagen ob mein Vorschlag auch wirklich funktioniert. Wobei ich marvins Vorschlag: Das Rueckpositionieren einfach auszuschalten besser finde, wenn Du es an keiner anderen stelle brauchst (wie z.B. NOT-AUS).

Gruss Elias

Hallo,

kannst du mir bitte kurz mitteilen, wie das Rückpositionieren ausschalten funktioniert?

Besten Dank & LG
Stups

Hallo Stethi,

danke- klingt vernünftig.
Leider sind unser Programme so aufgebaut, dass es kein Hauptprogramm gibt, sondern für jede Anlage bzw. für jeden "Teilbefehl" ein Programm. Diese wiederrum haben Bewegungssätze und rufen auch Standardprogramme mit ebenfalls Bewegungssätze auf. Wobei einige Positionen abhängig von der Base gerechnet werden und einige fix im Robcore definiert sind. Somit ist z.B. P1012 nicht immer gleich P1012.
Mit deiner Variante wäre es natürlich elegant zu lösen, nur müsste ich das komplette Roboterprogramm neu aufbauen und die Verschachtelungen bzw. Standardfunktionen neu anpassen. Ebenso wäre der Ablauf in der übergelagerten SPS neu zu implementieren- ebenso die Visu. Das alles mal x für x Roboter, die wir schon am laufen haben. Klingt jetzt ziehmlich nach Jammerei , ist aber wirklich ein enormer Aufwand, noch zudem für jeden Teilbereich andere Leute- auch externe und nicht mehr verfügbare Personen, verantwortlich waren.

Die einfachste Variante ist für mich derzeit noch das mit dem Abspeichern der Achswinkel bei Vorwärtsbewegungen und das Abspeichern des Callstacks bei Rückwärtsbewegungen. Nur leider sind KUKA z.Z. ziehmlich ausgelastet und das mit dem Caller Stack ($PRO_IP) ist für die leider auch noch keine Routine- Übung bzw. höre ich da ein gewisses Dagegen-Sein heraus .

Vielleicht gibts jemanden hier, der mit sowas schon Erfahrung sammeln konnte bzw. weiß, wie man den Callerstack "unfallfrei" beschreiben kann?

thx Stups

Hallo,

danke erstmal für die Antworten!

Uwe: leider funktioniert das Ausmessen des Gewichts am Greifer nicht so, wie es sollte. Da sich bei uns Gewicht und Schwerpunkt der Last ständig ändern, wird es wohl noch ein bisschen dauern, bis ein "grammgenaues" Ausmessen funktionieren wird. Der Bediener sollte dabei auch nur über die Visu eingreifen müssen. Wir haben den LBR schon ausgiebig mit all seinen Möglichkeiten getestet... Sagen wir so- der LBR 4 ist in seiner Gesamtheit für solche Sachen noch zu labil. Der LBR 5 wird das anfang des nächsten Jahres wohl besser machen. Unser Transportgut ist leider extrem teuer, sodass wir mit den (oft nützlichen) Funktionen des LBR in der Produktion noch recht haushalten.

MaBo: das ist sicher eine interessante Variante, leider haben wir in den Anlagen, die wir bestücken, das Problem, dass oft nur ca. 3mm Platzreserve vorhanden ist. Manchmal muss sogar nach so einer Art "Labyrinth" hineingefahren werden- also vor-auf-vor-ab-links-ab-vor... -alles im mm-Bereich. Das ist ja genau das besagte Problem, das ich nach dem Unterbrechen eines Programms genau an der Unterbrechungsstelle fortfahren muss. Das mit dem "klappen" des Robis würde leider auch so nicht funktionieren, da unsere Transportboxen an einer Seite offen sind (nicht die obere Seite :-() und somit das Transportgut leicht herausrutschen könnte.

Stethi: das ist bisjetzt auch die einzige Lösung, die ich mir irgendwie vorstellen könnte. Nur woher weis das Unterprogramm, von welchem "Oberprogramm" es aufgerufen wurde? Leider sind bei uns die Programme recht verschachtelt
Ich spiele noch mit dem Gedanken, den Caller Stack zu beschreiben. Mal sehen was der Robi dann macht. Leider ist das ein Lösungsansatz, von dem jeder Roboterhersteller abrät- aus gutem Grund...

Für weitere Ansätze bin ich sehr dankbar!!!

LG Stups

Hallo Kollegen,

ich bin neu hier- also bitte nicht gleich in die Offensive, sollte ich unbemerkt irgendwelche Reglen brechen

Ich benötige für einen LBR 4+ eine Rückzugstrategie, die es mir (bzw. dem Bediener) nach einem Fehler am Roboter ermöglicht, aus allen Lagen mit dem Robi in eine sichere Home- Position zu gelangen.
Da der Leichbauroboter noch so eine Art Vorserienmodell ist und es oft zu unerklärlichen Ausfällen kommt, die teilweise von KUKA auch nicht erklärt/beseitigt werden können, benötigen wir solch eine Funktion dringend an unseren produktiven Bestückungs- LBRs.

Ich hab schon mal begonnen, die Strategie in zwei Teile zu gliedern:
Teil 1- der Robi ist in der Vorwärtsbewegung zum Werkstück bzw. zur Anlage, die er bestücken soll
Teil 2- Der Robi ist in der Rückwärtsbewegung zu seiner Ausgangspos. (Home usw...)

So- Teil 2 bereitet mir aber Probleme!

Ich muss ab diesem "Point of no Return" das Programm vorwärts abfahren. Da dieses Programm aber bei einem Fehlerfall abgewählt wird, muss ich nach initialisieren der "SaveReturn" Funktion genau an diesem Punkt im Programm/Unterprogramm fortfahren. Das Auslesen des Caller Stacks ($PRO_IP) gibt mir zwar Hinweise, wo das passiert ist, aber leider kann ich diesen Stack nicht beschreiben- dem Roboter sozusagen vorlügen, er habe alle Funktionen bis dahin beretis abgearbeitet und soll einfach hier weitermachen.
Leider müssen die Funktionen oft händisch ab- und wieder angewählt werden, damit es wieder funktioniert. Ist so eine dumme Eigenheit des LBR. Das Bedienpanel ist in unserer Produktionslinie verbaut/versteckt- die Anlagenbediener sollen keinen Zugriff darauf haben. Die SaveReturn- Funktion wird über eine Visualisierung initiiert.

Hat irgendwer eine Idee, wie ich diese Herausforderung am elegantesten löse. Dabei ist zu beachten, das diese Roboter mobil auf einem Shuttle montiert sind und mehrere, verschiedene Anlagen bestücken. Somit ist eine definition eines Arbeitsraumes oder sonstige Auswertungen der kart. Ist/Sollpositionen leider nicht möglich. Des Weitern sollen zukünftige Robis mit der selben Funktion ausgerüstet werden, also keine speziell für einen Anlagentyp programmierte Funktion. Es soll tatsächlich das unterbrochene Programm an der Unterbrechungsstelle fortgesetzt werden. Aus dem Cell- Programm heraus werden derzeit etwa über hundert Unterprogramme aufgerufen, diese wiederrum rufen globale Funktionen auf (z.B. Greifer öffnen, Greifer drehen, Steifigkeitsregler, usw...). Der Greifer am Robi darf auch nicht in einer x-beliebigen Bahn zurück zum Start, denn es fallen sonst die Teile aus dem "Werkstück" heraus. Deshalb das notwendige Fortsetzten des Programms...

Sollten noch einige Details benötigt werden- bitte einfach drauf los fragen!!

Ich bedanke mich schon mal im Voraus für die kreativen Lösungsansätze!!

LG Stups