Geschwindigkeitsfehler bei kleinem Punktabstand

Das ist abhängig von der Art wie du die Punkte überschleifst!
Ich denke du überschleifst mit "c_dis", das ist Distanz abhängiges Überschleifen, was bedeute das das umorientieren zum nächsten Punkt an einer bestimmten Stelle passiert und dafür muss der Roboter die Geschwindigkeit reduzieren wenn es sich um eine deutliche Richtungsänderung handelt!
Mit $apo.cdis=x kannst du die Distanz in Millimeter zum nächsten Punkt einstellen, an der die Umorientierung stattfindet!
Du kannst aber auch versuchen mit c_vel zu überschleifen, c_vel ist Geschwindigkeits abhängiges Überschleifen und wird mir $apo.cvel=x in % angegeben, d.h. wenn du $apo.cvel=100 nimmst wird die Geschwindigkeit nicht verlangsamt, aber die Bahn wird dadurch extrem ungenau, weil der Roboter schon weit vor erreichen des Punktes auf den nächsten umorientieren muss um die Geschwindigkeit halten zu können, du kannst diesen Effekt aber verringern in dem du mehr Punkte setzt!

Hallo Zusammen,

dieser Thraed ist zwar schon was her, ich greife ihn aber doch noch mal auf weil wir vor einer ähnlichen Frage stehen:

wir verfahren zum Teil sehr komplexe Wege mit einer Vielzahl von Punkten und das Einhalten der Bahngeschwindigkeit ist dabei eine Katastrophe Haben schon fast alles probiert, mit C_DIS gehts fast gar nicht und mit C_VEL ist es auch kein großer Unterschied - auch bei $APO.CVEL=100 ...
Wir haben die Möglichkeit die Anzahl der Punkte zu beeinflussen und sie mal drastisch auf ein echtes Mininum gedrückt - ohne wirklichen Erfolg, wobei die Genauigkeit der Bahn stellenweise nicht mehr tragbar war. :angry:
Bei einer sehr großen Anzahl von Punkten steht das Werkzeug sogar an manchen Stellen - und das bei $APO.CVEL=100

Das ganze Schauspiel findet auf einen KR16 L6 KS mit einer KRC2 statt.

Hat jemand vielleicht noch eine Idde? Kann man das Überschleifen eventuell noch in einer weiteren Variablen beeinflussen, abgesehen von den drei bekannten ... ?!

Sind dankbar für jeden Tipp!!!

MFG

wie gross sind Deine minimalen Punktabstände ?

Typ: spiel mal mit den Beschleunigungs-Variablen ($ACC_MA, ...)

Arbeiten mit Kuka Cam-Rob, die niedrigste Einstellung für das Reduzieren der Punkte betrug soviel ich noch weiß 1,3 mm.

Haste vllt nen Tipp für Werte der Beschleunigungs-Variablen? Nur so nen Richtwert...

wieviele Punkte hast du denn?
Ein Lösung ist Spline, wenn die Pkt.-Anzahl <500 ist.
Wie gross sind denn die Pkt.-Abstände?

ich glaube den kleinsten Abstand kann man gar nicht pauschal sagen... wir verfahren auf einer Kontur mit ständigem Neu-Ausrichten des Roboters. Der wird auch nur extrem langsam wenn eine ständige Neu-Ausrichtung erfolgt, z.B. bei Spitzen auf dem Bauteil.

Die Punkte kommen direkt aus Kuka Cam-Rob. Zuletzt waren es knapp 1400 für eine Strecke von ca. 600 mm. Aber davon fielen wohl annähernd 90% auf eine Strecke von 50 mm, eben an diesen kritischen Stellen. Durch die Einstellmöglichkeiten beim Reduzieren der Punkte kommen wir locker unter 500. Wir benötigen jetzt nicht so die riesige genauigkeit, allerdings sollte der Werkzeeugweg schon erhalten bleiben.

Wie läuft denn das mit einer "Spline"?

MFG

beim Spline kann man Blöcke definieren, innerhalb derer dann die Punkte ohne Geschwindigkeitsreduktion gefahren werden. Verfügbar ist der Spline (allerdings eingeschränkt) ab V5.4. Volle Funktion soll dann in V5.5. enthalten sein. Habe das selbst allerdings noch nicht angeschaut.

Hallole,

Zitat

.. Der wird auch nur extrem langsam wenn eine ständige Neu-Ausrichtung erfolgt, z.B. bei Spitzen auf dem Bauteil...

Das ist doch das alte Problem der grossen Orientierungsänderung bei fast 'stehendem'
TCP. Dabei müssten die Grundachsen seeehr schnellll verfahren, das schaffen sie nicht,
also wird die Geschwindigkeit des TCP reduziert. Abhilfe in engen Grenzen soweit ich
das kenne nur durch Erhöhen der Orientierungsgeschwindigkeiten $acc.ori1, $acc.ori2
und $acc.cp, bzw. def_acc_ori1, def_acc_ori2 und def_acc_cp möglich.

Hermann

Hallo,

C_VEL als Überschleifkriterium und $APO.CVel =100 % ist die beste Vorgabe wenn man ohne Geschwindigkeiteinbruch überschleifen möchte.
Die Einstellung bedeutet, das der Roboter auf eine Überschleifkontur geht, wenn beim Einzelsatz die Bremsrampe beginnen würde und auf dem nächsten Satz dort ankommt wo die Beschleunigungsrampe enden würde.
Wichtig ist dabei die Beschleunigung $ACC.CP. In den Maschinendaten wurden früher $ACC_MA.CP = 4.6m/s² vorgegeben, neuerdings = 10.0m/s². Allerdings wurde der Wert häufig, durch die Einstellung DEF_ACC_CP=2.3 in $config.dat runtergesetzt.

Um mal eine Grössenordnung für Parameter zu geben, ist das Dreiecksprofil auf dem Einzelsatz sinnvoll. Damit ergibt sich z.B. ein Mindestabstand für Punkte wenn man die programmierte Geschwindigkeit erreichen möchte:
Mindestabstand = $VEL.CP²/$ACC.CP

Beispiel: $VEL.CP= 0.3m/s, $ACC.CP=4.6m/s² ==> Mindestabstand rund 20mm

Anderrum kann man natürlich auch eine Beschleunigung ausrechnen wenn man Abstand und Geschwindigkeit hat. Das Ganze hat natürlich auch Grenzen. Wenn man die Beschleunigung zu hoch setzt wird der Roboter mit Überwachungen aussteigen, bzw. sehr unruhig werden.

Das Ganze ist aber nur eine Abschätzung. Geschwindigkeitsreduzierungen wegen Zusatzachsen, Orientierung oder Winkel der Bahnen zueinander sind aussen vor, dürften aber bei CamRob Applikationen auch keine Rolle spielen.

Gruss DiDi

Hallo Zusammen,

erstmal vielen Dank für die vielen Ratschläge!

Die Einstellung CVEL=100% haben wir übernommen und die Beschleunigungsfaktoren mal angepasst:
$ACC.CP=10
$ACC.ORI1=1000
$ACC.ORI2=1000
$ACC_MA.CP=10
$ACC_MA.ORI1=1000
$ACC_MA.ORI2=1000
das Ganze auch in der config.dat (wir ich NIEMALS draufgekommen !!!!).

Die Bewegungen sind auch schon viel flüssiger geworden, noch nicht ganz der Hit, denke aber wir können mit arbeiten.

Haben also mal das erst übersetzte Programm aus Kuka Cam-Rob eingeladen und abfahren lassen. Soweit so gut, nun ist aber irgendwas passiert:
Die Geschwindigkeit hat sich rapide verringert! Sind vorher (auch bei den von Hand programmierten Programmen) immer mit $CP.VEL=0.01 vefahren - das entspricht ja 10 mm/s. Doch plötzlich ist diese Geschwindigkeit viel geringer geworden, und das in allen Programmen! Man sieht kaum noch das der Roboter sich bewegt. Woran kann das liegen? Hat das Programm aus Cam-Rob irgendeine Einstellung verändert, die für ALLE Programme gilt? Müssen inzwischen mit mindestens 0,1 verfahren, also Faktor 10!!! Jemand eine Idde?

MFG

Keiner eine Idee welche DEFAULT-Einstellung dafür verantwortlich ist?

Hallo,
die Werte werden beim Aufruf von INI mit den Default-Werten überschrieben.
Siehe BAS.SRC, z.Bsp.:

$ACC.CP=DEF_ACC_CP

oder auch def_acc_ori1, def_acc_ori2 .... am besten einfach mal
selber die Datei BAS.SRC durchforsten.

Ob das Ini bei den CamRob-Programmen aufgerufen wird weiss ich nicht,
lässt sich ja wohl aber einfach feststellen.

Hermann

Hallo Hermann!

Es erfolgt ein Aufruf der Ini:

Zu Beginn des Programms "BAS (#INITMOV,0 )" und vor jeder PTP-Fahrt "BAS (#PTP_PARAMS,50)" (wobei hier die 50 wohl für 50% von max. entspricht). Aber ich verstehe nicht warum auf einmal die Geschwindigkeit so im Keller ist - und das mit Auswirkungen auf alle Programme - wie gesagt mindestens Faktor 10. Konnte denn das Programm aus CamRob die Default-Werte überschreiben?

MFG

Hallo, ich hab ne kleine Frage zu der Splinefunktion in der V5.5. Ich muss Dichtmittel auftragen, hierzu werden viele Kreisbahnen angefahren! Bleibt bei der Splinefunktion die Geschwindigkeit immergleich, so dass immer gleich viel Dichtmittel aufgetragen wird??
Gruß Sebastian

Nummer_5
schau mal bitte nach flg. Werten während der Programmausführung:

$ov_rob, $acc_c, $vel_c und $red_vel

Nummer_5
Habe gerade mit jemandem von der FH Gelsenkirchen/Bocholt gesprochen, der hat genau das gleiche Problem, Zufall?
Auch er hat gesagt, dass Prog. (welche vorm CAMRob-Einsatz mit gewünschter Geschw. liefen) nach dem CAMRob Einsatz nicht mehr mit der gleichen Geschw. liefen.
Allerdings ist in der Diskussion rausgekommen, dass er nur wenige Punkte ausprobiert hat und ich dann vermutet habe, das die Programmierte Geschwindigkeit noch nicht durch den Vorlauf aktiv war und somit mit der letzten (zu geringen CAMRob-Geschw.) gefahren wurde.
Können da Zusammenhänge bestehen?

Hallo LindePaul,

ja ja, so klein ist die Welt... Habe den Thraed hier vor ein paar Tagen begonnen bzw. wieder aufgegriffen. In der Zwischenzeit haben aber meine zwei Kollegen, die sich ebenfalls mit dem Thema auseinandersetzten, hier weitergemacht. Wir "teilen" uns sozusagen den Benutzer da wir immer zusammen an den Roboterprojekten arbeiten. Und auf ihren letzten Beitrag hin haben sie mich mal angesprochen - ist ja echt ein Ding!

Haben jetzt einiges an Infos hier und am Telefon gesammelt und werden das mal alles nachher direkt vor Ort überprüfen - müssen leider immer ein Stück fahren bis zum Roboter ... geben aber eben bescheid was sich so getan hat.

MFG

T.Schulz

@Glöckler (Spline)

beim Spline gibt es keine „algorithmus“-bedingte Geschwindigkeitsabsenkung wie bei den herkömmlichen LIN und CIRC-Bewegungen.
Wenn also die programmierten Werte (Beschleunigung und Ruck) eingehalten werden können, bleibt die Geschwindigkeit konstant.
Wenn z.B. um eine scharfe Ecke gefahren wird oder eine große Umorientierung zu fahren ist, wird natürlich die Geschwindigkeit entsprechend reduziert.
Neu beim Spline ist auch, dass nicht nur die Beschleunigung (und Ruck) entlang der Bahn berücksichtigt wird, sondern auch senkrecht dazu. Das führt u.a. dazu, dass bei Kreisen die Geschwindigkeit auch durch die Zentrifugalbeschleunigung begrenzt werden kann.