Arbeitsraumverletzung....?!

  • Hallo miteinander,


    momentan habe ich ein kleines Problem, was ich sehr komisch finde...
    Ich habe mehrere Arbeitsräume definiert, welche auch während des Betriebs nich verletzt werden.


    Leider bekomme ich eine STOP Meldung beim hochfahren des Roboter "Arebitsraumverletzung". Wobei der Roboter während des Betriebs keine Arbeitsraumverletzung an dieser Stelle hatte.
    Mir ist aufgefallen, dass wenn ich den Roboter via Schalter an der Steuerung herunterfahre, also nur die Robotersteuerung. Dann startet der Roboter ohne Arbeitsraumverletzung. Wird die ganze Zelle via Hauptschalter (hier hängt der Sicherheitskreis, etc. mit drauf) heruntergefahren, und anschließend wieder gestartet, so bekomme ich jedesmal STOP Arebitsraumverletzung...


    Wieso ist das so? Hat da jemand einen Tipp für mich... Ich deaktiviere schon alle Arbeitsräume in der SPS.sub, und aktiviere sie nur wenn Sie benötige!


    Gruß
    John

  • Schritt für Schritt zum Roboterprofi!
  • Hallo John,
    dazu ein paar Fragen:
    - Softwareversion ?
    - SafeRobot ?
    - was wird in der Zelle extern mit 24 V versorgt ?
    nehme an, das diese Spannung nur beim Ausschalten der Zelle weggeht

    Wer nach allen Seiten offen ist kann nicht ganz dicht sein

  • Hallo LindePaul,


    SW - Version KRC 7.0.10
    BOF 1.2.5405.0
    KS 7.0.58


    Roboter ist ein KR5 sixx R650


    Die komplette Zelle hat einen 230V Anschluss, dieser geht auf Netzteile, welche wiederum 24V für Schutzeinrichtungen, SPS, etc. rausgibt...


    Gruß
    John

  • Hallo John,


    wie lautet die genaue Meldungsnummer? Ist es eine größer 31000, dann ist das die Arbeitsraumüberwachung der Densoseite ansonsten die von KUKA. Für eine genauere Analyse wäre das noch wichtig.


    Danke,
    Fubini

  • Hallo John,


    Ist es vielleicht 3072?


    Unsere Vermutung für den Fehler ist dann, dass es mit einem schon bekannten Problem der Denso-Antriebstechnik zu tun hat. Beim Hochlauf der Steuerung schickt diese fälschlicherweise gültige Positionen an die KUKA-Seite obwohl die Antriebe noch nicht richtig initialisiert sind. Quasi ist dann die Position der Achsen beim Hochlauf kurzzeitig irgendwo. Zufälligerweise könnte es jetzt sein, dass diese Lage des Roboters einen Arbeitsraum verletzt. Sind daher bei euch auch wirklich alle Arbeitsräume ($AXWORKSPACE[], $CYLWORKSPACE[] und $WORKSPACE[]) deaktiviert?


    Die zylindrischen Arbeitsräume $CYLWORKSPACE sind dabei neu für die Denso-Kinematik ins System gekommen und in den Maschinendaten zum Teil immer aktiv. Das liegt daran, dass die Kinematik sonst aufgrund ihrer Bauweise mit dem eigenen Sockel kollidieren könnte. Bei KUKA Kinematiken ist das so nicht notwendig, da dort bereits über die Lage der Endanschläge der Achsen eine solche Kollision ausgeschlossen werden kann.


    In einem neueren Softwarestand hat Denso dieses Problem inzwischen behoben.


    Gruß
    Fubini

    Einmal editiert, zuletzt von fubini ()

  • Hallo,


    ja es ist die Fehlermeldung 3072, woran erkenne ich ob die SW veraltet ist, bzw. wo muss ich updaten, damit ich diesen Fehler nicht mehr bekomme!


    Wieviele Cycle-Workspaces gibt es, und welche sind standardmäßig aktiviert und wie?



    Gruß
    John

  • Hallo John,


    die zylindrischen Arbeitsräume $CYLWORKSPACE[] findest du in der R1/$Machine.dat gleich nach den achsspezifischen $AXWORKSPACE[]. Wenn ich mich jetzt aus dem Gedächtnis nicht irre sind da die ersten beiden bereits fest einkonfiguriert. Aber am besten du schaust einfach mal selbst nach. Das Handling ist jedenfalls identisch zu den anderen Typen.


    Gruß
    Fubini

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden