Beiträge von lukelukeluke

    Hallo zusammen


    Hat jemand von euch Erfahrung beim Reparieren von Teach Panels von KUKA KRC2? Z.B: Display oder Tastaturmatrix ersetzen? Hat jemand Erfahrung mit eBay Komponenten (LCD ab ca. 350€ von China, Tastatur ab ca. 70€ von China), taugt dies was?


    Bei einem KCP2 (Version ohne ed05) wird sporadisch das LCD schwarz: Hintergrundbeleuchtung ist noch an aber kein Bild mehr. Ist hier am wahrscheinlichsten dass das LCD gewechselt werden sollte oder könnte es auch die Platine sein im KCP?


    Weiss vielleicht jemand ob die KCP1, VKCP2, KCP2 und KCP2ed05 gleiche Teile haben und untereinander getauscht werden können? Z.B. KCP1 sind günstig zu haben... könnte das LCD ins KCP2 gebaut werden?


    Danke für die Hilfe

    Hallo SJX, danke für die Antwort!
    Anbei die Fotos von 1. KRC2, 2. Phoenix Modul (Kabel links von KRC2 kommend, rechts zu Beckhoff), 3. Beckhoff.
    Habe keine FUs in der Nähe. KRC2, Peripherie-Schaltschrank, Kabelkanal und Roboter-Achse sind mit Potentialausgleichsleitungen und Erdungen versehen.
    Was mir nicht genau klar ist: Muss der Schirm auch auf das Gehäuse, z.B. auf der Roboter Achse (oder in der KRC2)? Habe leider im Beckhoff manual nichts dazu gefunden. Bei diesem Beckhoff ist SHIELD (siehe 3. Bild) nicht automatisch mit der Hutschiene (welche ja Potentialausgleich und Erdung drauf hat) verbunden (hab ich gemessen). Sollte ich dort den Kabelschild des Devicenet Kabel auf eine leitende Hutschiene-Klemme grad kurz vor dem Beckhoff machen?
    Vielen Dank für die Inputs!

    Hallo DeviceNet Spezialisten
    Ich habe einen KRC2 Roboter mit einem DeviceNet Netzwerk das folgendermassen aufgebaut ist:


    KUKA MFC2-Karte <--> Phoenix DeviceNet Kabel ca. 5 Meter zu Peripherie Schaltschrank: Phoenix DeviceNet Feldbus Koppler <--> verdrilltes geschirmtes 2-LitzenKabel ca. 10 Meter zu Beckhoff DeviceNet Feldbus Koppler (24V separat gezogen) auf dem Roboter.


    Die Anlage funktioniert meist gut, jedoch kann es vorkommen, dass nach einigen Stunden plötzlich der DeviceNet Fehler 1614 gem. Bild im Anhang kommt. Leider habe ich gerade kein originales DeviceNet Kabel zum Roboter vorhanden (Devicenet verdrillt und geschirmt sowie 24V separat verdrillt und geschirmt), so habe ich einfach ein geschirmtes verdrilltes Kabel für DeviceNet verwendet und 24V daneben mit einem "normalen" 2-Adrigen Kabel gezogen. Abschluss-Wiederstände habe ich auf beiden Seiten 120ohm zw. DeviceNet A und B verwendet, wobei ich mit und ohne Widerstand (z.B. Roboter-MFC2-seitig) probiert habe und den Fehler gleichhäufig habe.
    Hat jemand noch eine Anregung, was generell das Problem sein könnte?


    iosys.ini (Auszug):

    Code
    [CONFIG]
    VERSION=2.00
    [DRIVERS]
    DEVNET=2,dnInit,dndrv.o


    devnet.ini:

    Code
    [krc]
    debug=0
    baudrate=500
    [1]
    macid=1
    [2]
    macid=4

    Hallo zusammen
    Wir haben einen gebrauchten Roboter mit VKRC2 zur Inbetriebnahme wobei der Schaltschrankschlüssel fehlt und uns unbekannt ist (siehe Anhang). Ich habe bis jetzt nur VKRC2 mit normalem Doppelbart-Schlüssel gesehen. Dieser Schaltschrank hat aber ein Schlüssel wie bei einem Mahlschloss.
    Ich habe schon SIEMENS SSG10 und SIEMENS SB30 probiert, das sind die einzigen die ich hier habe, welche eine ähnliche Form haben. Ist hier ein Standardschlüssel verwendet worden oder war es eher ein kundenspezifischer Schlüssel? Hat jemand eine Ahnung wo man diesen bestellen kann? Möchte vermeiden das Schloss auszubohren.
    Danke!

    Hallo zusammen
    Ich habe genau die gleiche Fehlermeldung: "364 ungültige Betriebsart (?)" (und unten in der Statusleiste wo normalerweise T1, T2, EXT oder AUT steht, steht nun "-?-". Dieses Problem tritt mitten in der Produktion auf (nach öffnen der Türen) und der Roboter ist nicht mehr startbar. Dieser voran geht ein 420 Lokaler Sicherheitsstopp"". Ein Neustart der Steuerung löst das Problem jeweils, aber das soll nicht die Dauerlösung sein,.
    Es handelt sich um eine Zelle mit VKRC2 Steuerschrank, KPCed05, KCP2 (nicht VKCP2). Diese läuft im AUT EXT Modus. Was kann diese Fehlermeldung auslösen in mitten der Produktion? In einem anderen Beitrag hab ich gelesen dass es vielleicht mit der Startreihenfolge nach dem Schliessen der Türe zu tun hat... könnte dies sein? Lässt sich leider nicht rekonstruieren...
    Vielen Dank für die Inputs!

    Hallo zusammen
    Hat jemand Tipps, was man sich an der diesjährigen AUTOMATICA (siehe Ausstellerverzeichnis) ansehen sollte?
    Ich schreibe extra ins KUKA-Unterforum weil ich wissen möchte, was die Leute hier gut finden!
    Mich interessieren vor allem Firmen, die bei der Konstruktion von Greifer- und Fördersystemen (z.B. bei AGS Schwope werde ich vorbei schauen) helfen können, für klassische Automation von Roboterzellen. Also Baukasten-Systeme, nicht komplette Integratoren.
    Oder Firmen mit SIEMENS oder SIEMENS-kompatiblen Systemen (z.B. VIPA, Cognex) auch insbesondere solche die OpenSource Software verwenden.
    Die Diskussionsrunde ist eröffnet :)

    [size=2]Hallo zusammen[/size]


    [size=2]Ich habe ein Programm auf einem KR15 mit KRC2 (Win95) Version KR C V4.1.7 SP08 HF1 welches Positionen anfährt, die per Serial Port eingelesen werden. Das Hauptprogramm arbeitet also einen Positions-Puffer mit Fahrbefehlen ab, wobei per INTERRUPT mit CREAD neue Positionen eingelesen und in den Puffer geschrieben werden.[/size]


    [size=2]Das ganze funktioniert soweit gut, nur dass während dem Einlesen über Serial (CREAD) per INTERRUPT resp. während dem Schreiben einer Antwort (CWRITE) die Verfahrbefehle nicht mehr schön verfahren werden, sondern der Roboter ruckelt. Er stoppt also während der Fahrbahn und fährt gleich wieder weiter, als wäre diese Fahrbahn eine Anzahl einzelner Fahrbefehle jeweils mit Vorlaufstopp (sind sie aber nicht).[/size]


    [size=2]Ist dieses Verhalten normal? Oder müsste ein Fahrbefehl weiterlaufen, während der INTERRUPT aufgerufen wird und CREAD oder CWRITE ausführt?[/size]
    [size=2]Könnte es an zu wenig RAM liegen? Unter Info steht "Arbeitsspeicher 127 MB" und "Belastung 79.4%"... Im BIOS wird jedoch nur 64MB angezeigt. CPU ist 433mhz...[/size]



    [size=2]Vielen Dank für eure Tipps und Ideen![/size]

    Konnte das Problem lösen. Es lag tatsächlich am X11 Stecker resp. dessen Belegung (im Schaltschrank den ich zum Vergleich genommen habe war die Brücke 88-106 (+VCC extern / +24V intern) und 89-107 (GND extern / 0 V intern) schon vor dem X11 Stecker auf dem A1/X6 Stecker (auf dem CI3-Extended-Board) gemacht.
    Hilft vielleicht jemand anderem der die gleichen Fehler hat...

    Hallo zusammen
    Hat jemand von euch vielleicht noch weitere Informationen zu diesem Thema?
    Ich bin hier an der Inbetriebnahme von einem (V)KRC2 (KR C V 5.4.14) Schaltschrank mit KPC ed05 und KCP2 Std.ed05 (nicht VW?) der nach dem Hochfahren mit abgezogenem X11 (ohne Brückenstecker) einige Fehler hat, unter anderen:
    - "keine Betriebsart" (unten "-?-" statt z.B. T1)
    - auf dem CI3-Extended Board leuchten nur LED9 und LED14, und nicht LED15 (5V-ESC-Knoten), LED17 (ESC Bus KCP OK), LED20 (ESC Bus KPS OK), LED21 (ESC Bus Lokaler ESC-Knoten OK), LED28 (ESC Bus MFC OK)
    - das Schalten und Auslösen des NOTAUS auf dem KCP2 macht kein Härbares Geräusch (Relais auf dem CI3-Extended-Board)
    - Im HMI kann (nach Benutzergruppe Experte) das Menü "Anzeige > 3 Diagnose > ESC Diagnose" nicht aufgerufen werden: Fehler Nr. 122 "Fehler beim Lesen der Diagnosedaten".
    Bei einem fast identischen Schaltschrank (KRC2 statt (V)KRC2) sieht die verbaute Hardware und Verkabelung eigentlich gleich aus (es sieht also fast aus dass es ein bereits auf KRC2 umgebauter Schaltschrank ist). Dort hab ich aber (ebenfalls nach dem Hochfahren ohne gestecktem X11 Stecker) eine Betriebsart, alle diese 7 LEDs leuchten, das Fiddeln am NOTAUS auf dem KCP2 macht klick-klack auf dem Board (Relais hörbar) und ESC-Diagnose kann aufgerufen werden.
    Wäre für die Fehlersuche dankbar über Unterlagen und Hardwareunterschiede dieser 2 Steuerungstypen und natürlich Inputs zu obigem Verhalten. Danke!

    Verkaufe SCHUNK Greifer für Handling von Vierkant-Profilen. Zelle in welcher Vierkant gefräst und geschliffen wurden, wurde abgebaut, daher nicht mehr benötigt. Kann sicher für andere Zwecke umgebaut werden. War auf einem KUKA KR15/2 montiert, hat also dessen Tool-Aufnahme-Bohrungen. (Roboter nicht verkäuflich! Nur der Greifer.)


    Inkl. Kabelbaum bis zum Roboter-Arm-Kasten (Druckluft, Sensoren, etc.). Es hat 2 Aufnahmen für Vierkant-Profile welche unten eine federgelagerte Platte haben und wahrscheinlich Mechanismen/Sensoren für Profil-Erkennung (Profil dran oder nicht) sowie für Profil-Befestigung haben. Verbaut ist von SCHUNK ein "Kollisions- und Überlastschutz" (Nr. gem. Typenschild "OPS 100-PNP 321130") mit Druckluft-Eingang und Sensor-Ausgang.


    Anfrage bitte per PM oder Antwort. Ich kann auch weitere Bilder senden.

    Hallo
    Ich habe eine Frage zur Umstellung von Kuka auf Fanuc und dies scheint der passende Thread zu sein.


    Hätte eine Option mit Fanuc was zu machen was ich mit Kuka schon mal in der Art gemacht hab. Es geht um das abfahren von Positionen welche via RS232 gesendet werden. Ich kenn mich v.A. mit Kuka KRC2 aus. Ist die Umstellung gut machbar oder erwarten mich gröbere Hürden? Müsste ich noch Lizenzkosten für Software einrechnen? Es geht um Fanuc aus dem gleichen Zeitraum wie KRC2, ca. 10-jährig...


    Danke für die Einschätzung!

    Danke für den Vorschlag. Habe mir auch sowas in der Art gedacht. Wenn ich DeviceNet (z.B. mit CAN-Adapter) oder Serial (Cread / Cwrite) nehme, kann ich ja theoretisch digital übermitteln, also keine Störungsanfälligkeit.
    Habe noch etwas recherchiert: Es gibt einige Möglichkeiten z.B. per Ethernet: RSI oder ETX oder KRL Server. Dies sind aber kostenpflichtige Technologiepakete. Da ich das alles auf KRC2 umsetze, sind diese wahrscheinlich dafür nicht mehr verfügbar, resp. es lohnt nicht diese zu kaufen.
    Habe noch ein semi-OpenSource Projekt gefunden: https://github.com/aauc-mechlab/JOpenShowVar
    Damit wird ein KUKA Roboter mit einem Android Gerät in Echtzeit gesteuert.

    Hallo zusammen
    Super, dieser Post von 2011 hat mir wahnsinnig geholfen! Habe soeben meinen Ethernet Port an einer (V)KRC2 Steuerung mit Windows 95 in stundenlanger Arbeit zum Laufen gebracht. Der Ansatz war gleich aber die Umsetzung etwas anders, weshalb ich den Lösungsweg hier noch beschreibe. Die Karte wurde ebenfalls in Device Manager nicht angezeigt sondern musste manuell hinzugefügt werden.
    Der Treiber war unter D:\Krc1_cd\Internat\Tools\Network\Mfc2 zu finden. Dort musste man in der Datei Net9000.inf die beiden Zeilen:


    Code
    IOConfig = 20@200-eef%FFE0(3FF::)[font=monospace][/font]
    IRQConfig = 9,3,10,11


    in folgendes ändern:


    Code
    IOConfig = 20@340-eef%FFE0(3FF::)
    IRQConfig = 11


    weil im Device Manager die Werte nicht geändert werden konnten (grau hinterlegt). Dann Neue Hardware hinzufügen mit diesem geänderten Treiber. Die Meldungen, beim Installieren der Treiberfiles, dass viele Dateien bei Windows bereits in einer höheren Version bestehen alle mit "ok" bestätigen, damit die neueren/bestehenden Dateien nicht ersetzt werden. Dann noch IP Adresse festlegen, Rechner neu starten, fertig.
    Referenz für die inf-Datei: https://docs.microsoft.com/de-…l/inf-logconfig-directive
    Die Werte für I/O Range und IRQ konnten mit dem Tool D:\Krc1_cd\Internat\Tools\Network\Mfc2\Diag\Etx.exe überprüft werden (gem. Bild im Anhang). Ich denke damit hätte man auch noch IRQ etc. der Karte ändern können (Hardwaremässig)

    Hallo zusammen
    Ich würde gerne folgendes Umsetzen:
    Eine externe Steuerung (z.B. ein PC / eine SPS) soll laufend neue Positionen generieren und diese an den Roboter übergeben (z.B. in einen Puffer schreiben, der abgearbeitet wird), wobei diese dann angefahren werden. Ich stelle mir vor dass man sowas z.B. in der CNC-Fertigung benötigt, wo die Fahr-Geometrie von einer Steuerung übergeben wird und nicht statisch in src/dat-Dateien programmiert und ausgeführt wird.
    Bisher habe ich nur Erfahrung mit dem Datenaustausch mittels z.B. Profibus an eine SIEMENS S7 Steuerung (z.B. Austausch von boolschen Signalen via "Automatik Extern"). Kann mich jemand in die richtige Richtung weisen, wie man sowas angeht? Braucht es dafür Plugins von KUKA oder ist es mit der Standard-Programmierung zu machen?
    Ich plane dies auf einer (V)KR C2 Steuerung umzusetzen, welche glaube ich die Schnittstellen "DeviceNet (MFC), Ethernet und DeviceNet (LPDN) hat. Am liebsten würde ich die Kommunikation von einem PC via Ethernet machen, könnte mir aber auch vorstellen eine Siemens S7 Steuerung dazwischen zu hängen, da ich Erfahrung damit habe…
    Vielen Dank für eure Hinweise!

    Hallo zusammen


    Ich programmiere seit einiger Zeit auf einer KR C2 Steuerung rum und das funktioniert schon ganz gut.


    Nun möchte ich von einem externen PC ein Programm (z.B. src und dat File) erstellen (dynamisch, aufgrund von User Input) und dieses dann automatisch an den Roboter senden und abspielen. Ein src/dat File kann ich bereits generieren und z.B. per Windows-Freigabe und Batch-Datei auf den Roboter kopieren. Wie kann ich es dann dort aber in den RAM laden, also sozusagen ins KUKA HMI kopieren? Geht dies nur mit der Software "KUKA DirLoader" resp. manuell übers HMI? Es sollte möglichst einfach gehen und ich habe die Software DirLoader nicht und auch kein Budget dazu. Ich kann mir noch folgende Alternativen vorstellen:


    1) Mit so einem Makro-Programm wie z.B: "Mouse Recorder" auf der KR C2 (Windows XP) die Maus- und Tastaturbewegungen zum kopieren eines Files von der HD in die KUKA HMI per Batch-Datei abspielen. Nachteil hierbei ist sicher die Fehleranfälligkeit. Z.B. hab ich bemerkt dass das HMI manchmal einfriert, wenn der PC zu fest mit der Abarbeitung des eigentlichen Roboterprogramms beschäftigt ist.


    2) Eine fortlaufende Übergabe von Positionsdaten per Profibus realisieren: Ich übertrage kein src/dat File sondern habe ein File welches sich laufend neue Positionswerte, die angefahren werden sollen, über Profibus einliest und abarbeitet. Diese sollen aus einer Art Stapel abgearbeitet werden. Nachteil hier ist sicher der Programmieraufwand für diese Kommunikation resp. Abarbeitung von "Jobs" die von Profibus kommen.


    Gibt es weitere Möglichkeiten, hat jemand eine Idee? Ich programmiere im Moment auf KR C2 und möchte u.U. das oben genannte auch auf KR C1 implementieren. Wird dies viel schwieriger weil die Steuerung da viel älter ist?


    Vielen Dank für die Hilfe!

    Hallo.
    Ich verwende KR C2 ed2005 und habe eine Frage zu den $OUT[] Variablen. Ich habe jetzt schon gegoogelt und in Handbüchern nachgeschaut, leider finde ich nirgends, wie viele $OUT[] resp. $IN[] Variablen ich verwenden kann.
    Ich habe z.B. in KUKA den Ausgang 1380 per Profibus auf meine SPS gesendet. Wenn ich nun auf dem KUKA Roboter diesen Ausgang 1380 von Hand Schalte (im Menü Anzeige -> Ein/Ausgäünge -> Digitale Ausgänge) dann wird er auf der SPS angezeigt, dass er geschalten wurde (wie es sein sollte). Wenn ich andererseits im Programm (im SRC-File) diesen Ausgang mit folgendem Kommando schalte:
    $OUT[1380] = TRUE
    Dann passiert gar nichts. Woran kann das liegen? Sind per Programm geschaltene Ausgänge limitiert? Oder funkt mir hier etwas rein, dass den Ausgang für sich benötigt, so dass ich diesen nicht verwenden kann? Z.B. "Automatik Extern" habe ich geprüft, dort werden nur Ausgänge bis ca. 1210 verwendet.
    Vielen Dank für die Hilfe