Beiträge von zteve

    Wird eine diskrete Sicherheitsschnittstelle wie X11 verwendet löst das Ausschalten am Hauptschalter laut Dokumentation immer einen Nothalt der Gesamtanlage aus.


    Zitat Doku:
    "Wenn die Ethernet-Sicherheitsschnittstelle verwendet wird, erzeugt die KUKA-Sicherheitssteuerung ein Signal, das bewirkt, dass die übergeordnete Steuerung keinen NOT-HALT für die Gesamtanlage auslöst.
    Wenn die Ethernet-Sicherheitsschnittstelle verwendet wird: Der Systemintegrator muss in seiner Risikobeurteilung berücksichtigen, ob die Tatsache, dass das Ausschalten der Robotersteuerung keinen NOT-HALT der Gesamtanlage auslöst, eine Gefahr darstellen kann und wie der Gefahr entgegenzuwirken ist. Wenn diese Betrachtung unterlassen wird, können Tod, Verletzungen oder Sachschaden die Folge sein."


    Profisafe-Signal für Lokaler NOT-HALT (Lokaler NOT-HALT wurde ausgelöst)
    0 = Lokaler NOT-HALT ist aktiv
    1 = Lokaler NOT-HALT ist nicht aktiv


    Damit die übergeordnete Sicherheitssteuerung weiß, daß die KRC4 runterfährt gibt es auf der Profisafe-Sicherheitsschnittstelle das Signal "System Powerdown".


    Und das SmartPad muß entfernt werden, da der Nothalttaster nicht mehr funktioniert.

    zu I.


    Die Variable LSRO_LsrPwr ist durch das Tech-Paket LaserTech fest als analoger Ausgang deklariert.
    Änderst du in der Config die Signaldeklaration auf Bitbereich (SIGNAL LSRO_LsrPwr $OUT[55] to $OUT[70]) gibt's natürlich Folgefehler im LaserTech-Programm.


    Den analogen Ausgang (hier ANOUT[2]) - auf einen Bitbereich des Feldbus legen wird über die E/A-Verschaltung in WorkVisual gemacht.

    Ich hatte auch schon solche Abbrüche, wo ein Stecker nicht sauber verdrahtet war.
    Hast du schon mal versuchsweise die betroffenen Ethernet-Kabel gegen Kaufkabel getauscht?
    Mit dieser Gegenprobe kannst du schnell ausschließen ob es am Schirm, Stecker oder Kabel liegt oder ob es schlecht verlegt wurde.


    Und teste doch mal ob ein Neustart des betroffenen Roboters mit "Dateien neu einlesen" was ändert.


    Viel Erfolg

    Netzwerkanalyse-Tool "Wireshark" (Freeware).


    Der Traffic läuft allerdings direkt zwischen den Teilnehmern ab. Mit einem PC auf dem dann die Software läuft kann man sich nicht einfach einklinken. Die einzige Methode zum Abgreifen des Verkehrs, die ich kenne ist ein managed Switch mit einer Funktion zum Port-Spiegeln.


    Hier ein Link zu einer Übersicht über Diagnosemöglichkeiten:
    http://www.siemens.de/industry…_September2013_Finale.pdf


    Ich hatte mal ein ähnliches Problem.
    Ist der KUKA der Controller der Schweißsteuerung und ist das ein Ausfall vom Typ "Verbindung zum Gerät {Name} abgebrochen" Meldungsnr. 11001?
    Tritt der Ausfall zyklisch auf oder wirklich nur in Automatik?


    ==> ist installiert ;)
    und läuft auch, weil ich meine Greiferfunktionen ja ausführen kann.


    Alles klar.


    Bis zur Version 8.3.8 hat es diese Reg-Einträge ganz sicher noch gegeben.
    Vielleicht hat KUKA das bei späteren Versionen geändert!? Fände ich nicht gut, wenn es diese Möglichkeit nicht mehr gäbe.


    GeorgS
    Na klar, diesen Weg hatte ich ja ganz vergessen. Ist bei KRC4 (bis V8.3.8.) auch noch so.


    Jannnn
    Welche Version?


    Hab die ganze Registry durchsucht nach: CurrentUser, Keytext , etc ... :huh: nichts ...
    In den Dateien im Registry Ordner im Archive war auch nix dergleichen zu finden?


    Sehr merkwürdig!
    Nix für ungut, nur mal sicherheitshalber gefragt: Ist GripperTech überhaupt installiert?
    Steht in der "am.ini" ungefähr folgendes ...


    [TechPacks]
    Gripper-&SpotTech=3.2.0


    Wenn ja, vielleicht ist das Technologiepaket nicht sauber installiert!?! Kannst es ja mal testweise deinstallieren und von D: frisch installieren.

    Habe gerade keinen KRC4 zur Hand, aber anhand eines Archivs (V8.2.19 ) kann ich sehen, daß der Reg-Schlüssel immer noch derselbe ist.
    Du findest die zusätzlichen Registrierungs-Einträge für Technolgiepakete beim KRC4 im Archiv-Hauptverzeichnis unter "Registry".
    Die Datei "CUSOFTWAREVB and VBA Program SettingsKUKATPSPOT.amr" mit Texteditor öffnen.
    Die Schlüssel in der amr-Datei entsprechen nicht zu 100% dem Registrierungsschlüssel in Windows!
    "\CurrentUser" steht für "HKEY_CURRENT_USER".
    Sonst alles identisch.

    1377 Kommandoausführung nicht frei


    Ursache Ein vorangegangenes Kommando ist noch in Bearbeitung.
    Auswirkung Kommando wird nicht ausgeführt.
    Abhilfe - Kommando abbrechen.
    - Warten bis zur Beendigung des vorangegangenen Kommandos.

    Ich habe gerade keinen Rob hier, aber unter C:\KRC\UTILS\REGUTIL\ gibt es eine oder zwei Windows-Reg-Dateien, die - glaube ich mich zu erinnern - irgendwas mit "Tooldirection" im Namen haben.


    Mit einer konnte immer die Option Stossrichtung Z aktiviert werden.


    Vielleicht ist die passende Reg-Datei für dich dabei, oder du schaust dir die/den Registrierungsschlüssel an und passt ihn deinen Anforderungen an.


    Viel Erfolg

    Hallo IrrerPolterer


    Ich habe zwar noch keinen Kuka als Slave konfiguriert, ich glaube aber nicht, daß die Konfiguration sehr viel anders gemacht wird, als die der anderen Slaves.


    Zu beachten ist, daß der Kuka kein Profisafe Controller sein kann, folglich müssten die sicheren IOs auf Null gestellt (KRC4_2), bzw. auf der Module-Seite (KRC4_1) entfernt werden.


    Vielleicht hilft das ja schon weiter.


    Gruß Stefan


    Du könntest auch ein komplettes Image von den Ursprungsanlage aufspielen.


    Vom Aufspielen eines Images von einer anderen KRC4-Steuerung rate ich ab.


    Aus eigener leidvoller Erfahrung und auch wegen dieser Warnung aus der Kuka-Doku:


    "Ein Duplizieren einer bereits resealten Steuerung (Auslieferungszustand)
    ist nicht gestattet und kann z. B. zu Netzwerkproblemen, Blue
    screens etc. führen."

    Danke für deine Antwort. In der Sicherheitssteuerung ist Automatisch aktiviert.


    Ich werde in der Angelegenheit erst mal nichts mehr unternehmen. Wenn ein Techniker an den Robbis war sage ich Bescheid wie es ausgegangen ist.


    Gruß Stefan


    Allerdings hat ein SYS-X44 Fehler damit nichts zu tun. Denn der SYS-X44 ist der Extension Bus und darüber laufen nicht die Safety Boards, sondern EtherCat (Buskoppler, usw.).


    Ah okay, danke für den Hinweis.


    Die Hotline schreibt dazu, daß der SYS-X44 Fehler auf eine Inkonsistenz des aktuellen Bussystems hinweise und die Lösung das Ausstecken der beiden Busleitungen von SIB und SIB EXT sei.


    Allerdings hat das ja nichts gebracht, wie du richtig vermutest hast.


    Die SIBs haben wir natürlich aus dem WV Projekt entfernt, habe ich nur vergessen zu erwähnen.