Arburg Multi Lift V - Programmieren

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Arburg Multi Lift V - Programmieren

      Hallo Kollegen,
      ich möchte eine frage an die Programmierexperten stellen die mit Arburg Multilift V sich auskennen.
      Bei uns in der Firma benutzen wir seit einigen Jahren einen Multilift V der bestückt die Spritzgussmaschine, entnimmt die fertige Teile die mit Kamera überprüft werden usw..
      Da der Bedienpersonal und Einrichter keine entsprechende Schulung hatten ist es vorprogrammiert
      das es zu Fehler kommen muss.
      Genaugenommen geht es um Handling - Grundposition anfahren. Dies wird auf dem Selogica Pult mit drei Tasten eingeleitet. Voraussetzung dabei ist, das er sich in einer „Sicherer Position“ befindet. Da die so genante „Sichere Position“ schwer einzuschätzen ist weil es handelt sich um eine Sichteinschätzung und grade deswegen besteht hier die Crash Gefahr. Ohne Jegliche Information bezüglich der Position bzw. Bereichs, ist es leider möglich dem Bedienenden die Grundposition einzuleiten, mit fatalen folgen. Wenn das Handling nicht richtig stand, führt das zum ungewollten schaden.
      Hier stellt sich die Frage: Sollte man nicht in dem Fahl die Sichere Position (Achsen Position abfrage ) für das Bedienpersonal so sicher machen wie es geht?

      So konnte es in bestem Fall aussehen:
      • Jegliche versuche die Grundposition anzufahren durch sperren der Tasten und Meldung dass Handling befindet sich nicht an richtige Stelle / Zustand (abfrage aller Achsen, Greifer usw.). Hier wäre nur nur manuelle anfahren als Option frei gegeben.
      • Sichere Bereiche sind durch Freigabe der Referenztasten bestätigt. Sichere Position = Referenzierung der Achsen kann angeleitet werden.
      • Darstellung der Achsenpositionen (Sicher nicht Sicher) auf dem Display um die eventuell manuell anzufahren.

      Ist das überhaupt möglich bei Multi Lift oder ist es schon längst praktiziert und nur bei uns nicht geläufig? Gibt es Vorschriften bzw. Normen wie man Lineare Robot-Systeme zu Programmieren hat, wenn es um dies Thema geht?
      Wie wird das bei euch gelöst?
      Eine anfrage beim Arburg Anwendungstechniker hat zwar nicht dieses Problem gelöst aber, hat er ein-gedeutet dass es möglich ist dies besser (sicherer) als jetziger zustand zu programmieren. Wie man es macht steht in den unterlagen ?( ha, ha. Toll :!:
    • Die "sichere Position" wird bestimmt durch die Arbeitsraumüberwachung. D. h. es sind 3 Räume einprogrammiert in der sich der Multilift bewegen darf, außerhalb fährt er nicht. Es gibt noch unterschiedliche Möglichkeiten wie man einen Crash durch Vorbedingungen bestimmter Achsen verhindern kann, aber das kommt natürlich immer auf den Einzelfall an. Ich frage mich, wie es überhaupt sein kann dass der Handling an einer unsicheren Position steht? Das kann ja eigentlich nur passieren wenn die Maschine nicht mit "Stopp am Zyklusende" angehalten wird?

      Wurde der Multilift von Arburg selbst programmiert?
    •      
    • Es ist bei uns programmiert worden, deshalb bin ich nicht sicher ob es auch richtig ist. Das Handling wie schon erwähnt, ist angehalten worden (kein stopp am Zyklusende). Ich denke denke dass es dadurch die abfrage der Klappachse („C“) ist übersprungen? (wenn so was möglich ist) und die nicht angefahren ist. Ob es stand in überwachten Arbeitsraum kann ich Nachhinein nicht eindeutig sagen.
    • Die Abfrage der C-Achse wurde nicht übersprungen, sondern nicht im Grundstellungsprogramm bzw. der weiteren Überwachung bedacht. Du kannst den Multilift so programmieren, dass er z. B. Position Y nur anfährt wenn die C-Achse in einer bestimmten Position ist. Die Raumüberwachung deckt erstmal nur die X-Y-Z-Achsen ab, in weiteren Menüs kannst du dann z. B. die C-Achse, oder eigentlich im Prinzip auch alles andere als Vorbedingung einstellen. Evtl. wäre es auch sinnvoll die C-Achse im Grundstellungsablauf zu programmieren. Je nach Situation gibt es unterschiedliche Lösungen. Aber das müssten eure Programmierer eigentlich wissen...
    •      
    • Eine Frage hätte ich noch,
      Gibt's es eine Möglichkeit nach einem Vorfall zu überprüfen Mittel Software Anfrage wie es zu einem Crash gekommen ist. Zu welchem Zeitpunkt was gedrückt worden ist und Positionen der Achsen usw.?
      Hat der Service Techniker bzw. Arburg nicht die Möglichkeit dies auszulesen?
    • Soweit mir bekannt, kannst du nur im Einrichtprotokoll sehen wann (Datum/Uhrzeit) was (Hand - > Umrüsten etc.) betätigt wurde.

      Ggf. ist im Alarmprotokoll noch hinterlegt ob eine Achse eine Position nicht erreichen konnte.

      Ob zu jedem Crash Achskoordinaten hinterlegt werden weiß ich nicht, bezweifle es aber. Anrufen und nachfragen kostet aber nichts. ;)
    •      
    • Im Einrichtprotokoll wird jede Tastaturbetätigung, auch mit den eingegebenen Werten vor und nach der Eingabe, festgehalten, sowie auch ggf. Alarmzustände.
      Im Alarmprotokoll wird meistens leider nur eine Alarmmeldung festgehalten, wenn daraus ein Maschinenstop resultiert, bzw. festgelegte Toleranzen nicht eingehalten wurden.
      Als Anhänge mal ein paar mögliche Auszüge aus Protokollen, die an der Maschine angezeigt werden können (Protokolle1) und der unter anderem möglichen Auswertemöglichkeiten, wenn die Maschinen mit einem Leitrechner verbunden sind (Protokolle2). Je nach Softwarestatus (gekaufte Module) des Leitrechners sind die Auswertemöglichkeiten natürlich deutlich unterschiedlich.
      Die Auszüge bitte nur als Muster betrachten! Wir sind ein Labor und haben daher viele Fehlermeldungen, die sich aus der Notwendigkeit der ständigen Parameteränderungen ergeben und daher nicht mit den Protokollen einer Produktion vergleichbar sein werden. Ebenso sind daher viele Toleranzen notwendiger Weise sehr weit gefasst oder sogar deaktiviert und erzeugen daher gar keine "Alarme" und/oder Fehlermeldungen.
      Dateien
      • Protokolle1.pdf

        (29,9 kB, 10 mal heruntergeladen, zuletzt: )
      • Protokolle2.pdf

        (76,11 kB, 11 mal heruntergeladen, zuletzt: )