Überschleifen nicht möglich

  • Hallo,


    wer von den Kuka Spezialisten kann mir sagen warum bei diesem PTP XHome_Pal2 das
    Überschleifen nicht funktioniert?
    Habe sogar noch extra dieses C_DIS angegeben, macht aber keinen Unterschied ob mit oder ohne. APO_DIST wurde auch schon mit kleineren Werten (10, 30) versucht.


    Code
    DECL PDAT PPDAT7={VEL 100.0,ACC 100.0,APO_DIST 100.0}


  • Schritt für Schritt zum Roboterprofi!
  • Servus


    Wundert mich eigentlich das er das C_DIS nicht als Syntaxfehler anzeigt den das gilt meines wissen nur für LIN Bewegungen.


    Aber das ist eh fürn Arsch:


    Code
    continue
    Teil_nicht_erkannt = false
    continue
    durchlauf=1
    continue
    Kam_Versatz=$Nullframe
    versuch2:


    Die continue kannst du ersatzlos streichen. Ich habe damit schon mehrere Tests gemacht das macht nur bei WAIT FOR Sinn den da setzt er sonst einen Vorlaufstop.
    Ich denke was dir fehlt ist das $APO.CPTP=100 verschleifen um 100%


    Gruß
    Bastian


  • Das Umschalten auf andere Tool- und Basedaten stoppt den Roboter!
    Hier von Tool 1 auf Tool 2

    Gruß<br />Markus


  • Das Umschalten auf andere Tool- und Basedaten stoppt den Roboter!
    Hier von Tool 1 auf Tool 2


    Das gilt nur für KRC32 ! Dort gibt es in der $Config.dat die Vars VL_STOP_TOOL und VL_STOP_BASE, die standardmäßig auf true stehen.


    afaik löst bei KRC1 und KRC2 das Umschalten von $TOOL oder $BASE keinen Vorlaufstop mehr aus.


    Leider hat markz aber nicht angegeben, welche Steuerung und welchen Softwarestand er einsetzt.

  • Hallo,


    finde es super das sich an meinem "Problem" so viele beteiligen.


    Also zur Hardware: ist ein KRC1 mit Soft v4.1.5 auf dem das besagte Problem besteht. Auf dem anderen Kuka (KRC2 mit v4.1.7) funktioniert das überschleifen an der genannten Stelle. Vielleicht hilft diese Info noch weiter.


    Diese continue's wurden von mir nur zu Testzwecken eingefügt, weil ich auch nicht mehr anders weiter wusste.


    Gruß Markus

  • Hallo markz,


    dann wollen wir uns doch mal näher deinem "Problem" widmen:


    Im wesentlichen gibt es zwei Gründe warum die Steuerung nicht überschleift obwohl es programmiert ist:



      • Aus Zeitgründen: Die Steuerung muss den Überschleifsatz, also das Verbindungsstück zwischen den beiden Sätzen, fertig geplant haben bis spätestens zu dem Zeitpunkt an dem dein Überschleifkriterium vorgibt, dass die Bahn zum Genauhalt verlassen werden muss.

      • Nicht Überschleiffähige Anweisung: Du hast irgendeine Anweisung (z.B. Vorlaufstopp) programmiert die das Fahren auf Genauhalt erfordert.


    Nachdem es an der anderen Steuerung funktioniert würde ich erstmal davon ausgehen, dass ersteres passiert. Um das zu überprüfen kannst du vielleicht mal in T2 deine Applikation abfahren. Soweit mir bekannt werden manche "Überschleifen nicht möglich" Meldungen in Automatik nicht ausgegeben. Falls es das in der V4.1 schon gab kannst du auch die Variable $STOPNOAPROX auf true setzen, dann kommen die Meldungen auch in Automatik.


    Falls dann eine Meldung rauskommt schreib dir mal die Meldungsnummer auf und poste sie hier, dann kann man vielleicht wieder etwas mehr sagen.


    Gruß
    Fubini

    Einmal editiert, zuletzt von fubini ()

  • Hallo fubini,


    das mit dem $STOPNOAPOX habe ich bereits gemacht. Er zeigt definitiv an
    "1123 - Überschleifen nicht möglich". $ADVANCE ist im übrigen immer 3.
    Das aktuelle Programm sieht wie folgt aus (das steht da auch wirklich so am Stück):


  • Hallo markz,


    ist $STOPNOAPPROX=true und es kommt trotzdem nur die Meldung 1123 (und nicht 1155 oder 1442 zusätzlich!) heißt das meines Wissens definitiv, das aus Zeitgründen nicht überschliffen werden kann.


    Nachdem die KRC1 noch einen langsameren Prozessor hatte als die KRC2 kann ich mir das auch gut vorstellen. Fahr doch mal den Bewegungssatz langsamer ab. Klappt es dann passt das auch zu der Theorie.


    Gruß
    Fubini

  • Das hab ich in der KUKA-Doku gefunden:


    Das CP--PTP--Überschleifen kann allerdings nur garantiert werden, wenn keine der Roboterachsen
    imBahnsatzmehr als 180_ dreht und der Status S nicht wechselt, da dieseStellungsänderungen
    bei der Planung der Überschleifkontur nicht vorhersehbar sind. Tritt ein
    solcher Konfigurationswechsel im Bahnsatz vor dem Überschleifen auf (Änderung von S
    oder T), wird der Bahnsatz wie ein Einzelsatz zum programmierten Zielpunkt zu Ende gefahren
    und die quittierbare Fehlermeldung “Überschleifen CP/PTP nicht durchführbar”
    ausgegeben. Der Anwender sollte dann den CP--Satz inmehrere Einzelsätze zerlegen, so
    daß der Einzelsatz vor dem CP--PTP--Überschleifen hinreichend kurz ist, um einenWechsel
    von S oder T in allen Roboterachsen ausschließen zu können.

  • Hallo markz,


    es gäbe da auch noch die Möglichkeit, das Überschleifen nicht möglich ist auf Grund einer Momentenüberschreitung in der Überschleifbewegung. Nachdem der Überschleifsatz selbst ein PTP ist könnte man daher noch probieren die Achsbeschleunigungen und -geschwindigkeiten zu reduzieren. Nachdem diese Meldung sich bereits während der Planung ergibt (wo der Override noch nicht berücksichtigt ist), nützt es da nichts nur $OV_PRO zu reduzieren.
    Ich dachte aber bisher, dass das auch mit einer entsprechenden Meldung angezeigt wird. Vielleicht war es aber in der V4.1 noch nicht so. Hast du es an der KRC2 Version der V4.1 auch mit dem gleichen Robotertyp und den gleichen Maschinendaten ausprobiert? Falls nicht könnten da noch Unterschiede im Dynamikmodel sein, so dass es bei der KRC1 zuschlägt und bei der KRC2 nicht.


    Gruß
    Fubini

  • Hallo markz,


    ich hab mich mal noch bei einem Kollegen schlau gemacht und dabei kam die Frage auf ob dein Roboter absolutgenau ist. Falls dann TOOL[1] und TOOL[2] unterschieliche Lastdaten haben ist tatsächlich überschleifen nicht möglich. Das entspricht dann dem Fall Überschleifen nicht möglich wegen unzulässiger Anweisungsfolge. Die notwendige Meldung gab es aber in der V4.1 noch nicht, so das du trotz STOPNOAPROX nicht unterscheiden kannst ob es nicht möglich ist wegen Zeitgründen oder der Anweisungsfolge.


    Auch gab es in der V4.1 mal einen Fehler, der beim beschreiben des $OUT im TRIGGER irrtümlicherweise Vorlaufstopp ausgelöst hat. Falls obiges nicht der Fall ist kannst du ja mal die Trigger rausnehmen und es noch mal probieren.


    Gruß
    Fubini

  • Hallo,


    Lastwechsel im Überschleif ging soweit ich weiss noch nie. Es gibt wahrscheinlich auch kaum praktische Anwendungen. Da müsste ja im Überschleif etwas abgeworfen oder aufgefangen werden. Das wird wohl selten der Fall sein.


    Gruss DiDi

  • Danke für die nützlichen Tipps. Die Info mit den Lastdaten war sehr gut.


    Diese waren in der Tat unterschiedlich zwischen Tool 1 und 2. Die besagte Meldung "Überschleifen nicht möglich" kommt nun nicht mehr. Bin allerdings mit dem Überschleifweg noch nicht so ganz zufrieden, der ist wirklich nicht besonders groß, obwohl APO_DIST=100 im PDAT7 ist. Habe auch mal extra $APO.CDIS=30 davor gesetzt. Das ganze hat sich aber optisch nicht verändert.


    Gruß Markus

  • Hallo Markus,


    im Bezug auf die Überschleifradien und $APO.CDIS: Wo genau hast du dese Anweisung hingeschrieben? Es ist nämlich so, das der CDIS Anteil das Überschleifkriterium des Neusatzes (das ist bei dir der LIN P_Kamera) verwendet. Falls dort etwas anderes programmiert ist. kommt das zur Ausführung.


    Kurz gesagt: Wie in einen Bewegungssatz hineinüberschliffen werden soll bestimmt immer das Überschleifkriterium des Satzes in den hineinüberschliffen werden soll.


    Steht die $APO.CIS Auswertung vor dem Altsatz (das ist dein PTP XHome_Pal2 CPTP CDIS) hat das CDIS also keinerlei Auswirkung. Hier könntest du nur eine Änderung erwirken indem du $APO.CPTP für den PTP-Anteil anpasst. Damit veränderts du dann aber nur wie aus dem PTP hinausüberschliffen wird.



    Auch sollte man bedenken, das Überschleifen immer auf Satzlänge / 2 limitiert ist. Ist z.B. dein LIN nur 50 mm lang, wird maximal mit 25 mm überschliffen auch wenn du 100mm programmiert hast. Beim PTP ist es genauso nur das hier der Verwahrweg der Achsen als Bogenmass im Achsraum herangezogen wird.


    Ferner sollte man bedenken, das die Steurung versucht halbwegs den Überschleifbereich zu symmetrisieren. Ist auf PTP Seite nur ein sehr kleines Kriterium programmiert, wird auf der LIN Seite auch nicht viel herauskommen. Umgekehrt gilt das gleiche bei sehr kleinem LIN-Überschleifen und großem PTP-Überschleifkriterium. In etwa kann man sich das so vorstellen, dass neben der Beschränkung auf Satzlänge / 2 noch eine Beschränkung auf das Minimum der Einzelkriterien stattfindet.


    Gruß
    Fubini

    Einmal editiert, zuletzt von fubini ()

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