Beiträge von DerJosef

joar.. stimmt. aber die werden länger brauchen das anzuschaun, als wenn ich alles neu machen würde oder einer spontan ne gute antwort hätte. Aber Kuka wollte ich heute dne ganzen Tag sowieso anrufen, 24 Stunden Hotline, wovon 8 Stunden schonmal nur besetzt waren. :p

Wozu braucht man denn Proconos? Ich meine.. in KRC läuft doch eine Sub SPS auf Basis von VX Worx in Echtzeit oder nicht?

Moin Leute, ich bins mal wieder. Dieses mal habe ich ein reines Softwareproblem.
Ich möchte die Kuka-Software einer KRC2 Steuerung updaten. Von der Version 5.4.7 H4 zur Version 5.4.7 H10. Habe das ganz normal versucht über Inbetriebnahme.. Update usw. Nach dem automatischen Neustart begann die Kiste mit dem Aufruf der Setup-Datei aber blieb schnell hängen.
Installshield von XP Embedded meckerte mit dem Fehler wie im Bild dargestellt. Error 5011 - 80040702 Habe schon gegoogelt und vieles ausprobiert, wie Adminrechte kontrolliert etc. Bei der Festplatte wo ich das Update drauf machen möchte handelt es sich um ein Image eines anderen Roboters (ist davor mit der 5.4.7 H4 aber problemlos auf diesem Roboter gelaufen). Alle unnötigen Tasks wurden abgestellt... Hat jemand eine Idee, oder ist einem das gar auch schon mal passiert?

so Leute.. eine letze Frage zu dem Thema, vll kann mir da jemand was sagen. Es gibt von Kuka anscheinend eine Tech Paket zur Simulation einer siebten Achse. Soll und Ist Position sind dann wohl zugänglich und können nach außen geleitet werden. Hat da jemand Erfahrung mit der Ansteuerung von externen Umrichtern? Oder weiss vll. jemand mehr über das Simu-Paket? Vielen Dank

hmm keiner eine Ahnung wie die Kommunikation intern auf dem Bus für die Umrichter abläuft? Muss ja irgendwie möglich sein da noch was dranzusetzen, was nicht von Lenze (Kuka) ist. Resolver könnte vll. über die Schnittstelle der Steuerung für eine siebte Achse angeschlossen werden...

Aus anlagentechnischen Gründen muss es ein externer sew Umrichter sein. Man könnte einfach den Interbus den die Steuerung für die Umrichter benutzt erweitern, denke ich. Jedoch werden die Resolverdaten bei den internen Lenze Umrichtern ja nicht wieder direkt zum Umrichter geleitet, wie es bei dem Exteren der Fall ist. Die Regelung selbst geschieht ja anscheinend in der Steuerung selbst und nicht in den 6 Umrichtern. Ich weiss nicht, ob man dann einfach so eine externe Achse in der maschine.dat vorgaukeln kann. Igrendwie muss ich dann ja die Resolverdaten an die Stelle bringen, wo sie von der Steuerung bearbeitet werden.
Der Fremdmotor läuft zudem über eine PLC. Also ich würde nur die Daten abgreifen wollen, die normalerweise der Achse 7 zukommen, in der PLC aufarbeiten und entsprechend benötigte Daten zurückliefern über den Umrichterbus. Vll. kann man über diesen auch die Resolverdaten von der PLC an die richtige Stelle zurückliefern. Habe halt keine Ahnung, was da intern im Bus alles für Kommunikationsdaten laufen.
Aber vll. geht es auch anders, nicht über den internen Umrichterbus, indem ich einfach die Solldaten und Istdaten der Achse (über die PLC aufbereitet) stänig über einen Interbus mit der Rob-Steuerung als Master sende, also die Daten zum Umrichter über eine andere Schnittstelle laufen lasse. Hier weiss ich nicht, wo man diese Daten schreiben und lesen kann, damit die Steuerung eine solche siebte Achse deutet und verarbeiten kann.

Schwierig, schwierig.. Müsste mehr über das Erfahren, was sich wirklich in der Steuerung abspielt in Sachen Umrichterkommunikation..

Bei der Krc2 Steuerung laufen die internen Umrichter ja über Interbus. Hat jemand Erfahrung, was für Daten da genau verschickt werden? Vielleicht ist es ja möglich einfach eine siebte Achse anzugeben und dann den Bus nach außen führen und Daten per PLC vom Umrichter abgreifen und entsprechend zurückgeben...

Hi Leute!
Ich will eine siebte Achse betreiben, allerdings nicht über Umrichter der KUKA-Steuerung, sondern über einen externen Umrichter. (Daten via Bussystem zum Umrichter). Gibt es davür von KUKA irgend ein Techpaket, was nötige Positionsdaten aus den Steuerungsberechnungen weiterleiten kann, bzw die siebte Achse derart anbinden kann?

Danke

Eine sehr gute Idee
Dachte nur das man das auch theoretisch hinterlegen kann, ohne das durch Fummeln herauzubekommen.

if your "C" changed too maybe you have to look at an other coordinate-systeme?

WolfHenk
vielen Dank! Aber ich habe das jetzt aus "gooselks" Aussagen so verstanden, dass ich bei einer Veränderung von A x und y nicht neu berechnen muss. Ich hätte da gedacht:
Alte Tool Daten: X 0,85, Y 0,35, Z 255, A 0, B 90, C 0
Jetzt wird aus A=0 --> A=225, also dreht sich das Koordinatensystem um 225 Grad in der Weise, wie man auch Achse 6 um 225 drehen würde.
X und Y habe ich dann als Punkt (TCP) in diesem Koordinatensytem angesehen, wobei sich dieses System um 225 Grad dreht (Der Ursprung bleibt da wo er ist). Mit ner kleinen Rechnung kam ich dann auf die neuen Werte: X= -0,325 und Y= -0,86. (siehe Bild)
Nach "gooselk" ist das aber gar nicht nötig und der TCP bleibt trotzdem bei den alten Werten.

Zum Programm: Ich habe nur einen einzigen Teachpunkt, den ich dann einfach um 225 Grad um Achse 6 gedreht habe (ist ok so).
Fragt sich nur ob mein TCP nun noch genau wie der alte ist....

Eigentlich müsste sich das Tool-Koordinatensystem ja drehen, wenn man A in den Tooldaten verändert? Wenn sich das Systrem dreht liegt der TCP nicht mehr in der Mitte der Zange? Oder dreht sich dabei alles um den TCP?

Es wurde natürlich alles auf den TCP, also den Mittelpunkt des Greifers bezogen. Die Frage ist halt nur, ob dieser TCP eine andere Position im werkzeug selbst hat, nachdem man A in den Tool-Daten geändert hat, oder on dieser TCP (der vorher genau im Mittelpunkt der Zange war) durch die Veränderung von A jetzt nicht mehr im Mittelpunkt der Zange liegt und X und Y (kann ich ja durch Berechnung machen) nun andere Werte haben müssen (um den Winkel A verschoben)

Danke Leute

Hallo Leute!
Ich, der Josef, möchte auch mal wieder Euer Wissen ausquetschen.
Ich habe ein Werkzeug Zange) im rechten Winkel am Flansch befestigt. Die Tool Daten: X = 0,8; Y = -0,35; Z = 255; A = 0; B = 90; C = ...)
Der TCP befindet sich so genau in der Mitte der Zange ( Wenn Achse 6 gedreht wird haben die Zangenbacken immer den gleichen Abstand zum Werkstück.
Soweit alles gut, doch meine Vorgänger haben nicht berücksichtigt, dass die Zange nicht in Ausrichtung auf den Nullpunkt der Achse 6 angebracht ist, sprich A dürfte nicht 0 sein und im Werkzeugkoordinatensystem fährt das Werkzeug somit in X und Y Richtung nicht in Ausrichtung der Zangenbacken.

Ich habe nachträglich A auf 225 angepasst (nun fährt auch das Werkzeug richtig).

Frage jetzt: Muss ich hier X und Y der Tooldaten auf die neue Ausrichtung anpassen? Hat sich der TCP (der ja so gesehen in der Mitte der Zange sein sollte) um den neuen Winkel von A verschoben?

Danke :angel:

Has gewusst dass es so einfach ist :p Also nur nen #TOOL hinter die REL Bewegung. Danke!

Hallo Leute,
ich habe nun mal eine einfache Frage: Wie kann ich im Werkzeugkoordinatensystem um den TCP drehen. Also wie kann ich die Drehung auf das Werkzeug und nicht auf das Roboterkoordinatensystem beziehen? (Code im Expertenmodus gefragt)

Ich bekomme die Abweichungen ja nicht genau raus für die Achsen. Dafür wollte ich ja alte Justagedaten haben. Und in der .cal sind halt nur die Daten für Achsen 1-3 (wegen dem EMT)

Im Menüpunkt "Inbetriebnahme" --> Justieren gibt es einen Punkt "aktuelle Justagedaten sichern". Wo werden denn da die Daten gesichert?

Hmm schade... dann werden die Werte für die Handachsen oder auch via Messuhren gemessen wohl nicht auch auf dem Rechner gespeichert. Somit sind diese Werte scheinbar nach einer Neujustage verloren.

Die Daten auf der Festplatte in der .cal sind wohl nur zur Kontrolle für das EMT Verfahren vorhanden, für den Zeitpunkt wo justiert wird. Die Kontrolle einer Justage wird wohl ausschließlich über die Daten in der RDW durchgeführt (Soll/Ist)....

Nun ja, schade um die ganze Arbeit.. stehen jetzt einige Überstunden an