Beiträge von Roboformer

    Die Korrekturwerte beziehen sich jeweils auf den RSI-Takt (4 oder 12 ms, je nach Einstellung) und werden auch in diesem aufgeschaltet. Das gewählte Limit von 0,5 mm ist viel zu groß gewählt und sorgt für die immer noch ruckartigen Bewegungen (250/s*0,5mm=125mm/s). Die Geschwindigkeit der Korrektur legst du ja selbst durch die übermittelten Werte fest.


    Bei kleineren Werten hat man dann auch eine sanfte Korrektur.

    Hallo zusammen,


    ich baue gerade für einen inkrementellen Umformprozess eine Kraftregelung zusammen. Da habe ich einige Fragen zur Umsetzung. Vielleicht erstmal ein bisschen was zum Prozess selber, der ja eher unbekannt ist. Ein von einem Roboter geführtes Werkzeug fährt spiralförmig in das Blech hinein, um eine Form in das Blech einzuprägen. Das Werkzeug bewegt sich dabei nur kartesisch. Eine Drehung findet nicht statt.


    Auf der Rückseite wird der Prozess durch einen zweiten Roboter abgestützt. Dieser soll mit einer definierten Kraft dagegen drücken, um eine Druckspannungsüberlagerung im Blech zu erzeugen. Im Gegensatz zu der oberen Abbildung ist das Umformwerkzeug hier unten dargestellt. Der Gegenhalter soll in Richtung des Umformwerkzeugs drücken. Die Position dabei kann variieren.



    Prinzipiell würde dies ja der Verwendung des des TTS als Referenzkoordinatensystem in der Kraftregelung entsprechen. Dieses wird laut Doku aus der Bahntangente und der X-Achse des Toolkoordinatensystems berechnet. Dementsprechend ist das leider nicht so einfach möglich, da die Orientierung des Werkzeugs gleich bleibt und nicht nur in X-Richtung verfahren wird. Ich weiß, dass man als Workaround das Tool über $TOOL.A ... während der Fahrt entsprechend mitrotieren kann, sodass das TTS in Richtung des gewünschten Kraftvektors zeigt. Das ist unsere aktuelle Lösung. Die Bahn ist über LIN-Bewegungen approximiert und an jedem Bahnpunkt wird das Werkzeug virtuell gedreht. Das funktioniert auch, allerdings hat man dann die Gefahr, dass wenn das Programm abgebrochen wird und man den Roboter händisch verfährt dieser nicht unbedingt so fährt wie man es erwartet. Dementsprechend würde ich gerne eine bessere Lösung suchen.


    Da der Kraftvektor bzw. die dazugehörigen ABC-Werte während des Programmablaufs vorliegen, kann man sich daraus ja die jeweilig gewünschten Kraftanteile in XYZ berechnen und im RSI in das Objekt FTCTRL einspeisen und das Tool als Referenzkoordinatensystem nehmen. Diese würden sich dann während des Programmablaufs permanent ändern. Nun bin ich unsicher inwieweit der Roboter sich dann nur Richtung des gewünschten Kraftvektors bewegen würde. Beim TTS würde er sich ja nach meinem Verständnis nur in innerhalb des Kraftvektors bewegen, da man nur für eine Achse des TTS eine Kraft vorgibt und er dementsprechend nur in dieser verfährt. Bei der anderen Modellierung hätten wir jetzt allerdings Kraftanteile in drei Richtungen. Dementsprechend denke ich, dass es zu einem Versatz der beiden Werkzeuge kommen könnte, da die Position in alle Raumrichtungen angepasst werden kann.


    Ist mein Gedankengang bis hierhin soweit korrekt? Gibt es eine elegantere Lösung das TTS zu nutzen, ohne das Werkzeug virtuell zu drehen?


    KSS ist übrigens 8.3.26. RSI und FtCtrl sind in der Version 3.1 vorhanden.


    Viele Grüße

    Hallo zusammen,


    beim Testen längerer Programme im T1 kommt es zur Meldung: Timeout Zustimmung, Zustimmtaster erneut drücken.


    Der Roboter wird über eine externe RSI-Anwendung geregelt, die im aktuellen Testzustand nach einem Stillstand allerdings nicht wieder angeschaltet werden kann. bzw. sollte. Der I-Anteil im Regler macht dann verrückte Sachen.


    Kann man den Timeout der Zustimmung abschalten oder zumindest stark erhöhen? Es handelt sich um eine KRC4 mit KSS 8.3.


    Grüße

    Ich verwende aktuell LIN.


    Ich meine irgendwo gelesen zu haben, dass es bei SLIN zu den beschriebenen Problemen kommt. Da kann ich mich natürlich auch irren, da ich den entsprechenden Beitrag nicht mehr finde. Allerdings habe ich dafür einen anderen Beitrag aufgetrieben in dem nach 200 Splinebewegungen der Arbeitsspeicher voll läuft. Das Problem sollte ich ja bei etwa 10.000 Punkten auf jeden Fall auch bekommen.

    Heute habe ich ein längeres Programm (>2Stunden) abgefahren.


    Währenddessen kam die die Meldung: "Bewegungssynchronisation kann nicht aufrecht erhalten werden". Kurz darauf ist der RSI ausgestiegen, da der Regelcomputer keine Daten mehr bekommen hat und dementsprechend auch nicht geantwortet hat.


    Das dürfte ja auch auf die Rechenlast der Steuerungen zurückzuführen lassen. Gibt es allgemein Möglichkeiten diese zu reduzieren? Theoretisch könnte ich den RSI-Takt von 4 auf 12 ms vergrößern. Das sollte allerdings der letzte Schritt sein.


    Eine weitere Idee wäre es die LIN-Bewegungen in SLIN umzuwandeln. Da fehlt mir die Erfahrung, aber was ich so gelesen habe ist dabei die Bahnplanung ressourceneffizienter. Jedoch sollen diese Probleme bei geringen Fahrgeschwindigkeiten und Punktabständen haben. Ich denke mal 20 mm/s und Abstände im Millimeterbereich fallen darunter?

    Sieht so aus, dass Du die Roboter ziemlich belastest mit Deinem Datenverkehr.

    Performance der Anzeige leidet darunter schlussendlich als erstes.

    Hast Du den ganzen Code mal in eine Falte gepackt, damit Du kein durchrattern des Codes mehr hast ?

    Die folds helfen zumindest etwas. Danke. Das Programm rattert jetzt nicht mehr nach der Beendigung noch 30 Minuten schon abgefahrene Zeilen runter. Allerdings kommt es jetzt beim Wechsel von Unterprogrammen dazu, dass das Pad in den HMI-Anmeldebildschirm springt.

    Hallo zusammen,


    ich betreibe 2 KR600 mit KRC4 Steuerungen im Roboteam. Die folgen synchronisiert einer durch LIN-Bewegungen abgebildeten CAM-Bahn. Nun habe ich das Problem, wenn ich mit dem Smartpad auf die Steuerung gehe, in der nicht das Smartpad steckt, dann flackert der Bereich mit dem Programmcode während der Durchführung und etwaige Tastendrücke wie das öffnen des Menüs werden erst mit teils mehreren Minuten Verzögerung übernommen. Das Ganze hält auch noch etwa 10 Minuten nach Beendigung des Programms an. Parallel kommuniziert auch noch der RSI mit einem Regelcomputer, falls das einen Einfluss hat. Die Programme sind leider CAM-typisch sehr lang (20.000-100.000 Zeilen in der src und 5.000-20.000 Zeilen in der dat). Gibt es eine andere Möglichkeit außer diese in zig unterschiedliche Programme zu zerlegen, um die Steuerung wieder vernünftig bedienen zu können?


    Viele Grüße

    Roboter ist ein absolutvermessener KR600 mit KRC4 Steuerung. Um das Modell selber soll es hier nicht im Detail gehen. Das würde wohl den Rahmen sprengen. Basis des Ganzen ist jedoch ein Vorwärtsmodell. Über den RSI gebe ich mir die aktuellen Positionswerte und Achswinkel aus, Im Vorwärtsmodell werden im Prinzip die Achswinkel genutzt, um verkettete 3D-Körper, die in der Länge den Achslängen gemäß Doku entsprechen, zu rotieren um den TCP zu berechnen. Da habe ich jedoch leider einen Versatz von 0,2-0,4mm. Da ist halt die Frage, ob Kuka intern auch wirklich mit den gleichen glatten Achslängen rechnet oder sonst etwas noch einen Einfluss auf die Berechnung des TCP hat.

    Aber müssten dann nicht trotzdem die vom RSI übermittelten Achswinkel und Koordinaten zueinander passen oder wird da im Hintergrund etwas angepasst? Ich würde gerne ausschließen ob ich irgendetwas kukaseitiges übersehe oder ob ich einen Fehler im Modell habe.

    Hallo zusammen,


    ich habe mir ein Programm gebaut, um die Nachgiebigkeiten der Gelenke infolge von Prozesskräften herauszuregeln. Dazu werden über den RSI die TCP-Position und die Achswinkel an einen Rechner geschickt. Dieser berechnet anhand der Kinematik innerhalb eines Mehrkörpermodells die Momente, die auf die einzelnen Gelenke wirken. Anhand von Steifigkeitskennlinien wird die Abdrängung der jeweiligen Gelenke ermittelt und über eine Vorwärtstransformation mit angepassten Gelenkwinkeln der tatsächliche TCP berechnet. Der Versatz wird dann entsprechend ausgeregelt. Das ganze funktioniert auch wunderbar, aber:


    Das Ergebnis der Vorwärtstransformation ist, auch wenn ich nur die vom Roboter übermittelten Achswinkel berücksichtige und die Kräfte außen vor lasse, nicht identisch mit der TCP-Position des Roboters. Das Ergebnis weicht etwas 0,2-0,4 mm von der realen Position ab. Vom Prinzip besteht die Transformation aus den jeweiligen Längen der einzelnen Achsen, die jeweils über den Achswinkel verbunden sind. Die Position wird im Base-System berechnet. Von der Theorie her simpel, aber irgendwas läuft da verkehrt. Zur Berechnung der Baseposition transformiere ich ABC um Z,Y',X''.





    Sind die glatten Werte der Achslängen, die in machine.dat und robcorr.dat zu finden sind, auch wirklich exakt die, mit denen der Roboter rechnet? Oder wird da im nachhinein etwas für absolutgenaue Roboter angepasst? Erscheint mir unwahrscheinlich, aber ich suche hier leider seit Tagen die Nadel im Heuhaufen.


    Ein schönes Wochenende

    Hallo zusammen,


    ich nutze 2 KRC4 (KSS 8.3) im universitären Kontext. Da die Maschinen dementsprechend häufig stillstehen und auch zwischendurch gerne mal ein Kaltstart durchgeführt wird, ist es auf Dauer doch recht nervig sich jedes Mal erneut als Admin anzumelden. Gibt es eine Möglichkeit dies automatisch beim booten zu tun?


    Viele Grüße