Beiträge von Trias

Hallo Bert!

Danke für die Erklärung - ich muss zu unserer Entschuldigung sagen dass wir eine Architekturfakultät sind - vom Bedienen / Programmieren (also der Softwareseite) gibts somit keine echten Probleme, bei den Innereien sind wir aber manchmal überfragt

Bezüglich dem EMT: Ich hab im Manual (kleine) Bilder davon gesehen - ein sehr versierter Kollege meint dass er sowas nachbauen könnte, ich zitiere hier mal:

Zitat

...nur gibt es auf der Seite, mit der der Sensor am Roboter festgeschraubt wird zwei mal zwei kleine Bohrungen für Führungsstifte, die eine bestimme Orientierung zwischen zwei Teilen am Roboter sicherstellen und um einen Sensor nachzubauen müsste ich wissen wie diese beiden Teile im Original zu einander orientiert sind. Das würde man auf einem Foto sicher gleich sehen können. Es müsste ein Foto von der Seite sein, die in den Roboter geschraubt wird.

Wie seht ihr das - ist das möglich oder vergeudete Zeit?

Bei uns im Maschinenbau verwenden die leider nur ABB Roboter - ich nehme mal stark an dass die in keinster Weise kompatible EMTs haben?

Und eine letzte Frage: Fällt euch zufällig jemand in Wien/Umgebung ein der sonst einen EMT haben könnte und den herleihen/vermieten/verkaufen würde?

Noch einmal vielen Dank wie geduldig ihr alle geantwortet habt - hat uns wirklich sehr geholfen!!!

Ein schönes WE allerseits!

Johannes

Hallo Gernot,

Ich hab den KUKA grad nicht vor mir, aber - zumindestens glaub ich das - gibts im Menü "Roboterdaten" eine Funktion zum Importieren einer PID Datei - von der ich dachte dass sie die Justagedaten beinhaltet. Wenn man dann eine passende Datei (mit der Seriennummer des Roboters als Dateiname) ausgewählt hat, kommt eine Meldung dass er aufs RDW schreibt, somit hab ich vermutet dass er die alten Justagedaten zum RDW überträgt.
Ein Kollege von mir wird übers WE die Genauigkeit des Roboters überprüfen, anscheinend hat er mal ein paar Punkte eingemessen - bin schon gespannt ob wir von mm oder cm reden...

Einen schönen Abend noch!

Johannes

Nochmals Danke für die vielen Ideen!

So schauts nun aus: Heute wurde ein 6 Monate altes Backup-Image raufgespielt, was leider nichts gebracht hat. Außerdem hab ich alle Steckverbindungen geprüft und die ganzen Diagnoseprogramme durchgeschaut - da scheint alles in Ordnung zu sein, inkl. RDW. Das Einspielen von archivierten PIB Dateien (die Kalibrierungsfiles) hat nichts gebracht.

Bewegt wurde der Roboter in der Zwischenzeit mit größter Sicherheit in keiner Form, da niemand Zutritt hatte. Wie schon erwähnt: Ich habe den Roboter letzte Woche testweise via Serial Koordinaten geschickt und ihn die abfahren lassen, dann übers WE abgedreht und diese Woche ging dann nichts mehr - zumindestens bei den zwei Achsen.

Wir sind nun so verblieben dass wir die Achsen manuell auf Null eingestellt und nach Augenmaß justiert haben. Der KR60HA ist somit wohl nicht mehr "HA", aber er wird in den nächsten Wochen 4 Stockwerke runter ins EG gebracht, da hätten wir wohl so und so anschließend einen EMT-gerüsteten Techniker gebraucht. Bin schon gespannt ob der Fehler morgen wieder auftritt oder es nur ein einmaliger Ausrutscher war.

Wie genau funktionieren eigentlich die PIB Dateien und warum bringts nichts da alte Versionen einzuspielen?

Schönen Abend!

Johannes

Besten Dank für die schnelle Antwort, das hilft uns schon mal weiter! Ich werd mich morgen dann damit befassen und Rückmeldung geben!
Wenn noch wer Ideen hat, immer nur her damit!

Schönen Abend,

Johannes

Hallo Allerseits,

Wir haben einen KUKA KR 60 HA Roboter der meistens zum Fräsen eingesetzt wird. Seid einigen Wochen haben wir damit erstmals Probleme, zuerst gab die Spindelkühlung den Geist auf (wurde repariert), dann die fürs KCP zuständige Graphikkarte (wurde ausgetauscht) und nun lässt der Roboter es nicht mehr zu, einen Job zu starten, da die Achsen A3 & A6 dejustiert sind bzw. er das zumindestens ausgibt.

Wir hatten schon einmal ein ähnliches Problem weil die RDW Karte ausgesteckt war, die steckt aber nun definitiv. Ausserdem lassen sich die Achsen problemlos manuell verfahren, die Achsrotation wird aber nach jedem Start als 0 angezeigt. Bei den anderen Achsen scheint alles zu passen.

Die letzte Aktion die wir damit ausgeführt haben, war eine kurze Abfolge von via Serial übermittelten Koordinaten, anschließend wurde eine neue Graphikkarte eingebaut und der KRC2 ca. einen Meter in die Ecke zurückgerückt - sofern die eventuelle Erschütterung da was auslösen kann.

Irgendwas stimmt hier definitiv nicht, hat jemand von euch eine schlagende Idee? Es würde mich sehr freuen wenn das nur eine typische, alltägliche Kleinigkeit ist

Beste Grüße!

Johannes

P.S.: Sofern man nur neu justieren muss, wäre ich für diesbezügliche Tipps auch dankbar - vor allem was für Equipment man dafür braucht. Als hochexaktes Messwerkzeug hätten wir e.g. einen Metris- Arm, wenn das was bringt.

edit: Mir wurde gesagt dass der Roboter vor Lieferung "absolut vermessen" wurde - ist mir nur eben noch eingefallen, ohne zu wissen ob das etwas besonderes oder auch nur irgendwie relevant ist.

Hallo!

Vielen Dank für die äußerst informativen & ausführlichen Antworten!
Über Ostern werd ich mich dann damit befassen - es ist aber super zu wissen dass es keine prinzipiellen Probleme gibt! Die Option zum KRL Output im CAMRob werd ich mir heute noch raussuchen, das wäre dann sicher ein guter Anhaltspunkt für eigene Skripts.

Echtzeitsteuerung vom Roboter hat uns schon länger interessiert, ist KRL-XML die einfachste Sache zur Steuerung oder gibt es einen noch "primitiveren" Weg das zu übermitteln? In dem Metier gibt es bei uns (Architekturfakultät, also keine Maschinenbauer etc.) kein Know-How, somit wäre die simpelste Lösung Koordinate zu übermitteln die beste für uns.

Jedenfalls nochmals Danke! für die Antworten - die Echtzeitsteuerung ist momentan für uns nur ein Gimick, wenn aber jemand noch Denkanstöße diesbezüglich hat oder Tipps zum KRL Schreiben - immer nur her damit!

Allerbeste Grüße,

Johannes

Hallo Allerseits!

Wir verwenden auf der Universität unseren KUKA KR-60HA vor allem zum Fräsen von großformatigen Freiformflächen, was eigentlich ganz gut klappt.
Der Workflow geht von HyperMILL zu CAMRob/KUKASim und dann zum Roboter, je nach Bedarf schreiben wir den G-Code auch selbst und füttern ihn dann an CAMRob. Aus mehreren Gründen würden wir nun gerne CAMRob umgehen und die Koordinaten nicht als G-Code rausschreiben sondern gleich in ein Format mit dem der Roboter umgehen kann.
Die - etwas magere - KUKA Doku die wir zur Verfügung haben lässt den Schluss zu, dass man die Punkte einfach als PTP Movements in die *.src Datei schreiben kann, à la

PTP {POS:X 1025,Y 0,Z 1480,A 0,B 90,C 0,S ’B 010’,T ’B 000010’}

KUKA CAMRob erzeugt da jedoch eine andere Struktur, die *.src Datei verweist jeweils auf einzelne Jobs im *.bin Format.
Bei komplexeren Jobs kommen ja leicht viele 1000 Punkte zusammen - kratzt man dann an den Limits einer *.src Datei und muss deshalb die *.bin Datei verwenden?

Ausserdem war es mir leider auch mit diversen Hex-Editoren nicht möglich die binäre Datei in ein lesbares (und nachbaubares) Format zu brigen.

Der langen Rede kurzer Sinn:

Ist es möglich - und vernüftig - dem Roboter einige 1000 PTPs in die *.src Datei zu schreiben?

Wenn nicht: Nach welchem Muster sind die *.bin Dateien von CAMRob aufgebaut, sodass man sie nachbauen kann?

Eine Beispiels-*.bin Datei habe ich gezippt meinem Post beigelegt!

... das Durchlesen des Forums hat mir gezeigt dass wir mit unserem KUKA nur einen winzigen Teil der Möglichkeiten nutzen - ich hoffe meine Frage ist leicht zu beantworten & bin euch für eine Antwort jetzt schon dankbar!

Beste Grüße,

Johannes