Änderung DEF_ACC_PTP in Config sinnvoll/problemlos ?

    Hi Leutz,


    kurze Frage:
    Ist es sinnvoll/kritisch in der Config den DEF_ACC_PTP von 50 (Default ?) auf 100 zu setzen ?


    Jemand positive/negativeErfahrungen damit gemacht ?
    ...oder besser Finger weg ?


    Danke schonmal :danke:
    gruß
    rmac

    • Schritt für Schritt zum Roboterprofi!

    Hiho,


    kann verwendet und auch zur Optimierung der Zykluszeit eingesetzt werden.
    Hatte noch kein Programm bei dem es da Probleme gab.


    Gruß
    Thadäus

    Hi Thadäus,


    Danke für die Info.


    Habs heute mal beim Kunden ausprobiert und hat auch ohne Probleme funktioniert.
    Habe gleichzeitig auch noch :


    REAL DEF_ACC_CP=3.0
    REAL DEF_ACC_ORI1=200.0
    REAL DEF_ACC_ORI2=200.0


    gesetzt, aber einen merklichen Geschwindigkeits- bzw. Beschleunigungsschub hab ich
    jetzt nicht festgestellt...


    Hat jedenfalls nicht geschadet... :pfeif:
    Gruß
    rmac

    Hiho,


    kommt auf dein Bewegung an, wieviel du dir an Zeit ersparst.


    Da du jetzt auch schon bei weiteren Parametern angekommen bist, da könntest du noch ein bischen mehr drehen.


    DEF_ACC_CP z.B. bis auf 7.5 rauf und die beiden ORIs schrittweise auch weiter rauf.


    Aber mal ne andere Frage. Was genau willst du damit erreichen? Bessere Zykluszeit? Besseres CP fahren?
    Mit ein bisschen Info kann man dir vielleicht präziser helfen.

    Hi,


    bei diesem Projekt ist das Wichtigste die Zykluszeit,
    wobei die gefahrene CP-Strecke eigenlich nicht sonderlich groß ist, aber
    dafür jede Menge Umorientierungen notwendig sind (Achsen 4-6)


    Bin für Tipps immer dankbar.... :blumen:


    Gruß
    rmac

    Hiho,


    dann würd ich vorschlagen, das du DEF_ACC_ORI1 und DEF_ACC_ORI2 schrittweise hochdrehst. Ich hab das bisher bis 500.0 gemacht, aber auch schonmal höheres gesehen (Bei nem PA).


    Ansonsten könntest du noch die $Filter in 12er Schritten runtersetzen. Sollte schneller werden aber auch ruckeliger.
    Dabei hab ich allerdings keine Erfahrung wie sich das auf die mechanische Belastung auswirkt. Hab das bisher nur in die andere Richtung gedreht.


    Gruß
    Thadäus

    Hallo,
    $filter würde ich auf keinen Fall heruntersetzen. Dieser Wert ist auf den Roboter abgestimmt und beeinflusst relativ stark die Mechanik. Zudem kann die Positionierung länger dauern, was sich wieder negativ auf die Taktzeit auswirkt.
    Aus meiner Sicht würde sich daraus auch ein Garantieproblem ergeben.


    Gruß, robots


    PS: ich vermute die Lastdaten stimmen bei jedem Verfahrbefehl?

    Hi,


    werde mal DEF_ACC_ORI1 und DEF_ACC_ORI2 schrittweise hochdrehen und sehen was passiert.
    $Filter packe ich nicht an.... :jawohl:


    Lastdaten sind eingetragen, allerdings sind Greifer und Teile-Last(en) zusammengefaßt statisch eingetragen,
    d.h. ich unterscheide nicht zwischen Leerfahrt und Fahrt mit Teil.
    Sollte aber kaum einen Unterschied machen weil:


    1. bezogen auf den Zyklus fast keine Leerfahrten gemacht werden (aus Palette holen - bearbeiten - in Palette zurück - nächstes Teil aus Palette ....)


    2. die Teile relativ leicht und kompakt sind (150-250g bei KR15/2)


    Danke für eure Hilfe und Gruß
    rmac

    Hier noch eine Liste von Dingen, die für Zyklusoptimierung gemacht werden sollten. BEVOR an den Maschinendaten herumgeschraubt wird. (Nur für die, die es noch nicht wissen. :zwink:)


    1. Korrekte Maschinendaten verwenden. Die wirklich vorhandenen Lastdaten eintragen. (Auch Zusatzlasten auf z.B. A3 richtig eingeben.) Wenn keine Last vorhanden ist, eine Last von 0 eingeben und nicht -1 stehen lassen.
    2. Sicherstellen dass die Lastdaten auch geladen werden. Es wird oft vergessen die Lastdaten zu laden, wenn nicht mit den INLINE Formularen gearbeitet wird. ($TOOL = TOOL_DATA[1] lädt die Lastdaten nicht!)
    3. Immer PTP verwenden, wenn LIN oder CIRC nicht unbedingt nötig. Dadurch bewegt sich der Roboter viel schneller von A nach B und Umorientierungen sind viel schneller. Eventuell müssen halt mehrere aufeinander folgende PTP Befehle an Stelle einer einzelnen LIN bewegung verwendet werden um Crashes zu verhinden. Doch sehr oft bringt das viel für die Taktzeit.
    4. Wo immer möglich grosszügig überschleiffen! Verwende Trigger, Interrupts PULSE für I/O's oder mach solche Dinge da wo der Roboter sowieso stillstehen muss.


    Also kurz:
    - sicherstellen dass die korrekten Dynamikdaten geladen sind
    - so programmieren dass der roboter keinen Genauhalt/Vorlaufstop zwischen pick und place hat.
    - so bewegen, dass der Roboter möglichst nie linear fährt.

    Hiho,


    bin in guten glauben davon ausgegangen, daß er schon alles vor den Systemvariablen probiert hat, weil er gleich danach gefragt hat. Aber klar, SimeonW hat recht. Da gibts noch ne Menge Maßnahmen davor.


    Gruß
    Thadäus

    Hi,


    alle Punkte auf der Liste von simeonw sind bereits berücksichtigt, bis vielleicht auf die Exaktheit der Lastdaten
    und eine (noch unberücksichtigte) Zusatzlast (= kleine Ventil-Insel) auf A3.
    Das könnte man durchaus noch verbessern.....


    Was die Punkte 3 + 4 angeht, mache ich das allerdings prinzipiell immer so 8)
    und versuche CP-Fahrten zu vermeiden wenn es nicht unbedingt(!) sein muß.
    Bei diesem Projekt kommt es allerdings prinzipbedingt relativ häufig vor,
    da die Konturen der Teile bearbeitet/abgefahren werden müssen.
    Da ist leider nicht viel mit PTP :vergisses:


    Wie in einem vorherigen Posting schon geschrieben, ist die vom TCP zurückgelegt Strecke bei der
    Bearbeitung relativ kurz (abhängig vom Teil so ca. 100-200mm), aber aufgrund der Kontur gibt es
    dabei Umorientierungen bis annähernd 180°.


    Ich werde mal ein bisschen optimieren und wenn ich Zeit habe hier die Ergebnisse posten.


    Zitat von simeonw


    [...] Wenn keine Last vorhanden ist, eine Last von 0 eingeben und nicht -1 stehen lassen.[...]


    Drudge
    Éine Last von 0 (=keine Last) würde doch bedeuten, dass ich den Rob mit der nackten Flansch an A6
    betreibe, was in der Realität wohl kaum jemand machen wird, oder hab ich da was falsch verstanden ? :denk:


    Gruß
    rmac

    Einmal editiert, zuletzt von rmac ()

    Zitat von simeonw


    hehe man weiss ja nie ;) aber ich dachte da vorallem an die zusatzlasten


    ahso, na klar, da hast du natürlich recht..... :beerchug:


    werd mal testen ob das einen Unterschied macht (also 0 oder -1)
    wundert mich nur warum dann nicht defaultmäßig 0 drinsteht


    [Edit:
    habe mal die bas.src und configs durchstöbert und habs jetzt geschnallt :wallbash:


    Wenn die Beschleunigungsanpassung aktiviert ist (d.h. $ADAP_ACC <> #NONE) und die
    Masse der Last < 0 (also z.B. -1, d.h. nicht konfiguriert), dann wird eine robotertypabhängige
    Maximallast (definiert in $robcor.dat) als Standard verwendet, quasi um den "worst case" zu aktivieren.
    Beim KR15 wären das dann eine Handlast von 15kg und eine A3-Zusatzlast von 10kg.
    Logischerweise wird dann bei realen niedrigeren Lasten nicht optimal verfahren.
    ....auweia:
    ]



    Gruß
    rmac

    Einmal editiert, zuletzt von rmac ()

    Hallo zusammen,
    default ist meines Wissens immer die max. Last, sprich die "-1" und das muss auch so sein, da es immer noch viele Anwender gibt, die die Lastdaten überhaupt nicht setzen. Die A3 Last wird in diesem Fall nicht viel bringen, daher besser in die bereits beschrieben Richtung der Erhöhung "Orinetierungswerte" gehen und das sollte mit einem KR15 und dieser geringen Traglast auch ganz gut gehen.


    Gruß, robots

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