Beiträge von ROBOter_Nils

Da meine Frage eher in die Kategorie "allgemeines Interesse mit potentiellem Nutzen für spätere Situationen" eingestuft werden kann, gibt es von meiner Seite leider auch keine Rückmeldung in Bezug auf Erfolg oder Nichterfolg.
Ich gebe dir aber in soweit Recht, dass es angebracht ist, sich bei den Helfenden höflichst zu bedanken. Dies möchte ich hiermit gerne nachholen.
Sofern in einem alten Thema die Diskussion für mich relevant ist, sehe ich auch kein Problem darin, dieses aus den tiefen des Forums hervorzuholen. Zumal dieses Thema noch gar nicht alt ist...

Mich würde auch interessieren, ob es für die Installation der Profibuskarte(n) bei der KRC2 einen bestimmten PCI Steckplatz gibt für die verschiedenen Mainboards. Bisher habe ich keinen Unterschied festgestellt bei unterschiedlicher Wahl des Steckplatzes. Ich habe jedoch irgendwo (möglicherweise sogar hier) schon gelesen, dass es dann sporadisch Probleme beim Booten geben kann. Das ist natürlich nicht so schön.

Danke

Wow, grandiose Erklärung! Dank dir.

Hallo Kollegen,

heute ist mir an einem Roboter KR30 HA (KRC2) folgendes aufgefallen:

Verfahre ich im Weltkoordinatensystem den Roboter kartesich in der Z-Achse, bleiben die unter "Anzeige->Istposition->Kartesisch" angezeigten Koordinaten für X und Y nicht konstant. Hätte ich jedoch erwartet...
Der Fehler war über 2m Gesamtstrecke stetig angestiegen und am Ende ca. 0,3mm groß. Dass die Werte etwas "flackern" war mir bekannt, aber eine Abweichung im Zehntelbereich ist mir vorher noch nicht aufgefallen.

Der Kunde macht sich Sorgen, sein HA Roboter sei nicht in Ordnung. Basisinspektionen für Mechanik und Steuerung wurden im April durch KUKA durchgeführt. Ich konnte Ihm seine Sorge nicht vollständig nehmen.

Wie ist das zu erklären? Seht ihr dieses Verhalten auch bei anderen Robotern?

Falls es hilft...
- Last am Flansch ist minimal, kleiner Fräsbohrer mit passenden Lastdaten
- Achsauslage war im "normalen" Bereich, also keine enorme Strecklage

Danke!

Diese Frage stelle ich mir schon sehr lange. Gibt es wirklich keine Möglichkeit den Namen der Registerkarten direkt in der Bedienoberfläche zu ändern?

Hallo Kollegen,

da will ich nochmal nachhaken...

Würde auch gern den Bediener etwas einschränken wollen. Folgendes sollte er NICHT dürfen:
- Programm abwählen
- Satzanwahl
- Touch-Up
- Befehle / Bewegungen einfügen / ändern

Eigentlich soll er nur das Programm zurücksetzen können...

Bei der KRC1/2 ging das über die Dateien menuekeykuka.ini und softkeykuka.ini. Die Anzahl der Anrufe verwirrter Kunden ging mit der Einführung dieser Maßnahmen stark zurück. Das gleiche erhoffe ich mir bei der KRC4...

In der oben vorgeschlagenen authentification.config sehe ich keinen Ansatz das hinzubekommen.
Hat jemand Ratschläge wo und wie das bei der KRC4 geht?

Danke!

Zitat von MLP

Soweit mir bekannt ist, ist die Meldung der Unterspannung normal. Wobei ich 798 nicht in den Fehlermeldungen finde. ...
Er stellt halt einfach fest, dass ihm die Spannung weggenommen wurde.

Du hast Recht. Die Meldung lautet "1223 Quitt Unterspannung PM1". Ich bin da mit der laufenden Nummer der Störmeldung im Logviewer durcheinander gekommen.
Ich kann sie allerdings nur an dem Tag finden, an dem der Justageverlust aufgetreten ist. An den störungsfreien Tagen ist beim Einschalten immer nur folgendes im Log zu finden:

"1002 Steuerungsneustart nach Spannungsabfall"
"10 Hochlauf beendet"

Zitat

Bezüglich des Justageverlusts würde ich mal die RDW in Verdacht nehmen. Ich kenne es, dass nach Hochlauf ein Justageverlust vorliegt, justiert wird und der Roboter normal weiter läuft. Beim erneuten Aus- und Einschalten ist die Justage wieder verloren.

Es passiert halt nur sehr selten. Hat die RDW dann einen schlechten Tag oder wie? Außerdem tritt es (immer?) in Verbindung mit einem Kaltstart auf, obwohl Hibernate eingestellt ist. Wenn die Akkus nicht neu wären hätte ich sie in Verdacht. Wer sorgt in der KRC2 für die Umschaltung von Netz auf Akku beim Ausschalten? Dies wäre dann mein nächster Verdächtiger...

Danke für deine Hinweise!

Hallo Kollegen,

leider plagt mich in unregelmäßigen Abständen immer mal wieder der gefürchtete Justageverlust. Dies nicht nur an einer Anlage sondern an verschiedenen. Zugegeben, es handelt sich ausschließlich um alte KRC1 und KRC2 Roboter, die schon einige Jahre auf dem Buckel haben...

Gerade gestern ruft ein Kunde wieder an wegen Justageverlust. Hierbei handelt es sich um eine ältere KRC2-Steuerung.
Der Kunde stellt abends den Roboter ab und morgens wieder ein. Hibernate ist eingestellt, um dem Kunden den Wiederanstart zu erleichtern.

Doch dann:

• Roboter führt sporadisch Kaltstart statt Hibernate aus


• Kunde ruft an (meistens Sonntag früh am Morgen ), weil Roboter nicht startet


• Per Telefon wählen wir das richtige Programm an


• meist geht es dann normal weiter...


• manchmal verliert der Roboter dann jedoch gleichzeitig komplett die Justage


• 

Im Log habe ich "798 Quitt Unterspannung PM1" gefunden. Dies würde eigentlich für schwache Akkus sprechen!? Diese wurden jedoch schon durch neue ersetzt. Wenn es die Akkus wären müsste der Fehler wohl auch regelmäßiger auftreten. kommt aber nur alle paar Wochen vor. Schlimm genug!

Habt ihr Ideen?
Steht die Störmeldung direkt in Zusammenhang mit den Akkus oder kann es noch etwas anderes sein?
So oft ich es auch versuche, die Kunden mit Klein- und Kleinstanlagen lassen sich nicht dazu überreden den Roboter immer eingeschaltet zu lassen...

Zitat von arosafahrer

Bei den verschiedenen Varianten die man bisher gelesen hat... welche ist den nun sinnvoll oder "korrekt" ?

Moin,

ich kann nun zumindest für V8.2.20 die Methode von Hermann bestätigen (Stichworte X66, KLI, KLIConfig.xml). In allen Schränken die wir hier haben ist die KLI nach unten an das Steckerfeld als X66 geführt.

Ein Roboter wurde nun nachgerüstet mit V8.2.22. Und schon bei diesem kleinen Versionssprung verhält sich der Roboter in Bezug auf Remotedesktop wieder anders als seine Kollegen mit V8.2.20.

Bei diesem Roboter kommt die RDP-Verbindung zwar zustande (ich sehe für ein paar Sekunden das HMI auf meinem Notebook), dann jedoch scheint sich das SmartPad die Verbindung wieder zu "holen". Am Notebook bekomme ich eine Meldung, dass die Verbindung getrennt wurde. Die Roboter mit V8.2.20 haben das nicht gemacht. Dort blieb die RDP-Verbindung so lange bestehen, bis ich sie am Notebook selbst beendet habe oder jemand das SmartPad mittels Schlüsselschalter neu verbunden hat.

Die KLIConfig habe ich verglichen, da gibt es keine Unterschiede. Weiß jemand wo der Unterschied liegen könnte?

Danke!

Zitat von SJX

Da muss ich Hermann komplett unterstützen betreffend X47.

Zu X66 ( ja KLI) bei V8.2.x (V8.3 ?):
KLIconfig.xml:
Linie:
<NATRule>rdr [GlobalNatInterface] [addr] port 3389 -> [host:WINDOWS] port 3389 tcp proxy RemoteIP</NATRule>
in
<NATRule>rdr [GlobalNatInterface] [addr] port 3389 -> [host:WINDOWS] port 3389 tcp</NATRule>

dann sollte RDP laufen über KLI.
Aber Achtung: Bei Änderungen der Netzwerkeinstellungen am Smartpad wird ja die KLIConfig neu generiert. Dann ist dies wieder drin. Die Änderung selbst kannst in WoV machen und überspielen.

Alles anzeigen

Super,

das ist, was ich als nächstes versuchen werde...

Recht herzlichen Dank für die sehr schnelle und sogar bebilderte Antwort!!!

Zitat von kasperkopp

Schau mal in den 3.Post, aber Bilder sagen mehr als ...

Ich habe den dritten Post gelesen. Das Problem scheint zu sein, dass der Reiter "Alternative Konfiguration" nur sichtbar wird, wenn ich im Reiter "Allgemein" auf DHCP stelle. Das wiederspricht jedoch deiner Aussage, dass dort eigentlich die feste IP 192.168.0.1 stehen bleiben soll (wie ich ja selbst auch schon erfahren habe...). Das verträgt sich nicht. Oder ich bin zu blöd und brauche noch mehr Bilder.

Zitat

Alternativ die IP im HMI (für WorkVisual) benutzen.

Das hatte ich schon versucht, jedoch ist keine Verbindung zustande gekommen. Über die X66 konnte ich erfolgreich nach der Adresse pingen. RDP hat jedoch nicht über X66 funktioniert. Über die X47 kam der Ping zu der im HMI eingegebenen Adresse nicht durch...

Bei dir scheint es ja zu gehen, irgendwo muss es einen Unterschied geben. Ich habe hier Roboter mit V8.2.20...

Wäre nochmal sehr dankbar für weitere Hilfe!

Hallo Kollegen,

das Thema ist alt, für mich aber gerade aktuell. Ich möchte an der Frage von Bernhard anknüpfen, weil ich ebenfalls mehrere Roboter in einer Zelle habe und mit RDP zugreifen möchte...

Zitat von Bernhard

Jetzt habe ich allerdings noch eine weitere Anlage in der 3 Kuka Robotern in einer Zelle laufen. Auch diese Roboter möchte ich mir im Fehlerfall anschauen können. [...] Allerdings hätten sie dann ja für die Remotedesktopverbindung alle die gleiche IP (192.168.0.1). Kann man diese Problem umgehen bzw. um konfigurieren?

Wenn ich mich einzeln an der X47 mit dem Notebook einstecke und die RDP-Verbindung mit der Zieladresse 192.168.0.1 starte, funtioniert alles wie gewollt. Das Anlagennetz, in dem die Roboter sind, soll aber im Bereich 192.168.1.XXX liegen. Zudem die Problematik der gleichen Adressen aller Roboter.

Zitat von kasperkopp

1. Jedem Kuka-Rechner eine alternative IP verpassen (natürlich drei verschiedene)

Wo denn bitte schön?
Ich habe in der Windows-Ebene eine einzige Netzwerkverbindung ("Local Area Connection 3") gefunden. Da sie default die 192.168.0.1 hat, denke ich, dass ich hier die Adresse entsprechend ändern muss. Ich habe dann testweise mal eine Adresse aus dem bevorzugten Anlagennetz vergeben (z.B. 192.168.1.123). Ich konnte mich dann auch per RDP mit dem Roboter verbinden, das SmartPanel hingegen konnte sich nicht mehr mit der Steuerung verbinden. Auch nicht, wenn ich die RDP-Verbindung mit dem Notebook wieder getrennt habe. Es blieb eine permanente Verbindungs-Meldung auf dem SmartPad stehen. Das ist natürlich nicht die Lösung...

Könnt ihr mir bitte einen Schubs in die richtige Richtung geben?

Zitat von Blaxxun

Bedeutet dies, dass es in die eine Richtung mit der Verbindung geklappt hat, aber keine Verbindung von OL zu KukaSimPro gibt?

Ist das noch aktuell? (Vermutlich nicht, aber vielleicht hilft es anderen...)

Ich denke deine Vermutung ist richtig.

Versuch mal anstatt 'localhost' den Windows-Namen des SimPro-Rechners bei "Welt" einzutragen. Bei mir funktioniert es so. Wenn ich hingegen localhost drin stehen habe sieht es so aus wie bei dir...

Moin Kollegen,

vielleicht kann mir jemand von euch bei einer Idee helfen...

Dieser Creator- / Deletor-Kram nervt mich häufig, weil die Aufnahme und Abgabe von Komponenten durch den Greifer teilweise recht ungenau ist. Ein Packmuster sieht dann z.B. total unsauber aus. Besser wird es, wenn man große Wartezeiten programmiert, aber das macht den Sinn der Simulation / Präsentation zunichte.

Ich würde gern die Sichtbarkeit von Komponenten mit Ausgängen des Roboter steuern (vermutlich mittels Skript, einen anderen Ansatz sehe ich nicht). Dann könnte ich (um beim Beispiel des Packmusters zu bleiben) die Packstücke eines vorher von mir vorbereiteten Packmusters nach und nach sichtbar machen, während der Roboter die Einzelnen Komponenten an der entsprechenden Position "ablegt". Für das Teil im Greifer würde das gleiche gelten. Der Roboter hat immer ein Teil im Greifer, ich steuere dann nur dessen Sichtbarkeit.

Dies ist nur ein Beispiel, auch in anderen Situationen kann ich mir das sehr praktisch vorstellen, Komponenten variabel sichtbar bzw. unsichtbar zu machen.

Im Reiter "Parameter" gibt es die Checkbox "visible" für jede Komponente, wenn ich doch nur irgendwie da dran kommen könnte...

Wer weiß was

>> Übrigens: Sim Pro 2.2 und Office Lite 8.2 <<

Danke!

Den Inbetriebnahme-Modus hat KUKA bestimmt eingeführt um die Hotline zu entlasten. Bei den ganzen Fragen nach der X11 hier im Forum...

Zitat von Matu

Kennt jemand eigentlich irgendeine Möglichkeit, solche Fehler an KUKA zu melden, oder geht auch das nur über die normale technische Hotline...?

Es gibt auch ein Web-Formular der technischen Hotline. Aber ich persönlich würde den Anruf immer vorziehen...
Ich kenne leider keine weitere Möglichkeit über diese Dinge mit KUKA in Kontakt zu treten.

http://www.kuka-robotics.com/d…line/CST_Hotline_Form.htm

Zitat von SJX

Bei mir kommt noch dazu, dass WorkVisual auch Konfigurationen der I/O Verknüpfung ab und zu einfach eliminiert.

Ja, das ist mir auch aufgefallen. Betrifft aber nur die Verschaltung der Signale, nicht den kompletten Bus-Aufbau. Das Problem existiert bei mir, wenn ich beim Vergleich der Projekte die Daten von der Steuerung hole (bzw. "merge"). Vollständige Projekte, die ich in die Steuerung lade, sind dort aber bis jetzt auch immer vollständig angekommen. Ich lasse jetzt beim Merge von der Steuerung einfach alles was die EA-Konfiguaration betrifft aus. Schön ist das aber nicht...

Jetzt bin ich leider doch nochmal auf Probleme gestoßen...

• Ziel: Ich möchte das offline bearbeitete Projekt eines Roboters aus der Zelle von WorkVisual in die Steuerung übertragen
  


• andere Roboter der Zelle im selben Projekt sind in WorkVisual angelegt (und auch fertig konfiguriert), jedoch momentan ausgeschaltet oder nicht im Netzwerk
  


• es gibt demnach Steuerungen im Projekt, die momentan keiner realen Steuerung im Netzwerk zugeordnet sind


• dies führt dazu, dass beim Erzeugen des Codes mit Fehler abgebrochen wird -> Code wird nicht erzeugt (scheinbar für keine der Steuerungen)


• ohne erzeugten Code kein Übertragen des Projektes

Ich musste jetzt erstmal wieder für jede Steuerung ein eigenes Projekt anlegen...
Gibt es dafür eine Lösung? Mache ich wieder etwas falsch?

Danke schonmal...

Riesig!

Hallo Kollegen,

ich möchte eine Zelle mit mehreren Krc4-Steuerungen in einem WorkVisual-Projekt verwalten. Es gibt aber leider Probleme...
Nach Auskunft von Kuka sollte von einem werksneuen Roboter zuerst das aktive Projekt in WV geladen werden, damit alle relevanten Dateien im WV-Projekt sind. Dort kann es dann entsprechend offline bearbeitet und später wieder auf die Steuerung übertragen werden.
Schön und gut, aber es wird immer ein neues Projekt je Steuerung angelegt, wenn ich mit der Funktion "Projekt suchen" arbeite. Wie bekomme ich all meine Steuerungen in ein gemeinsames Projekt geladen?

Gruß und Dank
Nils