Kontinuirliches Schweißen um die Ecke?

  • Hallo zusammen!


    Ich habe folgende Aufgabe bekommen:


    Ich soll mir Methoden überlegen, wie man eine Schweißbewegung "um die Ecke" (im 90° Winkel) am besten programmiert, so dass die Bewegung nicht an der Ecke stehen bleibt, sondern der Schweißbrenner flott um die Ecke gedreht wird und flüssig weiterläuft.


    Bin erst seit 1,5 Wochen dabei mit dem Robi zu arbeiten (bin HiWi :liebe029:) und deshalb bräuchte ich Anfängerfreundliche Tipps ;)



    Habe schon irgendwo gelesen, dass man eventuell mit einem Überschleifen von 0% sowas machen kann?


    ============================================================================


    Bisher habe ich nur zwei Progs geschrieben:


    DEF quadrat()
    INI


    PTP HOME Vel=100% DEFAULT


    PTP {X 1600, Y 200, Z 2300, A 0, B 0, C0}
    PTP {X 1600, Y 200, Z 1900, A 0, B 0, C0}
    PTP {X 1600, Y -200, Z 1900, A 0, B 0, C0}
    PTP {X 1600, Y -200, Z 2300, A 0, B 0, C0}
    PTP {X 1600, Y 200, Z 2300, A 0, B 0, C0}


    PTP HOME Vel=100% DEFAULT


    END


    ==> Werte A-C musste ich auf 0 setzen, da der Robo sonst ständig die Orientierung geändert hätte.
    (Hat teilweise dazu geführt, dass zulässige Soll-Geschwindigkeiten überschritten wurden, was zum Abbruch führte)


    ============================================================================


    Zweites Prog:


    DEF kreis()
    INI


    PTP HOME Vel=100% DEFAULT


    $CIRC_TYPE=#BASE


    PTP P1 Vel=100% PDAT1 Tool[1]:Schweisspistole Base[0]


    ; Kreisbewegung durch 2 Halbkreise:


    CIRC P2 P3 Vel= 2 m/s CPDAT1 Tool[1]:Schweisspistole Base[0]
    CIRC P4 P5 Vel= 2 m/s CPDAT1 Tool[1]:Schweisspistole Base[0]


    PTP HOME Vel=100% DEFAULT


    END


    ============================================================================



    Beide Progs lassen den Robi quasi an einer virtuellen Wand einmal ein Quadrat zeichnen und einmal einen Kreis.


    Fragen:


    - Wie kann ich den Kreis flüssig ausführen lassen ohne einen Stop zwischen den Halbkreisen?
    CONTINUE oder Überschleifen haben nichts gebracht


    - Kann mir jemand kurz und knapp erklären welche Befehle benötigt werden, wenn man neben der Bahn auch die Orientierung des Tools steuern möchte?
    ($ORI_TYPE=#CONSTANT $ORI_TYPE=#VAR $CIRC_TYPE=#BASE $CIRC_TYPE=#PATH...)


    - Funktioniert das Überschleifen überhaupt im Betriebsmodus T1 oder T2?




    Schonmal im Voraus vielen Dank und schönes Wochenende! :blumen:

  • Schritt für Schritt zum Roboterprofi!
  • schau einfach, dass der TCP, also dort wo der Draht rauskommt genau im Mittelpunkt der 6. Achse ist.
    Ne bessere Methode gibts nicht :zwink:

    Menschen brauchen Roboter, aber auch Roboter brauchen Menschen.

    Roboter sichern die Arbeitsplätze und den Fortschritt der Industrieländer, da sie kostengünstig und qualitativ hochwertig produzieren.

    Ohne Automatisierung mit Robotern werden unsere Produkte in Billiglohnländern hergestellt.

    >> Abonniere meinen YouTube Roboterkanal <<

  • Zunächst erst mal solltest du die PTP-Bewegungen in LIN ändern, da beim Mig-Schweissen probleme auftauchen.
    Die PTP-Bewegung guckt nur aus als wäre sie geradlinig - is sie aber nich!


    Wenn du die Punkte mit Inlineformularen erstellt hast - geh auf ändern und wähle in dem
    leeren Feld nach der Punktbezeichnung CONT.


    Ohne dies wirds immer stops geben.


    !!! Base und Tool sind nicht vorgegeben !!!


    Bei der erstellung im Editor: es fehlt das C_PTP
    PTP {X 1600, Y 200, Z 2300, A 0, B 0, C0} C_PTP


    bei LIN siehts dann so aus
    LIN {X 1600, Y 200, Z 2300, A 0, B 0, C0} C_DIS


    Die Überschleifregeln und Einstelloptionen solltest Du dir aus der KUKA-Doku aneignen,
    sonst kommst Du nicht auf die gewünschte Qualität.


    Die Werte A, B und C sollten wegen der Bahngeschwindigkeit NICHT auf 0 gesetzt werden, weil sonst die langsameren Achsen 1, 2 und 3 die ganze Arbeit machen müssen.


    Am besten die Vorrichtung ist so zum Roboter positioniert, das die Achse 5 um 90° Grad angewinkelt ist, wenn der TCP im Quadratmittelpunkt ist, und wie Werner sagt, der TCP auf der Drehachse der A6 ist.
    .... Wird ziehend oder schiebend geschweisst?....


    ACH JA, UND FRAG DEINEN CHEF OB ER WEISS WAS ER VON DIR VERLANGT!

    Einmal editiert, zuletzt von Robotnik ()

  • Hi,


    tut mir leid dir deine Illussionen nehmen zu messen.
    Was du da vorhast geht mathematisch nicht.
    Etweder der Roboter bleibt stehen, oder Du faehrts einen Radius (ueberschleifen)


    Gruss Stefan

  • Soo, nu komm ich auch endlich mal wieder dazu mich zu melden...



    Ja ihr habt da schon recht, ich werde an den Robi gesetzt mit nem Aktenordner in der Hand und dann heißt es "mach mal"...


    Haben sie damals mit dem alten Kuka IR 363/6 mit KRC32 Steuerung mit mir gemacht und nu machen sies mit dem schicken Kuka KR30 L16 und KRC 2 Steuerung... :)
    (Damals als Praktikant, nu als HiWi :D)


    Ich steh hier teilweise wirklich wie ein Ochs vorm Berg, aber et hilft ja nichts.


    Nun zu euch:


    - Jo, PTP ist nicht wirklich linear --> weiß ich. Aber um erstmal die HOME Position anzufahren ist es doch der schnellste Weg oder?
    Ich muss dazu sagen, dass ich im Moment nur den Robi bewege, das Schweißen kommt dann später, wenn oder falls ich mich mit dem Robi genug auskenne. Hier gehts erstmal um die Theorie der Bewegungen, Orientierungen und des Programmierens.


    - Das mit dem CONT habe ich bereits versucht, allerdings ohne weiter etwas zu definieren (C_DIS oder so)
    Allerdings stoppt der Robi zwischen den beiden Halbkreisen immernoch, einen schönen großen Kreis hab ich noch nicht in einem Rutsch hinbekommen. Er meldete mir "Überschleifen nicht möglich"


    - Die Stelle wo der Draht rauskäme scheint in etwa im Zentrum der Achse A6 zu liegen, allerdings (wie es denk ich mal normal ist) unter einem Winkel von etwa 30°.
    Mein Problem ist, dass wenn ich ihm für eine CIRC Bewegung im Inline Verfahren Punkte teache, er mal ohne Umorientierung genau den Kreisbogen nachfährt, wie ich es möchte und ein anderes mal (bei mir 2. Halbkreis) dreht sich plötzlich der Robi um das TCP... Beidemale habe ich die Halbkreise einfach so geteached, dass er erst in der Y-Achse um 100 nach rechts fährt und um 100 (Z-Achse) nach unten --> Hilspunkt
    dann wieder 100 nach unten und nun wieder 100 nach linkst --> Zielpunkt --> Halbkreis...
    Nur durch $CIRC_TYPE=#BASE hat er beide so geteachten Kreise auch wirklich so nachgefahren, wie ich es erwartet hätte. Wenn ich also einen Stift ans Tool kleben würde, könnte ich damit an eine Wand einen Kreis malen :gutidee:
    ==> Nu gehts aber um Schweißbewegung (ob stechend oder schleppend ist jetzt noch unklar)


    - BASE und TOOL nicht vorgegeben? öhm, also bei den geteachten CIRC bewegungen nimmt er doch TOOL[1]: Schweißpistole und BASE[0]
    ==> Versteh ich da was falsch? Muss ich ihm erstmal sagen, welche BASE er nehmen muss?
    Habe heute mal versucht ihm eine neue BASE zu geben (3P-Verfahren) --> Diesmal quasi ein virtueller Tisch in der X-Y Ebene. Habe diese BASE unter Nummer 2 gespeichert und im Programm dann folgendes geschrieben:
    $BASE=BASE_DATA[2] --> Ist das so schonmal richtig?? Muss ich ihm dann auf der rechten Bildschirmseite auch noch das BASE Koordinatensystem geben oder ist das nur fürs Hand-Verfahren?


    - C_PTP und C_DIS: Verstehe ich jetzt so, dass das die Befehle sind, wenn ich ihm manuell Punkte gebe und ihm den Überschleifmodus sagen möchte, richtig? C_DIS meint dann einen festen Abstand C_Vel eine bestimmte Geschwindigkeit?
    --> Irgendwie fehlt mir in der Doku mal eine richtige schöne Programmieranleitung... Von vielen Befehlen wird überhaupt keine Syntax gegeben... Schätze, die wollen, dass man eine Schulung besucht, oder?


    - Werte A, B und C nicht auf 0 setzen? Tja, wenn ich das mache, dann drehen die Achsen 4-6 total durch. Zum Beispiel bei der unteren Kante meines Quadrats, wo er "nur" entlang der Y-Achse konstant fahren soll drehte sich die Achse A4 auf einmal immer schneller rum, was entweder dazu führte, dass der Robi wegen eines Soll-Geschwindigkeitsfehlers an Achse 4 oder wegen eines zu hohen Getriebemoments an Achse 4 gestoppt wurde... Die Werkzeugspitze eierte bei der Bewegung außerdem wie betrunken die Linie entlang... Das Problem mit dem Stop (Soll-Geschwindigkeit) konnte ich nur beheben, indem ich die Linearbewegung an einer anderen Stelle ausgeführt habe, dadurch musste er bei der Bewegung die Achse A4 nicht so schnell drehen, aber erst als ich A-C fest auf 0 gesetzt hatte blieb die Orientierung so konstant wie ich es wollte.


    NEUE PROBLEME:


    Habe mal probiert eine Bewegung zu einem von mir (Im Hauptprogramm) initialisierten Punkt zu schreiben...


    FRAME ist wenn ich das richtig verstehe ein STRUCT, in dem ich einen Punkt in kartesischen Koordinaten speichern kann.
    ( STRUC FRAME REAL X, Y, Z, A, B, C)


    Es klappt vorne und hinten nicht:


    <DECL> FRAME posi
    FRAME posi
    --> Wie deklariere ich eine Positionsvariable?


    posi = {0,0,0,0,0,0}
    posi = {X 0, Y 0, Z 0, A 0, B 0, C 0)
    --> wie weise ich der Variablen dann Werte zu?


    PTP posi
    LIN posi
    --> Wie fahre ich dann diese Position an?


    ==> Ich habe C programmieren gelernt und bin im Moment dabei C++ zu lernen, aber das hilft mir hier nicht weiter...
    Ich bekomme ständig "Unzulässiger oder nicht bekannter Satz"
    Bei C würde ich jetzt meinen, ich hätte vergessen eine Library zu includen, aber ich schätze mal eher in der Config.dat oder sonst wo muss ich was ändern, kann das sein?





    Soooo, wer es tapfer durchgehalten hat meine inkompetenten Fragen bis hier durchzulesen hat sich wahrlich einen KEKS verdient!


    *einentellerkeksebereitstellt*

  • Noch ne Frage:


    Auf der KRC:\R1\System\$config.dat sieht ziemlich mager und leer aus:


    DEFDAT $CONFIG
    BASISTECH GLOBALS
    AUTOEXT GLOBALS
    ARCTECHDIGITAL GLOBALS
    USER GLOBALS
    ENDDAT


    Das ist alles was da drin steht... müssten da nicht noch jede Menge Werte stehen? Globale Variablen? Einstellungen der Geschwindigkeiten, Beschleunigungen, Überschleifen etc. ?


    Kann mir vielleicht jemand eine standard Config.dat hierfür schicken? Ist ja klar, dass der in meinen Programmen keine Variablem des Typs FRAME deklarieren kann, wenn nirgendwo steht, was das ist...
    :hilfe:

  • Ähem ....
    mit welchem Editor hast Du die $config.dat geöffnet.


    Wenn mit dem normalen KUKA-Editor, dann solltest Du die 'Folds öffnen'.
    - Bearbeiten - Folds - alle Folds öffnen -


    Dann sollte da doch so einiges auftauchen. Kann mir nicht vorstellen, dass die
    $config.dat ganz leer ist, da müsste es beim Hochlauf des Roboters
    jede Menge Fehler geben, und kein einziges Programm würde laufen.


    Deklaration Frame im $config.dat, oder jeder anderen .Dat:


    decl frame posi = {X 0, y 0, z 0, a 0, b 0, c 0}


    Zuweisung im Source:


    posi = {X 100, y 100, z 0, a 0, b 0, c 0}
    oder koponentenweise:


    posi.x = 100
    posi.y = 100



    wenn Tool und base gesetzt werden sollen, dann:
    ENTWEDER mit Inline-Formularen
    ODER 'von Hand' eingetragene Befehle verwenden.


    Bei
    $base=base_data[2]
    und einem anschliessenden Inline Bewegungsbefehl gilt das im Inline eingetragene
    Base und Tool, da hilft die Base-Zuweisung vorher gar nichts.


    Hermann

    Einmal editiert, zuletzt von Hermann ()

  • Sooo, hab endlich rausgekriegt, was nicht stimmte...
    Habe nun 2 Werte in der Backward.ini geändert und nun kann ich endlich initialisieren und damit dann auch überschleifen...



    Habe ein Programm geschrieben und die Ausrichtung des Robis ist nun wie bei Robotnik beschrieben.
    So läuft das alles schon viel übersichtlicher ab und die Orientierungsachsen werden entlastet.


    Mein Programm sieht nun vor, dass ein rechter Winkel geschweißt wird (nur die Bewegung, ohne Schweißen, es geht nur um die Theorie)...


    Läuft soweit schon wie ich es möchte...


    Über 4 Punkte habe ich ihm den Weg beschrieben (4x LIN Bewegung)


    LIN1: Robi fährt auf Eckpunkt zu
    LIN2: Robi fährt die letzten 10mm auf den Punkt zu und beginnt dabei das Schweißgerät um 45° zu drehen.
    LIN3: Robi fährt 10mm in die neue Richtung und dreht die restlichen 45°
    LIN4: Robi fährt konstant die zweite Kante entlang



    Kann das Programm grad nicht ausführlicher schreiben, da mein Laptop und der Robi an unterschiedlichen stellen stehen im Moment...


    Das Überschleifen macht mir nun ein wenig Probleme... Ich schleife mit C_DIS bzw. C_VEL


    Die Bewegungen des Robis sind gut und schnell, aber die Orienterungsänderung an der Ecke läuft sehr langsam...
    Beim Schweißen würde er mir also ein Loch in die Ecke brennen. Die Umorientierung läuft fast ausschließlich über die Achse A6 an der die Schweißpistole sitzt...


    Gibts auch so ein $APO.CORI=xxx oder BAS(#VEL_ORI= xxx) ?


    Er dreht die 45° Schritte in einem Male konstant durch aber eben zu langsam und wenn ich den Override höher stelle, sehe ich, dass die Achse A6 sehrwohl schneller kann...

  • Hm, wenn ich das richtig verstehe stellen die meisten Leute dann die DEF_ACC_ORI und DEF_VEL_ORI Werte hoch...


    Mein Problem ist aber glaub ich nicht, dass er nicht schneller drehen kann...
    Ich teste mein Programm auf 30% Override und da dreht der Robi sehr langsam um die Achse A6


    Wenn ich das Prog dann mal mit 100% druchlaufen lasse, dann passiert genau das gleiche... nur halt ALLES schneller.
    Er fährt schneller zum Eckpunkt hin, dreht auch schneller (klar) aber auch dann ist die Drehung wesentlich langsamer als die Translation.


    Ich müsste doch irgendwo sagen können, dass die tatsächliche Bahngeschwindigkeit gehalten werden soll und die dafür notwendigen Orientierungsgeschwindigkeiten gefahren werden müssen.
    --> Wenn er dann meckert, dass damit die Soll-Geschwindigkeit der Achse A6 überschritten wird, dann kann ich mir ja mal Gedanken über die Maximalen Werte machen, aber so glaube ich ist das Problem ein anderes...




    UND WENN DOCH:


    Sowohl in der $machine.dat, als auch in der $config.dat und in der bas.src scheinen ja Vel- bzw. Acc-Werte zu stehen.
    Ich verstehe das im Moment so, dass die Werte in der machine.dat die Maximalwerte sind, die bei geringer Last erlaubt sind. Heißt also schneller kann ich den Robi nicht einstellen als hier hinterlegt ist.
    Werden alle Bewegungen auf diese Max-Werte runtergeregelt oder gibts einen Fehler bei Überschreitung?


    In der config.dat kann ich dann die maximal Geschwindigkeiten einstellen, die mein Programm fahren darf ?!?
    Im Prog geb ich ja über BAS(#VEL_CP= xx) eine Geschwindigkeit an. Das ist dann die Geschwindigkeit, die ich "anfordere" und die die Geschw. aus der config.dat aber nicht überschreiten kann?


    Würde also heißen, ich darf (bei geringer Last --> Nur Schweißpistole) die Werte in der config.dat bis an die Werte aus der machine.dat anpassen und dann läuft der Robi generell schneller?
    Verletze ich damit irgendeine Garantie, wenn ich höhere Werte ausprobiere?



    Danke schonmal für die schnelle Hilfe hier! :grinser043:

  • Noch ne Frage: In manchen Threads steht, man kann einen "Trace aufnehmen", um eine Überlastung auszuschließen oder um die Geschwindigkeitsbegrenzende Achse rauszufinden.


    Wie macht man daaas? :liebe029:

  • Zum vorherigen Post:
    dürfte zwar eine unwissenschaftliche Vorgehensweise sein, aber:
    probier's doch einfach mal aus, und setze die Def_acc_ori-werte einfach mal
    hoch und schau was passiert.
    Von EINEM Versuch wird der Roboter nicht auseinanderbrechen, schon gar nicht
    bei 30%, wenn's funktioniert kannst' Dir immer noch Gedanken um die Garantie
    machen, wenn nicht, dann war's eh für'n A...
    (Ganz im Vertrauen, auch bei 100% wird er nicht zusammenbrechen).


    Das mit dem Trace: Da gibt es eine Oszilloskop-Funktion unter (glaube ich)
    Inbetriebnahme - Service, vielleicht auch in irgend einem anderen Menü, aber
    Oszilloskop heisst es auf alle Fälle. Da kann man Ströme, Nachlauf, Sollwerte
    und weiss nicht was sonst noch alles über eine bestimmte Zeit aufzeichnen.
    Ist in der Doku ganz gut beschrieben.


    Den Sachverhalt mit dem unbedingten Halten der Bahngeschwindigkeit bei sehr kurzen
    Abständen der TCP-Positionen und starker Orientierungsänderung habe ich hier schon
    mal erläutert. Der Roboter begrenzt intern die Orientierungsänderung sehr stark, so
    dass dann die Bahngeschwindigkeit nicht mehr stimmt (das ist halt so, da hilft auch alles
    Theoretisieren nicht). Einzige Abhilfe: siehe oben.


    Hermann

  • Hallo Eagle,
    rein mathematisch ist Deine Aufgabe nicht lösbar. Wenn Du dich entlang der Kante 1 auf die Ecke zubewegst, hast Du eine Vorwärtsgeschwindigkeit in Richtung Kante 1 und keine Geschwindigkeit in Richtung 2, nämlich entlang der Kante 2 nach dem Eckpunkt. Im Eckpunkt springt es um. Dann ist die Geschwindigkeit in Richtung Kante 1 gleich null und in Richtung Kante 2 gleich Sollwert. Daran ändert auch das Absenken der Geschwindigkeit nichts. Und im Augenblick spreche ich nur von der TCP-Bewegung ohne irgendwelche Orientierungen.
    Dies ist weder mathematisch noch physikalisch mit Robotern umsetzbar. Zunächst must Du oder Dein Chef eine lösbare Aufgabe definieren, erst dann machen die Diskussionen im Forum einen Sinn.
    Möglichkeit 1: Verrunden der Ecke mit einer definierten größten Abweichung. (Überschleifen)
    Möglichkeit 2: Scharfe Ecke, dabei wird die Bewegung entlang Kante 1 über den Eckpunkt hinaus verlängert, der Schweißvorgang endet am Eckpunkt mangels Material. Für Kante 2 wird neu angesetzt. (Siehe Video am besten mit dem camtasia player, den kann man punktweise per cursor ablaufen lassen)
    Ich hoffe es hilft.


    Gruß
    Detlef

    RobotWorks<br />CAT Computer Aided Teaching<br />Vom CAD per Mausklick zur Roboterbewegung

  • Also meines erachtens wirst du genau an der Ecke also wenn du 45° zu Ebene 1 stehsts ein Problem bekommen, da meines wissens nach hier eine Achssingularität erreicht wird. Also mal ganz einfach gesagt: nehmen wir mal an du fährst die X Achsen entlang in richtung + ( Ecke ) und musst dann x konstant halten um mit Z ins - zu gehen ( also runter ) wirst du genau an dem Punkt wo x am endwert ist und Z losfährt einen Stop haben. Wir hatten genau so ein Problem mit nem Doppeldrahtbrenner. Unsere Lösung war dann, das Bauteil auf ne 7. Achse zu setzen, und mitzudrehen.


    Was natürlich geht, wäre, es experimentell zu ermitteln, wieviel Zeit dir bleibt um die Ecke zu passieren. Also zu gut deutsch wenn dein Bauteil massiv genug ist, und du an der Ecke nicht durchbrennst hättest du dein Ziel erreicht... Wenn du eine Schweisstromquelle hast, die du variabel steuern kannst ( Fronius o. dgl. ) kannst du natürlich an der Ecke auch einfach den Brenner runterregeln...



    liebe Grüße...

  • Rein Mathematisch, Einstein hatte so wie ich eine 5 darin :bawling:


    Ich bin halt ein Praktiker, und wer behauptet das Seifenblasen immer rund sein müssen hat unrecht! :biggrins:


    Denn wer um eine Blase zusätzliche sechs um ihn herum anordnet, erhält einen Würfel - natürlich nur in der Praxis, nicht in der Mathematik.
    Die Innere Blase wird vollkommen deformiert - ist tatsächlich so!


    Deswegen solltest Du Dich dir mal die Limesfunktionen reinziehen, dann kannst Du das praktisch machbare ermitteln.

  • uiuiui, da hab ich ja mal ne heiße Diskussion in Gang gesetzt...


    Also werde dann mal vorsichtig mit den Def-Werten spielen und gucken, ob ich das erreiche, was ich möchte...
    Das Problem ist schließlich ein Standard-Problem, wenns ums Schweißen geht, aber der Robi ist schließlich unter anderem dafür gebaut.


    Hermann: Danke für die Tipps, ich werde es mal ausprobieren...


    @Detlef: Ich gebe dir Recht, eine 90° Ecke kann nicht flüssig laufen...
    ... aber wie du schon sagst ist Überschleifen hier das Stichwort und ich lasse ihn ja auch überschleifen.
    Ich möchte probieren, ob mit Überschleifen und/oder CIRC-Bewegungen (natürlich sehr kleine Wege) die nötige Mindestgeschwindigkeit fürs Schleifen erreicht werden kann. Ich glaube nicht, dass es unmöglich ist.

  • Habe die Werte in der config.dat geändert auf:


    DEF_VEL_ORI1 =400.0 (MAX)
    DEF_VEL_ORI2 =400.0 (MAX)
    DEF_ACC_ORI1=800.0
    DEF_ACC_ORI2=800.0


    (Die ACC Werte haben nicht mehr soo viel verändert, aber das DEF_VEL hat mich schon ein ganzes Stück, nach vorne gebracht)


    :gutidee: :danke:


    Was mich wundert:
    (Muss dazu sagen: Ich habe einen Punkt gelöscht... fahre die Ecke nun direkt an und gebe in der zweiten Richtung nach 10mm einen Punkt an, um ihm damit zu signalisieren, dass er sich für die Drehung nicht bis zum Endpunkt der Bahn 2 Zeit lassen soll, sondern nach 10mm bereits fertig gedreht haben muss.) :jawohl:


    Wenn ich von LIN auf LIN überschleifen möchte (90°) mit C_DIS, dann beginnt die Umorientierung nicht mit Beginn des Überschleifens (10mm), sondern erst am exakten Eckpunkt... Somit ists kein richtiges Überschleifen, denn er hält an der Ecke an. :down:


    Mit C_VEl = 100 klappts schon ganz gut, der "huscht" zwar noch nicht so schnell um die Ecke, wie er gerade Linien entlangfährt, aber ich denke darauf lässt sich aufbauen.


    Kann ich im Programm nicht explizit sagen, er soll die Orientierungsbewegungen (Achsen 4-6) schnell durchführen aber rein translatorische Bewegungen mit veringerter Geschwindigkeit?
    Quasi VEL_ORI für Achsen 4-6 hoch und VEL_CP für Achsen 1-3 niedrig?
    Dann könnte ich die Orientierungsgeschweindigkeit auf die Bahngeschwindigkeit abstimmen und somit sowohl auf der Geraden, als auch in der Ecke (Kreisbogen mit r=1-10mm) konstant die Bahneschwindigkeit halten.


    @Detlef: Diese Unterbrechung des Schweißvorgangs wie in deinem Video... Ist das Schweißtechnisch wirklich in Ordnung so? Dann könnte man ja ebensogut auch den Schweißvorgang abschalten, 90° Drehen und dann wieder anschalten. Kommt mir ziemlich umständlich vor die Methode, hmmmm :denk:

  • Ich wollte eigentlich nur ein paar generelle Gedanke beisteuern. Wie gesagt, man muß sich einigen, welche Abweichung von einer scharfen, rechtwinkligen Ecke erlaubt ist. (Überschleifen oder nicht)
    Eagle: Schweißtechnisch gesehen ist das die definierte Bewegung, gerade kann jeder Kontroller, bei Umorientierungen weiß mann nie, wielche Geschwindigkeit der TCP tatsächlich hat. Darüber hinaus stellt sich die Frage, wie diese Kontur von Hand geschweißt werden kann? Wahrscheinlich wird da mehrfach abgesetzt.
    Die Bewegung im Video bedarf nur ein paar Mausklicks, ist also gar nicht aufwendig.
    Robotnik: Du irrst, die Seifenblase in der Mitte wird auch in der Theorie (Mathematik/Physik) würfelähnlich.


    Gruß
    Detlef

    RobotWorks<br />CAT Computer Aided Teaching<br />Vom CAD per Mausklick zur Roboterbewegung

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden