Beiträge von fubini

    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

    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 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,


    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

    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

    Hallo Wasdel,


    eine externes Tool wird genauso gehandelt wie ein Tool am Flansch. Um es zu verwenden musst du einfach im Programm den $IPO_MODE vom Default #BASE auf $IPO_MODE=#TCP ändern.


    Gruß
    Fubini

    Hallo Michael,


    ich meine der Submit ist hier wohl etwas zu langsam. Daten nur alle 200ms sind insbesondere beim PTP etwas zu langsam. Wenn ich dich richtig verstehe willst du auch noch die kartesische Geschwindigkeit protokollieren (d.h. bei PTP musst du die natürlich selbst berechnen) und spätestens da wirds doch sehr ungenau, da der Roboter in den 200 ms schon recht viel Weg macht und auch nicht umbedingt mit konstanter Geschwindigkeit fährt.


    Mein Mittel der Wahl wäre ein Trace mit dem eingebauten Oszi und z.B. Aufzeichnung der Interpolatorgruppe. Das liefert allerdings nur Positionen und keine Geschwindigkeiten. Eventuell besser wäre hier die Testgruppe 10 "Dynamikmodell", die z.B. auch die Achsgeschwindigkeiten enthält. An kartesische Info wie der aktuellen TCP-Geschwindigkeit kommst du auch hier nicht ran sondern müsstest sie selbst berechnen.


    Gruß
    Fubini

    Hallo Zorniki,


    prinzipiell kannst du den Roboter natürlich auch mit einer laut Traglastdiagramm unzulässigen Last betreiben. Du solltest dir aber einiger Einschränkungen bewusst sein:


    Die Traglastdiagramme sind so ausgelegt, dass man bei Einhaltung im gesamten Arbeitsraum des Roboters verfahren können sollte. Bei dir wird es dann eventuell Bereiche geben, die nicht erreicht werden können, da der Roboter vorher mit einer Überwachung austeigt. Denkbar sind hier z.B. Meldungen wie statisches Haltemoment beim PTP-Fahren oder Maximales Getriebmoment beim CP-Fahren.


    Gruß
    Fubini

    Hallo Petz,


    S steht für Status und unterscheidet die unterschiedlichen Achskonfigurationen, die zur gleichen kartesischen Position führen. Nachdem die Positionen beim Teachen immer kartesisch im *.dat File abgelegt werden braucht man dann den Status z.B. beim PTP um eindeutig auf die zugehörigen Achstellungen von Start und Zielpunkt zurückrechnen zu können. Dabei gibt Bit 0 die Position des Handwurzelpunkts (gemeinsamer Schnittpunkt der Handachsen) im Überkopfbereich oder nicht an. Bit 1 ist die Arm Konfiguration (elbow up/down) und Bit 2 die Handachskonfiguration (up/down).


    T steht für Turn und beschreibt die Vorzeichen der Achspositionen des Roboters. T ist also auch ein Bitfeld, wobei Bit 0 zur Achse 1 gehört. 0 bedeutet dabei negatives Vorzeichen. Verwendet werden diese Bits um z.B. zu unterscheiden ob eine Achse auf +5 Grad oder -355 Grad fahren soll. Beim Verfahrenheisst das dann ob die Achse auf dem langen oder kurzen Weg zum Zielpunkt geht.


    E1...E6 sind die Positionen von eventuell bis zu 6 Zusatzachsen.


    Gruß
    Fubini

    Hallo John,


    die zylindrischen Arbeitsräume $CYLWORKSPACE[] findest du in der R1/$Machine.dat gleich nach den achsspezifischen $AXWORKSPACE[]. Wenn ich mich jetzt aus dem Gedächtnis nicht irre sind da die ersten beiden bereits fest einkonfiguriert. Aber am besten du schaust einfach mal selbst nach. Das Handling ist jedenfalls identisch zu den anderen Typen.


    Gruß
    Fubini

    Hallo John,


    Ist es vielleicht 3072?


    Unsere Vermutung für den Fehler ist dann, dass es mit einem schon bekannten Problem der Denso-Antriebstechnik zu tun hat. Beim Hochlauf der Steuerung schickt diese fälschlicherweise gültige Positionen an die KUKA-Seite obwohl die Antriebe noch nicht richtig initialisiert sind. Quasi ist dann die Position der Achsen beim Hochlauf kurzzeitig irgendwo. Zufälligerweise könnte es jetzt sein, dass diese Lage des Roboters einen Arbeitsraum verletzt. Sind daher bei euch auch wirklich alle Arbeitsräume ($AXWORKSPACE[], $CYLWORKSPACE[] und $WORKSPACE[]) deaktiviert?


    Die zylindrischen Arbeitsräume $CYLWORKSPACE sind dabei neu für die Denso-Kinematik ins System gekommen und in den Maschinendaten zum Teil immer aktiv. Das liegt daran, dass die Kinematik sonst aufgrund ihrer Bauweise mit dem eigenen Sockel kollidieren könnte. Bei KUKA Kinematiken ist das so nicht notwendig, da dort bereits über die Lage der Endanschläge der Achsen eine solche Kollision ausgeschlossen werden kann.


    In einem neueren Softwarestand hat Denso dieses Problem inzwischen behoben.


    Gruß
    Fubini

    Hallo John,


    wie lautet die genaue Meldungsnummer? Ist es eine größer 31000, dann ist das die Arbeitsraumüberwachung der Densoseite ansonsten die von KUKA. Für eine genauere Analyse wäre das noch wichtig.


    Danke,
    Fubini

    Hallo Jens,


    das steht in der R1/$machine.dat unter $ACC_MA. Normalerweise stehen da im Defaultfall für alle Robotertypen 10 m/s^2 lineare Beschleunigung und je 1000 Grad/s^2 für drehen und schwenken bei der Orientierungsführung.


    Gruß
    Fubini

    Hallo Bert,


    die Kurzschlussanforderung RDW steht z.B. immer dann an wenn die SafeRDW einen Stopp 0 auslöst, d.h. genauer den Ausgang QE auf der SafeRDW setzt. Beim Hochlauf ist das solange der Fall bis die Sicherheitskonfiguration erfolgreich verifiziert ist. Nachdem ihr die Konfiguration noch nicht gemacht habt kann das also gut sein, dass diese noch ungültig ist. Das müsste man aber an einer zusätzlichen Meldung (Text hab ich leider gerade nicht parat, irgendetwas mit Ungültige konfiguration) erkennen. Auch kann es sein, dass ihr noch keine Justagereferenzierung gemacht habt und in einer Betriebsart ungleich T1 seid, dann gibt es auch einen Stopp Null.


    Das maximale Getriebmoment hat nichts speziell mit der SafeRDW zu tun bzw. wird von dieser nicht überwacht. Insofern (mal einen Hardwarefehler des Boards ausgeschlossen) ist hier das Verhalten identisch mit einer RDW2.


    Gruß
    Fubini

    Hallo Eagle,


    zunächst Arbeitsraumfehler hat nichts mit Arbeitsraumüberwachung zu tun, sondern nur ob der Roboter diese Position anfahren kann oder nicht. Wie genau fährst du den Punkt an?


    Eventuell hast du deine Position im BASE mit einem falschen Status geteacht so dass der Robbi die Position nicht erreichen kann. Nachdem der Status bei CP-Bewegungen immer beibehalten wird ist dieser durch den letzten davor liegenden PTP-Punkt bereits festgelegt.


    Eventuell muss der Roboter auch nur auf dem Weg zu deinem BASE irgendwo durch wo er physikalisch nicht hin kann. Die Meldung kommt nicht nur wegen dem Endpunkt der Bewegung, sondern - zumindest beim CP-Fahren - auch für Punkte auf der Bewegungsbahn.


    Gruß
    Fubini

    Hallo,


    eine einfache Formel oder Tabelle für diese Problem wird es wohl kaum geben, da der Sicherheitsabstand wohl kaum nur von den (Achs-)-Geschwindigkeiten abhängt, sondern sicher noch von den Lastdaten und Abmessungen deines Werkzeugs sowie der Dynamik des Roboters.


    Siehe auch die Diskussion bei


    http://www.roboterforum.de/rob….0.html;msg17530#msg17530


    Dort findest du ein paar Normen, die sich mit so etwas befassen. Allerdings kommst du da immer auf sehr große Abstände.


    Gruß
    Fubini

    Hallo,


    so ungefähr heisst z.B. dass es nie eine Parabel wird, sondern immer ein Kreisbogen bleibt, wobei der Radius des Kreises immer größer wird je näher der Hilfspunkt an die Verbindungsgerade von Start- und Zielpunkt heranrückt.


    Gruß
    Fubini