Dann fahren wir mal auf den Tisch und gucken was passiert.
Warum konnte Kuka solche Infos nicht geben?
Dann fahren wir mal auf den Tisch und gucken was passiert.
Warum konnte Kuka solche Infos nicht geben?
Ja ich hab beim Programm Init die Sollwerte auf MAX bzw. die Überwachung deaktiviert.
Im T1 beim Handverfahren ist immer für einige Sekunden ein größerer Strom erlaubt.
Aber da die Meldung vom Getriebe kommt schaltet er ab bevor ich wirklich verfahren kann.
Vom automatischen Freifahren träume ich grad nicht mal...
Ja das haben wir, Lieferzeit > 10 Jahre.
Daher aktuell ohne.
Unabhängig davon darf es meiner Meinung nach nicht sein, dass man einen Scara in der Situation nicht freifahren kann. JEDER andere Hersteller sieht das vor, und kennt das Problem. Kuka wollte aber 3,50€ für den Taster sparen...
Ja das sage ich meine Kollegen und Kunden auch immer - bringt trotzdem nix.
Das Problem ist hier leider, dass wir mit einer 2D Kamera teile von einem Band holen.
Wenn diese nicht korrekt erkannt wurden oder etwas anderes nicht stimmt, dann fahren wir mit dem Greifer auf das falsch liegende Teil und haben damit diese Kollision.
Ja ist es.
Verwirrend ist nur, dass beim Handverfahren in Base um C gedreht wird, intern aber alles wie bei den normalen 6-Achsern verrechnet wird.
Hallo Zusammen,
ich habe eine hoffentlich einfache Frage. Wir setzen den "neuen" Scara-Roboter von Kuka aus dem Titel ein.
Wenn ich nun mit der Z-Achse auf den Boden fahre, und so eine Kollision entsteht, kann ich den Roboter nicht mehr freifahren.
Es kommt immer die Fehlermeldung maximales Getriebemoment Achse 3. Ich muss dann immer den Roboter demontieren, oder von Hand etwas hochdrücken und entlasten (nicht gesund).
Die Tooldaten stimmen, ich habe bereits die Kollisionserkennung parametriert, und mit den Werten gespielt. Wenn ich so weit runter gehe, dass er im normalen Ablauf gerade so nicht stehen bleibt,
bleibt aber mein Problem weiterhin bestehen. Dann habe ich es mit der "alten" Kollisionserkennung probiert, auch hier hilft es nicht weiter.
der Kuka Support sagt mir, ich soll das machen was ich schon tue.
Es sind übrigens die ersten Modelle, die noch keinen Knopf zum lösen der Bremse von A3 haben, Die neueren haben das ja angeblich.
Und beim Master musst Du den Slave noch als Profinet-Device einbinden.
Hast Du eine profinetfähige SPS?
Wenn ja:
Alle Roboter benötigen die Option Profinet Slave
Die SPS bindet alle als Profinet-Devices ein
Die SPS kann nun Daten mit allen Robotern austauschen
In der SPS kannst Du die Daten zwischen den Robotern rangieren wie Du es brauchst
Wenn nein:
Hast Du bei einem Roboter die Option Profinet Master und bei allen anderen Profinet Slave?
Dann kann das gleiche passieren wie oben genannt, nur das der erste Roboter die Aufgabe
der SPS übernimmt.
Ja das kann etwas tricky sein, die richtige GSDML-Datei zu finden.
Was zeigt Dir denn die HW-Config im TIA an, wenn Du online bist?
Hast Du ggf. noch Profisafe im Roboter aktiv?
Bei den SPTP / SLIN Bewegungen fährt der Roboter an seinen mechanischen Grenzen laut Mada.
Wie also schon beschrieben, bietet es sich an diese etwas runter zu nehmen. (z.B. Beschleunigung, Ruck, Geschwindigkeit).
Hallo Zusammen,
ich sollte mit einem Roboter mit KRC4 ODER KRC5 Steuerung (hängt noch von der aktuellen Liefersituation ab) eine Socket-Verbindung per TCP oder UDP aufbauen.
Ethernet KRL ist mir bekannt.
Gibt es, wie glaube ich damals bei der KRC2, nicht eine einfache String oder Byte basierte Socket-Kommunikation, oder muss/kann ich das auch über EthernetKrl abbilden?
Grüße
INTERRUPT
Klar!
Du kannst unter Programmierung -> Eigenschaften die Sicherheitskonfig aus deinem Roboter (XML-Export WoV) importieren.
Ohne es 100% zu wissen gehe ich von folgendem aus:
Messmethode: Toolvermessen 4-Punkt.
Du vermisst dein Tool in dem Du z.B. eine Spitze aus 4 Positionen anfährst.
Dabei errechnet sich der Roboter aus den 4 Positionen den Schnittpunkt, und dies ist Dein TCP.
Da sich aber die 4 Positionen niemals perfekt treffen, sondern immer etwas aneinander vorbei gehen, muss der Roboter den TCP anhand des mittleren Fehlers "schätzen". Dieser Fehler ist das, was hier angezeigt wird. Ähnlich wird es sich bei den anderen Methoden verhalten.
Hallo Zusammen,
mein Name beschäftigt mich gerade.
Mal ein paar ZDF vorweg:
KSS 8.7
Krc5 Micro
Programmierung mit SPTP/SLIN
Aufgabenstellung:
Mit einem Trigger When Distance wird beim Erreichen eines Punktes ein Unterprogramm aufgerufen.
Bei SPTP/SLIN wird ja beim beginn der Überschleifbewegung dieser Trigger ausgelöst.
Es gibt die Variable POS_INT bzw. AXIS_INT die mir die Roboterposition zum Zeitpunkt des Interrupts speichern, soweit ok.
Mich interessiert jetzt aber die wirkliche Zielposition, die ohne Überschleifen hätte angefahren werden können.
Dazu gibt es ja POS_NEXT bzw. AXIS_NEXT. Ich habe aber die Sorge, dass der Interrupt prioritätsbedingt später ausgeführt wird,
und POS_NEXT ggf. schon mit der nächsten Bewegung beschrieben wird -> Das wäre natürlich schlecht.
Hat hier jemand eine Idee für mich?
Grüße
Interrupt
Naja ich hab den ersten Beitrag auch nochmal lesen müssen, aber mir ist es klar geworden.
Der Kollege hat ein Work-Visual-Projekt auf seinem Rechner, an dem er ohne den Roboter wochenlang programmiert. In der Zeit möchte er natürlich eine regelmäßige Datensicherung machen, und fragt nun wie er das am unklügsten erledigen kann.
Online ist klar -> Alles archivieren bzw. ggf. automatische Backups des Roboters.
Offline -> Backuptool deiner Wahl in das WoV-Verzeichnis gucken lassen und regelmäßig sichern.
Oder Git nutzen.
Ich schmeiße mal RescueZilla in den Raum.
Hat ne schöne GUI, hab schon lang vor es an nem Kuka zu testen, komme aber nicht dazu.
Alles anzeigenIst ja auf dem Robbi auch nicht viel besser. Früher konnte man sich (mit ExpertTech) drauf verlassen, dass mit einer $BASE- oder $TOOL-Zuweisung auch das Programmierkoordinatensystem geändert wurde, sei es auch im Vorlauf, was angelegentlich zur Verwirrung führte. Heute hat die $BASE- und $TOOL-Zuweisung nur noch Einfluss auf das Programm, beim Teachen werden hingegen die eingestellten Grund-Koordinatensysteme genommen, die in der Statusleiste des KCP angezeigt werden. Wenn man glaubt, mal eben auf Touch-up drücken zu können, wird man baß enttäuscht sein von dem Ergebnis. Man muss sich also immer erst z. B. das aktuelle $BASE in BASE_DATA[irgendwas] schreiben, und dann mit BAS(#BASE,irgendwas) die Sache wieder zurückholen, um ins Reine zu kommen.
Und die Inlineformulare lassen sich davon erst gar nicht beeindrucken, die nehmen immer stur das zuletzt verwendete. Wohlgemerkt, was wieder nichts mit dem aktuellen Programmierkoordinatensystem in der Statusleiste zu tun hat. Wenn beides nicht gleich ist, hat man ebenfalls ein Problem.
Wie oft ich jetzt schon Punkte vergebens geteacht habe, weil ich da in alter Manier nicht drauf geachtet habe....
Vielleicht hab' ich auch einfach nicht kapiert, was die eigentliche Idee dahinter sein sollte.
Grüße,
Michael
Wenn man $ACT_TOOL und $ACT_BASE beschreibt sollten 90% Deiner Probleme gelöst sein!
Hi vielen Dank!
Die KSS-Version weiß ich leider nicht (ich weiß - böse) aber es ist defenitiv das alte Meldeverfahren.
Das mit den 20 Zeichen wusste ich nicht. Der Offset ist auf 0 - ich habe aber gesehen, dass meine Meldung 21 Zeichen lang ist.
Somit haben wir den Bösewicht gefunden
Vielen Dank!