Beiträge von Stups

Hi,

Hier mal ein alternativer Lösungsvorschlag:
Ich hatte mal die Herausforderung, das ich für mehrere Systeme, die schon in Betrieb waren, eine solche Strategie nachträglich implementieren musste.
Dabei war das mit der Variable wie oben beschrieben nicht mehr möglich, da die System zu komplex und zu verschieden aufgebaut waren. Ich bin dann auf eine Lösung gekommen, die bei allen Systeme gleich funktionierte und als einfache copy/paste übertragen wurde. Mann muss dabei auch nicht den Ablaufcode angreifen. Das Ding werkelt im Hintergrund.

Kurz und Bündig: Die Bahn des Roboters im Hintergrund durch Interrupt gesteuert aufzeichnen. Bei Fehlerfall die Bahn bis zum Ausgangspunkt rückwärts abfahren.

Im Anhang ein Dokument mit einer Niederschrift dazu.
ist etwas kompliziert zu lesen aber die Idee kann man schon in etwa raus finden.

hoffe, ich konnte helfen.

LG
Stups

Ok verstehe- du verwendest die originale cell von KUKA;

Dieses CHECK_HOME ist, so wie ich es verstanden habe, nur ein Vorschlag:

Wenn der User diese Variable auf Wunsch bzw. je nach Anwendung auf TRUE setzt, wird im P00 die Home- Position geprüft. Bei CHECK_HOME = FALSE wird die Home- Position nicht ausgewertet.
Diese Variable ist in der config.dat standardmäßig auf TRUE. Dort einfach auf FALSE und der Check wird nicht mehr ausgeführt. Oder aber einfach den Absatz löschen im cell.
Aber Achtung vor einem Crash bei direkter Home- Fahrt

Willst du den Check trotzdem ausführen, musst du

A) in der P00 im CHK_HOME() die Zeile IF ($IN_HOME==FALSE) THEN... einfach um die gewünschten HOMEs erweitern ODER

B) in der cell so wie ich oben beschrieben habe die HOMEs direkt abfragen: IF (($in_Home == TRUE) OR ($in_home1 == TRUE) OR ... ) THEN

Zu (A) würde ich abraten! Das ist wieder eine Standard- KUKA Routine, die bei einem Update überschrieben werden kann bzw. die Änderungen ungeahnte Auswirkungen haben können

Wir haben das komplett gelöscht und eine eigene Rückzugstrategie entwickelt...

LG

Hallo,

wo wird denn die Home abgefragt im cell bei dir? Mach mall nen Screenshot.

Dort erweitern, so etwa:

(($in_Home == TRUE) OR ($in_home1 == TRUE))

LG
Stups

Hallo nochmal,

Ok, wenns Baulich nicht anders möglich ist, brauchst wohl eine Mehrsensor- Vermessung.

Die Auswerteeinheit ergibt sich automatisch mit den Anforderungen:

Wenn es zeitlich erforderlich ist, würde ich einen PC nehmen, an dem entsprechende Hardware angebunden oder eingebaut ist. Z.B. Karten oder USB- Geräte von National Instruments- die haben gewünschte Abtastfrequenzen für Messaufgaben. Kostet halt auch ein Bisschen. Software- Varianten gibt es da dann genügend...

Wenn es eine SPS zulässt, kann man auch diese verwenden. Eine SPS ist halt nicht für hochfrequente Messaufgaben gedacht- bzw. benötigst du entsprechende Komponenten. Dann wird's halt auch wieder teuer...

Rein vom Programmierkomfort und den Live- Visualisierungs- Möglichkeiten würd ich einen Rechner mit entsprechender HW vorschlagen...

Zu den Sensoren:

Wenn du schon so viele hast, sind diese doch sicher fest montiert und du bekommst ja von jedem einen absoluten Abstand. Damit ergibt sich normalerweise auch schon die Kontur und Lage/Position der Werkstückes? Dann wie oben einen Abgleich mit den Soll- Werten und daraus die Offset- Werte- oder so...

LG
Stups

Hallo,

ich würde EINEN Laser- Sensor am Roboter vorschlagen. Dann mit Suchfahrt z.B. einmal von Links und einmal von Oben. Der Sensor geht auf eine Auswerteeinheit und liefert werte im 1/1000mm Bereich. Addiert mit der Robotertoleranz bzw. Bahn- Untreue musst du halt selbst herausmitteln, wieweit du in deiner Spec liegst. Du hast ja die Soll- Bauteilmaße und kannst dann das Gefundene somit überlagern. Dadurch hast du die Offset- Position (XYZ/ABC), die du dem Robi mitteilst.

LG
Stups

Hi,

Wenn du die Werte einzeln zuweisen willst, musst du auch $ACT_TOOl dem richtigen Tool zuweisen ebenso wie die $Load- Werte- aber mit BAS(#TOOL,2) wird das alles automatisch gemacht- so wie schon BastelNerd erwähnt hat.

z.B.:
$ACT_TOOL = 2 ;Diesen Befehl zum Schluss dann erst wird das Werkzeug gesetzt
$LOAD.M = [Gewicht/Masse]
oder
$LOAD = LOAD_DATA[2] ;für den gesamten Lastdatensatz

In deinem Fall würde das dann für Werkzeug 2 am einfachsten so aussehen:

$TOOL = TOOL_DATA[2] ;Koordinaten TCP
$LOAD = LOAD_DATA[2] ;Koordinaten und Daten Last
$ACT_TOOL = 2 ;Werkzeug aktivieren/setzen

LG
Stups

Hallo,

siehe oben...
Dort sollte sie zu finden sein- auch noch mit ein paar anderen Files.

Kannst aber auch mal in dem Verzeichnis nachsehen, von dem du die KSS installiert hast:
\\KRC1_CD\INTERNAT\KRCSETUP\KRC\ROBOTER\DLRRC\cfg\

Dort sind auch alle Files drin...

LG

Hi,

die von dir beschriebene Datei kenne ich nicht- aber es gibt ein JntPara41.dat, in dieser sind die Reglerparameter der Achsen für den Positionsregler eingetragen. Anbei mal diese Datei- auch aus der v5.6.5. Vergleich die mal mit deiner.

Verzeichnis ist ..\\KRC\ROBOTER\DLRRC\cfg\

LG
Stups

PS:

Doku gibt es meines Wissens nicht für die bas.src.

Aber wenn du die mal öffnest, siehst du gleich die Switch-Case Anweisung mit den möglichen Commands. Sind bei der KR C2/C3 nicht so viele (17).
Dann musst du halt bisschen in den Unterprogrammen suchen. Ist- von den hunderten IFs mal abgesehen- auch recht gut aufgebaut

Vielleicht hat ja jemand hier im Forum sich die Mühe angetan, die Befehle herauszulösen und eine Doku zu schreiben

KR C4 kenn ich mich leider nix aus

LG

Hallo,

Folds sind eigentlich nur Hilfswerkzeuge, um zusammengehörigen Programmcode übersichtlicher zu verschachteln. So werden lange Programme übersichtlicher und Zusammengehörendes eben erkennbar.

PDAT_ACT ist ein Datensatz, der eigentlich via Programmieren im Inline- Format vom System generiert/verwendet wird (deshalb der Fold an dieser Stelle, damit das System den Inline- Befehl erkennt- vordefinierter Aufbau). Das hat die Vorteile, dass du mit dem BAS- Befehl alle Parameter in einem vereint hast. Diese werden dann im BAS.scr nach ein paar Überprüfungen und Verknüpfungen ebenfalls via $APO.CPTP und den anderen Variablen zugewiesen.

Es macht programmtechnisch für dich jetzt keinen Unterschied. Eben sowenig ob in oder außerhalb von Folds...

LG
Stups

Wenn du den richtigen Ansprechpartner hast, geht das recht unkompliziert über FTP...

Die sind da auch recht aufgeschlossen wenn man gemeinsam schon recht viele Probleme gelöst hat

Die ist etwas älter- da hat sich schon einiges getan

Die aktuelle und wahrscheinlich auch letzte Version ist die 5.6 V6:

Software ist die aktuelle die v5.6.5

LG

Nachtrag:

Der Befehl DesiredForce gilt natürlich auch für die Rotationen <A,B,C> nicht nur für <X,Y,Z>

Ist aber in der Doku beschrieben...

LG

Hi,

ja es gibt in der Tat noch viele Features, die nicht im HB beschrieben sind. Diese werden aber als "Hidden Features" ausgewiesen, da sie nicht ausreichend getestet wurden usw. und somit offiziell nicht für den Endanwender zur Verfügung stehen...

Das andere kann ich dir leider auf die schnelle nicht beantworten. Da müsste man sich ein bisschen Zeit nehmen. Aber beim Herumprobieren sollte es eigentlich zu schaffen sein...

Was die Befehle angeht, würde ich mich an KUKA wenden bzw. da mal nachsehen: http://kuka-labs-forum.com/

LG

Ach ja nochwas-

Normal macht man Änderungen bzw. automatische Programmabläufe in den anderen Reglern- aber auf keinen Fall im GravComp- Modus. Den sollte man nur manuell verwenden für Techingaufgaben und ähnlichen Dingen... Danach sofort wieder zurück in den Positionsregler!

LG

Bitteschön!

Welche KSS- Version hast du?
Abweichung zu was? Wenn der TCP abweicht sollte es egal sein...
Illegal State sagt aus, das die Lastdaten nicht stimmen. Der TCP hat normal keinen Einfluss auf die Berechnung der Lastdaten- er ist nur führ die Bahnberechnungen und Positionierung nötig.

Es gibt die Möglichkeit, die Lastdaten vom Roboter automatisch ermitteln zu lassen. Ich hab das auch schon versucht und es funktioniert- wenn es funktioniert- recht gut

Die Funktion heißt LOADIDENT und ist ein undokumentiertes Feature beim LBR 4+.

Die Lastdaten eines unbekannten Tools (momentan Masse und Schwerpunkt) können mit dieser Funktion aus den Robotermesswerten ermittelt werden. Dazu sind mehrere Messungen in verschiedenen Roboterposen nötig. Zum Zeitpunkt des Aufrufs mit dem Softkey LoadIdentStart sollte der Roboter ruhig stehen. Bei der ersten Messung wird der interne Zustand zurückgesetzt, darauffolgende Aufrufe mit LoadIdentNext in anderen Posen verbessern das Ergebnis sukzessive. Die Softkeys sollten links unten in den DLRRC- Funktionen zu finden sein...

Die Funktion gibt nach jedem Aufruf die ermittelte Masse, den Schwerpunkt und eine Aussage über die Güte der Messung zurück. Dies erfolgt im folgenden Format, die Werte sind unten näher erläutert:
LoadIdent good 1 num Exp 15 condition 2.677171
LoadIdentMass 3.583514 cm X 2.103062 Y 0.628391 Z 140.1607

Bedeutung:
Lastschätzung zuverlässig = 1, sonst 0
Anzahl der gemachten Messungen (1-15)
Masse in kg
Schwerpunkt x in mm
Schwerpunkt y in mm
Schwerpunkt z in mm
Konditonierung => Güte der Messung

Der Aufruf blockiert, bis die Berechnung abgeschlossen ist. Die Konditionierung gibt die Güte der Parameteranregung an und sollte möglichst klein (nahe bei 1) sein. Werte unter 10 ergeben bereits eine sehr gute Schätzung der identifizierten Last. Unabhängig von der Konditionierung kann die Güte der Messung weiter verbessert werden, wenn von allen Roboterposen zwei Messungen gemacht werden, die positionsgeregelt aus unterschiedlichen Richtungen angefahren werden. Dadurch können Hysterese-Fehler der Drehmomentmessung durch die Abtriebslager-Reibung minimiert werden.

Nach der 15. Messung die Werte in die Lastdaten deines Werkzeuges eintragen. Wenn alles geklappt hat sollte im GravComp der Roboter ruhig stehen und auch die Meldung IllegalState verschwinden. Wenn die Meldung nicht verschwindet- im Positionsregler mit Hand ein bisschen verfahren- dann sollte sie endgültig weg sein...

Mann kann diese Messung auch aus dem Programm heraus automatisch mit den PAPAS bzw. DLRRC- Kommandos machen- da würd ich aber mal abraten, wenn man es nur einmalig zu ermitteln hat...

Alle Angaben natürlich ohne Anspruch auf Vollständigkeit und Richtigkeit! :angel:

Für weitere Fragen und Anregungen stehe ich natürlich gerne zur Verfügung!

LG
Stups

Hallo,

hast du den Vektor geprüft oder ist das nur eine Vermutung?

Als aller erstes sollten mal deine Greiferdaten (Lastdaten) richtig sein. Das kannst du beim LBR leicht mit der Gravitationskompensation überprüfen. Wenn der Roboter dann still hält und sich leicht bewegen lässt, sind die Daten richtig. Aber Vorsicht- bei älteren KSS- Versionen kann es passieren, dass dir der Roboter bei falschen Lastdaten abhaut- so wie du beschrieben hast. Da kann man schon einiges kaputtmachen- im schlimmsten Fall auch verletzt werden!!!
Bei den aktuellen Versionen lässt er dich gar nicht umschalten wenns nicht passt bzw. nur in der viskosen Betriebsart...

Dann kannst du noch prüfen, ob im Betrieb/Programm auch wirklich das richtige Werkzeug mit den entsprechenden Lastdaten aktiv ist- nicht aus Versehen ein Anderes.

Mit den Standardwerten wie du sie im Anhang hast, sollte der Arm eigentlich keine großen Sprünge machen- außer das Gewicht ist komplett in der Seite. Hast du den Regler auch wirklich mit diesen Daten versorgt??

hier ein Bsp:

defaultstiff =$stiffness      ;einmalige vorbelegung
defaultstiff.strategy =20
defaultstiff.frametype =#Base
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}


$stiffness=userstiff

Sonst schick mal den Code und ich sehe mal drüber....

LG
Stups

Hi,

Hier Angaben zur KR C2 bzw. KR C3:

zum Überschleifen muss in erster Linie der Rechnervorlauf eingeschalten sein ($Advance >=1).
In Interrupt- Unterprogrammen ist kein Rechnervorlauf möglich.

Des Weiteren sind für LIN-PTP und PTP-LIN besondere Befehlsfolgen notwendig- siehe angehängte Doku.

mfg Stups

Das hier könnte dir auf längere Sicht helfen:

www.kuka-labs-forum.com

Die können dir sicher in deinem Projektverlauf helfen...

mfg Stups

jup- meite ich ja

Aber wenn die Positionen wieder umgeteacht werden musst du sie wieder manuell nach/umtragen.
Da würd ich im cell oben oder in der sps.sub die werte automatisch überschreiben bei Änderung- so wie ich oben beschrieben habe...

lg