Beiträge von fubini

  • Überschleifen ptp - lin ohne "Fast-Stillstand"

    Hallo PA,


    wie du Überschleifen kannst hängt auch von dem LIN Zielpunkt ab, da ja die Steuerung es auch schaffen muss in die LIN-Bewegung hineinzuüberschleifen. Der maximale Überschleifradius ist beschränkt auf die halbe Länge der beteiligten Bewegungen. Ist z.B. der PTP sehr lang und der LIN sehr kurz, kannst du trotzdem frühestens bei halber Länge der LIN-Bewegung in der PTP-Bewegung anfangen zu überschleifen.
    Diese Kappung macht die Steurung implizit und teilt sie dem Nutzer nicht gesondert mit. Daher überprüfe doch mal wann die Bewegung die PTP-Einzelbewegung auf Genauhalt verlässt. Ich vermute das passiert erst kurz vor dem Punkt, der Überschliffen werden soll und da muss der Roboter wahrscheinlich "scharf" um die Ecke und muss folglich sehr langsam werden.


    Gruß
    Fubini

  • Experten Programmierung

    Hallo Jesi,


    hast du versucht das Programm im geöffneten oder im angewählten Zustand zu editieren? Ich frage deshalb, da LOOP, FOR,... im angewähletn Zusatnd nicht editiert werden können.


    Gruß
    Fubini

  • Fortlaufende Speicherung von Positionsdaten in einer Datei

    Hallo lazyloo,


    du könntest das durchaus mit dem Trace/Oszilloskopmachen. Von KUKA gibt es ein kleines DOS-Tool (trace2ascii), dass Tracedateien in Ascii-Dateien umwandelt, die du mit jedem Texteditor lesen kannst. Ich hab es leider gerade nicht zur Hand aber eventuell kannst du ja noch mal gezielt bei KUKA deswegen nachhacken oder LindePaul kann es hier ins Forum stellen. Soweit ich weiss haben diverse Kunden das auch im Einsatz.


    Gruß
    Fubini

  • Ich brauche Eure Hilfe

    Hallo Mario,


    Falls ihr kein ArcTech Paket habt, ist das Stichwort nachdem ihr mal schauen solltet Funktionsgnerator. Mit dem Funktionsgenerator kann man die Bahn mit selbstgabauten Auslenkungen überlagern.


    Gruß
    Fubini

  • Lageauswertung Kuka Robojet

    Hallo Robonic,


    ich verstehe deine Frage nicht ganz. In $AXIS_ACT steht doch die Achsposition bei linearen Achsen in mm? Inkrementelle Werte stehen meines Wissens nur in $AXIS_INC. Den würde ich aber für deine Aufgabe nicht verwenden.


    Gruß
    Fubini

  • Handachsensingularität

    Hallo student.


    das Problem mit KUE_WEG hatte ich auch schon mal und tritt immer in Verbindung mit Zusatzachsen auf. Hier wurde einfach in KUE_WEG.src vergessen die Zusatzachsen zu berücksichtigen. Das kann man aber leicht selbst korrigieren. Einfach



      • die Deklaration POS ZPOHNETURN in E6POS ZPOHNETURN ändern und

      • Bei den Zuweisungen ZPOHNETURN.A1=ZIEL.A1 die Zuweisungen ZPOHNETURN.E1=ZIEL.E1 ... ZPOHNETURN.E6=ZIEL.E6 ergänzen.


    Dann sollte das zumindest problemlos funktioniern.


    Gruß
    Fubini

  • Tool konstant halten

    Hallo Happyman0815,


    Der Roboter berechnet den Achse 5-Winkel im Zielpunkt der Bewegung über A5 = pi/2 - A2 - A3. Das ist bei A4=0 genau die notwendige Bedingung, das der Flansch parallel zum Roboterfuß ist. Gewissermaßen wird durch setzen von $PAL_MODE=TRUE ein 4-Achspallettierer simuliert, der die richtige Stellung des Roboters mechanisch über ein Parallelogramm das A2, A3 und A5 verbindet, herstellt. Nachdem sich beim PTP-Fahren jede einzelne Achse auf einer Geraden von ihrem Startpunkt zu ihrem Zielpunkt bewegt, stellt das dann auch sicher, dass während der Bewegung immer die Bedingung an den A5-Winkel erfüllt bleibt, also auch während der Bewegung der Flansch immer parallel zum Roboterfuß ausgerichtet bleiben sollte.


    Die Formel A5 = pi/2 - A2 - A3 könntest du übrigens, falls du nicht genau parallel zum Boden bleiben willst, auch modifizieren indem du die pi/2 gegen einen anderen Winkel austauscht. Das funktioniert solange du den Flansch fest in einer zur A2-A3-Ebene senkrechten Ebene ausrichten willst. Bei z.B. Einsetzen von 0 (oder pi, was richtig ist hab ich jetzt auf die schnelle nicht genau nachgerechnet) statt pi/2 müsste der Roboter den Flansch immer senkrecht zum Boden halten. Dann müsstest du allerdings deine Programme von Hand so modifizieren, dass der A5-Winkel immer passend berechnet wird. Direkt einstellbar über die Steuerung ist das dann nicht mehr.


    Gruß,
    Fubini

  • Tool konstant halten

    Hallo StefanM,


    soweit ich weiss aktiviert der $PAL_MODE auch die Kopplung, so dass der A5 Winkel immer passend aus dem A2 und A3-Winkel berechnet wird, so dass man dann immer parallel zum Boden bleiben sollte. Trotzdem wie du schon sagst: ausprobieren schadet ja nie.


    Gruß
    Fubini

  • Beschleunigung ung Geschwindigkeitsprofil

    Hallo,


    die Beschleunigung bei CP-Bewegungen kannst du kartesisch über $ACC.CP programmieren ($ACC.ORi1 und $ACC.ORI2 für Umorientierungsbeschleunigung).


    $ACC.CP = 5 ; 5 m/s^2
    LIN XP1


    In den Inline Formularen wird das nicht angeboten, so dass du Expertenprogramme dafür schreiben musst. Bei PTP-Bewegungungen kannst du nur die Achsbeschleunigung über $ACC_AXIS[AchsNr] beeinflussen. Nachdem bei PTP normalerweise aber mit Dynamikmodell verfahren wird, beschränkt dir das nicht direkt die Beschleunigung, sondern nur das zum Beschleunigen zur Verfügung stehende Moment.


    $ACC_AXIS[1]=50 ; Achse 1 mit 50%
    PTP XP1


    Gruß
    Fubini

  • Tool konstant halten

    Hallo,


    falls dein Tool immer dann nach "unten" zeigt, wenn auch der Flansch immer parallel zum Boden ist, könntest du den Roboter mit $PAL_MODE=true im Pallettiermodus betreiben. Dann hast du als einzigen Freiheitsgrad noch das drehen um die Achse 6 alias um den C-Winkel. Verdrehen um A und B-winkel geht dann nicht mehr.


    Gruß
    Fubini

  • Safe Robot

    Hallo,


    die Daten werden als XML (etwas kryptisch) in einer Datei namens KukaSafeRobot.config gespeichert. Auf Platte liegt die im Verzeichnis HMI/Config/SafeRobot. Nachdem die Daten nach Wiederherstellen ja wieder da sind wird wahrscheinlich einfach diese Datei gesichert.


    Gruß
    Fubini

  • SafeRobot Frage

    Hallo Wasdel,


    das sind Kreuzvergleichsfehler. Prozessor A und B der SafeRDW tauschen regelmässig ihre berechneten Daten aus und vergleichen sie miteinander. Stimmen diese nicht überein gibt es die Systemfehler 300x (*). x sagt aus in welcher Vergleichstabelle der Fehler aufgetreten ist (x=0: Integerwerte 32 Bit, x=1 double-Werte, und x=2 Integerwerte 64Bit, soweit ich das jetzt auswendig hinbekomme). Die zweite Zahl in Klammern gibt das Register des Tabelleneintrags an. Was in welchem Register steht ist leider Versionsabhängig und kann nur durch genaue Angabe der Versionsnummer inklusive Buildnummer (aus der Version.ini der SafeRobot Option) rekonstruiert werden.


    Die Erfahrung zeigt aber, dass es sich meist um die Justagedaten nach einem Justageverlust handelt. Durch neue Justage verschwinden diese Fehler dann wieder. Bevor man den Roboter neu justiert kann mann aber auch erstmal versuchen die Konfiguration neu auf die SafeRDW zu schreiben. Dazu einfach das Konfigurationstool öffnen, Dummy-Editieren und Speichern. Eventuell hilft das schon.


    Gruß
    Fubini

  • KRC-Systemfehler 14tLTC

    Hallo RT,


    der Fehler sagt, dass es in dem Modul LifeTimeCounter (Task tLTC) der KRC zu einem Pagefault gekommen ist. Da kannst du leider nicht viel machen es sei denn jemand hier weis wie man den LifeTimeCounter an der Steuerung deaktivieren kann. Am besten du kontaktierst KUKA und legst ein vollständiges Archiv bei. Insbesondere die Dateien tt_<Datum>__<Uhrzeit>.log und system_<Datum>__<Uhrzeit>.log aus dem Verzeichnis C:\KRC\Roboter\Log sind hier für die Analyse wichtig.


    Gruß
    Fubini

  • Safe RDW Systemfehler 15

    Hallo Glöckler,


    in Ergänzung zu LindePaul:


    Safe RDW Systemfehler 15 bedeutet, dass der schnelle Abschaltpfad bei Stoppreaktionen nicht zur Verfügung steht. Normalerweise pollt die SafeRDW zyklisch die DSE und erfragt ob Kurzschlussanforderungen direkt über die DSE abgesetzt werden können (der andere Abschaltpfad für Kurzschlussanforderungen läuft über den ESC und hat deutlich längere Reaktionszeiten).


    Früher gab es DSE-Versionen, die diese Funktionalität überhaupt nicht unterstützt haben und dann stand der Systemfehler 15 dauerhaft an. Das ist aber nicht weiter schlimm gewesen, da die Meldung keinerlei Stopp oder Verriegelungen hervorruft.


    Nachdem es bei dir aber nur sporadisch auftritt würde ich das mal ausschliessen und eher auf einen sporadischen Kommunikationsfehler zwischen DSE und RDW schliessen. Eventuell sollte man mal die Verdrahtungen kontrollieren.


    Auslöser des Stopps ist aber sicher wie LindePaul schon sagt die Kurzschlussanfordeung. Der Rest scheint Folge davon zu sein. Warum es zu der Kurzschlussanforderung kommt müsste man noch genauer untersuchen (oder war das ein gewollter Stopp?) Eventuell hat aber der Antriebsfehler etwas damit zu tun. Hättest du zu dem noch die Meldungsnummer, dann könnte ich eventuell mehr sagen (Meldungen mit Text "Antriebsfehler" gibt es leider mehrere unterschiedliche, z.B. MsgNo. 214-216 oder 234)



    Gruß
    Fubini

  • Geschwindigkeitsänderung während Lin-Bewegung

    Hallo,


    $VEL.CP ist die Geschwindigkeit mit der die Steuerung die Bewegung im Vorlauf plant. Zum Ausführungszeitpunkt hat das keinerlei Einfluß mehr.


    Ich würde die Overrideanpassung in einem Interrupt, der auf deinen gewünschten Eingang reagiert, machen. Der notwendige Interrupt wird im Deklarationsteil vereinbart.


    Fubini

  • motor data

    Hello,


    I just wanted to correct Martin Hubers explanation of ERSYS and EASYS,..,EFSYS:


    ERSYS does not tell if the axis is linear or not. This is done by means of $AXIS_TYPE = 1.


    ERSYS means the external kinematic is put in beetween the relation $WORLD -> robot base . That is the robot is mounted on the external kinematic (usually a single linear axis!). Only a single external kinematic of this type with up to 3 axes is allowed.


    On contrary EASYS,...,EFSYS configures up to six different external kinematics in the relation $WORLD -> $BASE with each external kinematics comprised of up to 3 axes. That is the position of the robot does not dependent on the position of the external kinematic.


    Fubini

  • Arbeitsräume - KUKA Safe

    Hallo Ollimike,


    das kannst du nur machen, falls der Arbeitsraum so eingestellt ist, dass er den Roboter bei Überfahren der Arbeitsraumgrenze nicht stoppt. Ansonsten gilt, dass der Roboter nur dann weiterfährt, falls er in allen aktiven, stoppenden Arbeitsräumen gleichzeitig drin ist. Ansonsten musst du darauf achten, dass der Überlappungsbereich der Arbeitsräume so groß ist, dass das aktuell aktive Werkzeug komplett in den Überlappungsbereich passt.


    Angenommen du willst von einem AR1 in einen AR2 wechseln. Warum konfigurierst du dann nicht für AR2 einen Ausgang der deiner SPS sagt, sobald der Roboter in AR2 angekommen ist und deaktivierst dann über die SPS den AR1?


    Gruß
    Fubini

  • KukaSafe im AUTEXT

    Hallo,


    Auszug Fehlerbeschreibung:
    "Stop bei nicht durchgefuehrter Justagereferenzierung" wurde im Parametriertool der SafeRDW bei mindestens einem Ueberwachungsraum aktiviert, es wurde keine Justagereferenzierung durchgefuehrt und die Betriebsart ist nicht T1.


    Im Klartext:
    Schau mal deine Überwachungsräume durch ob die Option "Stop bei nicht durchgefuehrter Justagereferenzierung" true gesetzt ist. Der Roboter wird dann bei Aktivierung dieses Überwachungsraums ohne erfolgreich durchgeführte Justagereferenzierung gestoppt, da er sich seiner Achsstellungen nicht mehr sicher sein kann und damit keine Räume sicher überwachen kann.


    Wahrscheinlich war an den anderen Anlagen die Option für alle aktiven Überwachungsräume auf false.


    Gruß
    Fubini