ungültige Betriebsart ?

Zitat von Glöckler

Hallo, i
ch habe bei Krc2 Kuka Robotern mit SW 5.5.7 ab und zu die Meldungen ungültige Betriebsart, QE, SafeRobot Eingänge 3,4 Fehler.

1. Hast du mal den X40 kontrolliert?
2. Hast du zufällig eine ProfiNet-Karte CP1616 im Steuerungs-PC?

Kann auch an einem defekten KCP liegen.

Hallo Sebastian,

was haben diese beiden Steuerungen gemeinsam ?
Gemeinsamer Schutztürkreis, .... ?
Vermutung: irgendeine Fehlverdrahtung bringt das ESC-Board/SafeRobot durcheinander

Zitat von Glöckler

Hallo, Der X40 ist ok und ich hab ne CP1513 drin. Die zwei Roboter die dieses Problem haben, hatten eines Morgens gleichzeitigt Geberfehler.

Ich habe das gleiche Problem mit 2 Robotern:
Je Roboter eine CP1616. Beide als Device & Controller parametriert.
Beide Roboter mit SafeRob.
Ein Roboter mit KRLXML.
Sobald ich auf das Firmennetzwerk unseres Kunden mit aufstecke, habe ich ein ähnliches Problem.
Fehler SAFE-RDW, Justage verloren, Ungültige Betriebsart usw....

Konnten den Fehler bisher nicht lokalisieren, aber eine IP-Doppelbelegung kann ich ausschliessen.
Ein Update auf die neuste ProfiNet-Version und die neuste CP1616 Firmware hat geholfen. Gestern, hatte ich aber aus unerfindlichen Gründen bei einem Roboter Justageverlust A1. Noch keine Auhnung wieso...

Sebastian,
was machst Du nach so einem Fehler ?
ESC-Reset (Software, Taster auf ESC-Board) oder Kaltstart ?
Kannst Du mir oder der KUKA-Hotline einen aktuellen Verdrahtungsplan der Schutztüren und die Belegung von X11 und X40 zukommen lassen ?

Hmmm, Du hast doch eine CP1513 drin, oder ?

Kannst auch mal bitte in die ESC-Diagnose schauen ob es eine 2-Kanalverletzung gibt ?

Zitat von IrrerPolterer

Ich habe das gleiche Problem mit 2 Robotern:
Je Roboter eine CP1616. Beide als Device & Controller parametriert.
Beide Roboter mit SafeRob.
Ein Roboter mit KRLXML.
Sobald ich auf das Firmennetzwerk unseres Kunden mit aufstecke, habe ich ein ähnliches Problem.
Fehler SAFE-RDW, Justage verloren, Ungültige Betriebsart usw....

Konnten den Fehler bisher nicht lokalisieren, aber eine IP-Doppelbelegung kann ich ausschliessen.
Ein Update auf die neuste ProfiNet-Version und die neuste CP1616 Firmware hat geholfen. Gestern, hatte ich aber aus unerfindlichen Gründen bei einem Roboter Justageverlust A1. Noch keine Auhnung wieso...

Alles anzeigen

Hallo.

Habe mal eine Doku gefunden, sieht aber inoffiziell aus.....

Einschränkungen bei Netzwerkkarten unter VxWorks

• MFC3 ist auf Slot 2 (KUKA - Zählweise) freigegeben und muss zwingend in diesen Slot gesteckt werden.
• 3COM 3C905CX-TX-M ist auf Slot 3 (KUKA - Zählweise) freigegeben und muss zwingend in diesen Slot gesteckt werden.
• Realtek NIC ist auf Slot 6 (KUKA - Zählweise) freigegeben und muss zwingend in diesen Slot gesteckt werden.
• Sollte jemand auf die Idee kommen, nachdem alles läuft, die Netzwerkkarten umzustecken, läuft dann VxWin RT eventuell nicht: es gibt wahrscheinlich Probleme mit TCP/IP-Einstellungen unter XP Embedded. Ein Workaround dazu: Folgende Treiber deinstallieren und neu installieren:
KRC VDH, LPVxwlt2, Shared Memory – Treiber.
• Es ist vorgekommen, dass nach dem Installieren eines USB-CD-Laufwerks, der Shared Memory-Treiber inaktiv wird. Ein Workaround dazu: Im Geräte-Manager den SM-Treiber deaktivieren und dann wieder aktivieren, dann die IP-Adresse wieder einstellen.
• Beim folgenden Fehler „Blue Screen beim Shutdown“, ist ratsam vor dem Shutdown das VxWorks zu stoppen. Dies geht, indem man folgenden Befehl ausführt:
Uploadvxwin.exe –rt –x
Empfehlenswert ist, einen Link mit diesem Befehl auf den Desktop zu legen.
Denkbar wäre auch beim Beenden von BOF, auch das VxWorks automatisch (über Uploader-DLL-Aufruf) zu beenden ???

Hallo,

ich hatte mal mit einer KRC2 V4.1 und ESC-CI-Board mal einen ähnlichen Fehler.
Unser Problem war die SPS.
Die SPS sendet des Softwareeingang $DRIVES_ON wenn die Schutzbereich geschlossen wird. Gleichzeitig wird die das Schütz für die Bedienerschutzeingänge auf X11 angesteuert.
Wenn das Schütz mal etwas länger braucht um anzuziehen ist der Bedienerschutz nicht geschlossen und der Roboter bekommt das Signal $DRIVES_ON worauf das ESC-CI-Board mit einem "Abstutz" reagiert.
Da dadurch auch die Hardwaresignale des Betriebsartenwahlschalters unterbrochen werden entsteht die Fehlermeldung "ungültige Betiebsart".
Die SPS wurde nach einer wochenlangen Suche nach dem Fehler umprogrammiert.
Nun wird $DRIVES_ON erst gesetzt wenn eine Rückmeldung des Bedienerschützes anliegt.

Ich hoffe das das dir hift.

Zum Testen kann der SPS-Programmierer einfach eine Verzögerung für $DRIVES_ON programmieren.

Gruß
notime

Hallo
Das mit dem Geberfehler hatte ich auch schon mal. Nach zwei techniker besuchen konnten wir den fehler nicht lokalisieren. Als dann noch andere seltsame meldungen auftraten habe ich mal angefangen die HArdware nach und nach auszutauschen. Der fehler lag dann im Leistungskabel vom controller zum Roboter. Da es bei dir allerdings an zwei robotern vorkommt
Aber vielleichts hilfts ja doch

Bei BMW mit Softwarestand KRC2 V5.2 taucht dieses Problem ebenfalls an mehreren Robotern auf.
Bisher (letzten 6 Monate) konnte keiner helfen.
Der Bedienerschutz ist geschlossen - nach DrivesON hilft nur noch das drücken des Microschalters auf der ESC.
Nach Quitt u. Co geht's normal weiter.

Das liegt, wie schon weiter oben erwähnt, m.E. daran, dass $Drives_ON zu früh nach Quittieren des NotHalt bzw. Bedienerschutz von der SPS auf 1 gesetzt wird. Einfach das $Drives_ON verzögern! Ggfls. tritt das auch nur dann auf, wenn $Drives_OFF zu diesem Zeitpunkt noch auf 1 ist.

Diese Erfahrung habe ich bei Daimler in Sindelfingen gemacht. (im Anhang ein Dokument, wo der Fehler bezogen auf den Daimler Standard beschrieben wird)

Zitat von IrrerPolterer

Ich habe das gleiche Problem mit 2 Robotern:
Je Roboter eine CP1616. Beide als Device & Controller parametriert.
Beide Roboter mit SafeRob.
Ein Roboter mit KRLXML.
Sobald ich auf das Firmennetzwerk unseres Kunden mit aufstecke, habe ich ein ähnliches Problem.
Fehler SAFE-RDW, Justage verloren, Ungültige Betriebsart usw....

Konnten den Fehler bisher nicht lokalisieren, aber eine IP-Doppelbelegung kann ich ausschliessen.
Ein Update auf die neuste ProfiNet-Version und die neuste CP1616 Firmware hat geholfen. Gestern, hatte ich aber aus unerfindlichen Gründen bei einem Roboter Justageverlust A1. Noch keine Auhnung wieso...

Alles anzeigen

Du sagst, das passiert, wenn du den Netzwerkstecker steckst? Unmittelbar beim Stecken steigt die SafeRDW aus?
Dann könnte ich mir vielleicht vorstellen, es ich ein Masse/Erdungsproblem...

Bei der KRC-Version die an Daimler rausgeht, gibts jedenfalls einen Fehler im Hardwaredesign:
* Die Bezugsmasse der safeRDW-Signale ist nicht mit der Bezugsmasse im Roboterschrank verbunden.
* Die safeRDW kann aufgelegte Signale aus dem KRC-Schrank also nicht sauber auswerten
* sind alle Massen (ext. Steuerspannung und KRC-Spannung) mit PE verbunden gehts (dann sind alle Massen auf geichem Potential)

Vielleicht hift dir der Hinweis....

Hallo notime!
Dein Beitrag hat uns auf die richtige Spur gebracht! und

Wir haben das oben beschriebene Problem damit lösen können

Gruß Enno