Posts by ottosieben

    Moin,

    beim TCP-Umschalten gabe ich diese Effekte bereits damals bei der KRC2 beobachtet.

    Das vergleiche ich gern mit dem Räderwechsel am Auto während der Fahrt. Das geht auch nur im Stillstand.

    Meine damalige Lösung: Bewegung aus Station 1 mit Tool 1 teachen , dann die Punkte erneut anfahren und auf Tool 2 umteachen.

    Der Wechsel des TCP findet im Programmablauf dann im Stillstand = Werkstückaufnahme statt, ggf. müssen dann dort in der gleichen Position zwei räumlich gleiche Punkte mit beiden Tools angelegt werden.

    Grüße

    für den Anfang hätte es wahrscheinlich auch ein Agilus gemacht; schlägt nicht so hart zu wie ein KR125;)

    Moin,

    das möchte ich so nicht stehen lassen. Auch ein Agilus ist in der Lage , bleibende Gesundheitsschäden zu verursachen. An der richtigen Stelle erwischt, kann auch der "Kleine" jemand ins Jenseits befördern.


    INDUSTRIEROBOTER SIND KEIN SPIELZEUG !


    Grüße

    Moin,

    die Verschaltung der E/A für mxA auf der Roboterseite erfolgt ja mittels Teilprojektimport. Daher tippe ich auf Fehler bei der Initialisierung auf der SPS Seite.

    Erfahrungsgemäß werden die entsprechenden FB's nicht in der richtigen Reihenfolge angewendet. Es ist zu beachten, dass auch die SPS immer einen Zyklus benötigt, um die Ausgänge zu schreiben. Zum Beispiel Init der Schnittstelle und im nächsten Netzwerk sofort einen Befehl absetzen kann nicht funktionieren, da das Init zu dem Zeitpunkt den Roboter noch gar nicht erreicht hat. Das mal nur als Beispiel.

    Vielleicht hilft das weiter.

    Die Bremsenleitungen werden direkt am Umrichter gesteckt (bei KRC4). Evtl. sind die Bremsleitungen dort zwischen den Achsen vertauscht. Tritt der Fehler bereits beim Handverfahren der Achsen auf ?

    Daran liegt es nicht. Die Bremsenstecker am am KSP/KPP sind durch die Belegung codiert, sind diese vertauscht, öffnet die Bremse nie.

    Grüße

    Moin,

    wie soll Dir geholfen werden, wenn Du lediglich mitteilst , dass was nicht geht?

    Ich finde es schon sehr bedenklich, dass Du schreibst, die Positionen in der *.dat angepasst zu haben und im gleichen Atemzug über die Inlineformulare meckerst.

    Sorry.

    Wenn Du "zu Fuß" in den *.dat Werte änderst, was ich Deinen Ausführungen entnehme, erwarte nicht, dass die Formulare anschließend evtl. Fehleingaben in der *.dat wieder glattbügeln. Sollte die Struktur in der *.dat durch die Änderung einen Fehler aufweisen, so wird dieser vermutlich nicht automatisch durch Benutzung des Inline korrigiert, da das Einlesen aufgrund des Strukturfehlers schon "Mist" ergibt.

    Moin,

    TRACEN ist generell möglich.

    Bei den Tracekonfigurationen auf der Steuerung sollte eine vorgefertigte Konfiguration für die Mechanik liegen. Der Name fällt mir gerade nicht ein, irgendwas mit mec ... Im Zweifelsfall gehe einfach auf KUKA zu und lasse Dir die Konfig schicken.

    Allerdings gehe ich bei der Häufigkeit von einer generellen Überlastung aus. Lade Dir bei KUKA doch einfach das kostenlose Tool KUKA.LOAD herunter und lass das Teil mal rechnen, ob die Belastung des Roboters dyn. und stat. i.O. ist.

    Moin,

    wenn das so ist, ist ja alles gut.

    Nichteinhalten der Wiederholgenauigkeit läßt sich schwerlich nachvollziehen.

    Gerade nach dem Poliereinsatz kann der Getriebeverschleiß erhöht sein. Heißt , erhöhtes Getriebeumkehrspiel kann beim Positionieren zum Nachschwingen und damit zur Positionsabweichung führen. Grundsätzlich stehen die Getriebe beim geteachten Punkt immer auf der gleichen Stelle, was theoretisch die (geteachte) Position entsprechend der Spezifikation genau anfahren sollte. Auch kommt das Getriebe bei geteachten Programmen immer aus der selben Drehrichtung auf den Punkt zu, was die These der Wiederholgenauigkeit unterstützt. Statisch betrachtet sieht es dann eigentlich gut aus, nur leider spielt dann die Dynamik mit rein, was zu einem unzureichendem Ergebnis führen kann. Leider hat Getriebespiel die Angewohnheit, sich selbst zu vergrößern und ausserdem immer dort aufzutreten, wo man es am wenigsten gebrauchen kann.

    Moin,

    wenn ein Roboter umgesetzt wird, sollte er grundsätzlich nochmals justiert werden. Ich nenne es REINBETRIEBNAHME.

    Gerade wenn er jetzt neue Aufgaben übernimmt, sollte bei der Erstellung der neuen Programme sichergestellt sein, dass die Justage passt.

    Alles andere ist Pfusch.

    In der Zeit, die für die Beiträge hier verbraucht wurde, wäre die Justage schon erledigt...

    Moin,

    Deine Annahme, dass der Roboter deswegen in KEINER Betriebsart bewegbar ist, ist falsch. Das muss andere Gründe haben.

    Das Deinstallieren der Option, wenn überhaupt möglich, würde ich unterlassen. Der SafeRobot hat bei der KRC2 spezielle Hardware an Bord. Durch die Deinstallation tut er meines Wissens dann gar nicht mehr. Um die lästigen Sicherheitsfehlermeldungen los zu werden, müssen in der Sicherheitssteuerung sämtliche Einstellungen deaktiviert werden. Danach sollte er sich wie eine "normaler" Roboter benehmen.

    Grüße

    Moin,

    der Menüpunkt "Aktuelle Daten sichern" schreibt lediglich die aktuellen Achsstellungen auf die RDW, also das selbe Prozedere wie beim Herunterfahren.

    Das ist zB. im Falle defekter Akkus hilfreich, wenn das Herunterfahren nicht mehr sicher möglich ist. So erspart man sich den Justageverlust...

    Was allerdings der Vergleich einer Uhrjustage mit der EMT-Justage bringen soll, ist mir nicht klar.

    1) mit Uhr justiert ist immer ein ziemlich "subjektives" Ergebnis

    2) mit EMT justiert ist reproduzierbar (weil automatisert), aber von Justagesituation abhängig

    Da die ursprüngliche Justagesituation vermutlich unbekannt ist , würde ich eine Erstjustage ohne Werkzeug durchführen, Im Idealfall mit EMT.

    Im späteren Verlauf der Reinbetriebnahme den Offset mit angebauten Werkzeug lernen.

    Grüße

    Moin, was meinst Du mit Justagesicherung?


    Die *.cal beschreibt die elektrischen Offsets zur Justagestellung.

    Die eigentliche Justage wird im Moment des Justierens durch Setzen der mechanischen Sollwerte zur aktuellen elektrischen Position vorgenommen. (Mit Berücksichtingung der Offsets aus der *.cal)

    Damit ist dann der Abgleich vollzogen. Die Speicherung findet erst beim Herunterfahren statt, bei dem die AKTUELLE Position der Achsen in der Speicher der RDW geschrieben wird. Beim Hochlauf werden diese Werte geladen und mit der AKTUELLEN Position verglichen. Sollten die Werte gleich sein, so bleibt der Roboter justiert und Automatik ist möglich.

    Ein Sichern der Daten in z.B. einem Archiv findet NICHT statt, wozu auch. Die Position kann ja beim Ausschalten beliebig sein..

    Moin,

    seitens Software kannst Du die Achse 6 auch auf unendlich drehend stellen. Die Softwareendlagen müssten dann irgendwie anders überwacht werden, in der sps.sub zum Beispiel. Eventuell ist aber mit der "endlosen Achse" ein anderer Einstellbereich der Softwareendlagen möglich?

    ...

    Habe nun gesehen das RAM schon relativ fest ausgelastet ist (Hilfe->Info) zeigt zwischenzeitlich doch z.B. 95% an. Nun habe ich von 2x128MB auf 3x128MB erweitert (hatte noch einen exakt gleichen Riegel von einer anderen KRC2). Danach erst mal Bildschirm schwarz. Nachdem ich erst mal CMOS Clear Jumper gesetzt habe, MB Batterie kurz raus, startet der PC trotzdem nicht. Habe dann in einem anderen Forumartikel gelesen dass man den Startknopf des Mainboard / ATX Powersupply kurzschliessen muss und danach direkt KUKA defaults laden:

    KRC2 PC läuft nicht

    ..

    Moin,

    offensichtlich ist der neue RAM Riegel nicht passend.

    Weiterhin gibt es , wie ich mich dunkel erinnern kann, nur bestimmte RAM Kombinationen, mit der die KSS umgehen kann. Dazu ghört garantiert nicht , dass drei der 4 Steckplätze belegt sind.


    Selbst auf die Gefahr hin, dass ich wiederhole: Ein Zugriff auf die Daten im R1 Ordner zur Laufzeit der KSS ob über Netzwerk oder direkt, ist nicht empfehlenswert. Das Echtzeitbetriebssystem der KSS greift auf diese Daten zu!

    Moin,

    bei absolutgenauen Robotern existiert auf der RDW/RDC noch eine Korrekturdatei, umgangssprachlich genannt "PID File".

    Dieses beinhaltet ein Korrekturnetzwerk für den gesamten Arbeitsraum, welches durch 3D-Vermessung mehrerer Posen erstellt wird.

    Dabei ist auch eine definierte Last am Flansch.