System Input Busy steht dauerhaft an

    Hallo zusammen,

    ich habe ein Thema, bei dem mir der ABB Support leider nicht weiterhelfen konnte. Es geht um 16 Roboter mit der RW 6.15.03. Es kommt sopradisch (1-2 mal im Monat) vor, dass die Systemeingänge und Systemausgänge "einfrieren". Der Roboter kann dann weder über die SPS, noch über das FP im manuellen Betrieb verfahren werden. In diesen Fällen steht dann der Systemausgang "SystemInputBusy" dauerhaft an. Obwohl keine Signale auf den Systemeingängen anliegen.

    Man kann die Situation nur durch das Neustarten der Robotersteuerung beheben. Danach läuft wieder alles wie gewohnt.

    Hat einer eine Idee, wie es zu einer sochen Situation kommen kann?

    Kann es sein, dass sich die Systemeingänge "aufhängen", wenn die Eingänge der SPS zu schnell wechseln. Wenn ein Werker zum Beispiel den Roboter über das Stations-HMI in die Grundstellung verfahren will und wiederholt schnell auf die Tasten hämmert?

    Gerne auch noch Fragen stellen, um Klarheit zu schaffen.

    Ich bin dankbar für jeden Hinweis von euch...

    Der Kommentar von ABB-Support war "Es ist nicht bekannt, warum der Systemausgang "Systeminputbusy" dauerhaft ansteht. Bzw. wodurch ein solches Verhalten ausgelöst werden kann"

    Grüße DerWerner

    • AD

    Ich denke, Du bist auf der richtigen Spur mit Deiner Vermutung. Oder hängt an einem der Signale noch eine Ereignisroutine mit dran? Das wäre dann noch eher ein Kandidat für eine solche Selbstblockade (Ereignisroutine startet, irgendwas mit Priorität bricht sie ab, Ereignisroutine endet nie - das war so einer der Klassiker, um sich aufzuhängen.) Vielleicht geht das intern auch mit manchen Systemeingängen.

    Eigentlich ist dann aber der SPS-Programmierer anzumeckern. Der sollte ja vernünftige Handshakes machen und nicht einfach die Signale rauskloppen...

    Vielleicht kannst Du mit "Filter Time active/passive" in den Systemparametern der kritischen Eingangssignale was reißen.

    Guten Morgen Programmiersklave,

    ja, es wird eine Eventroutine für das Event "Start" verwendet.

    In dieser wir ein Array von triggdata initialisiert. 1000 Runden in der For-Schleife sind natürlich schon einiges in der Eventroutine.

    Ich kann mir vorstellen, dass das so gemacht wurde, um im Einrichtbetrieb beim Anwählen von Routinen nicht immer das Problem mit undefinierten Triggern zu haben.

    Hab mir jetzt auch schon überlegt, um den Aufruf des Programms "TriggEquip_VA()" in der Eventroutine ein "IF Hand_Mode" zu machen. Weil im Automatikbetrieb müssen die triggdata doch nicht bei jedem Start neu initialisiert werden oder? Meines Wissens sollte das Initialisieren nur nach PZ to Main notwendig sein oder?

    Hoffe meine Gedanken sind soweit verständlich..

    Ups, da bin ich raus. Derart exzessiv habe ich Trigger nie verwendet und somit keine Erfahrung damit.

    Da die Triggdata VAR sind, verlieren sie ihre Initialisierung unter denselben Bedingungen wie alle VAR. Im "normalen" Automatikbetrieb könnte man das Array ganz gewöhnlich zu Beginn des Programms initialisieren, scheint tatsächlich ein Workaround für Handbetrieb zu sein.

    Würde ich tatsächlich so probieren wie Du vorschlägst. Oder - da gibt's noch 'ne Funktion namens "TriggDataValid", keine Ahnung seit wann, nie benutzt, aber damit könnte man im Rest des Programms die Fehler abfangen, bei Bedarf nachinitialisieren und dafür die Ereignisroutine ganz loswerden.

    Interessant auch irgendwie, dass in der Doku die Triggerdefinitionen 'ne Restriktion haben bzgl. Verwendung in Ereignisroutinen. "Start" ist jetzt explizit nicht drin, aber so ganz verstehe ich das nicht...

    • New

    Hallo zusammen,

    hier eine kleine Zusammenfassung zum Abschluss des Themas.

    An der Linie konnte das Aufhängen der Systemeingänge durch wiederholtes Anfordern der Grundstellungsfahrt (SysEingang PZ-Main und Start) reproduziert werden.

    Nachdem die Initialisierung der Triggdata in der Eventroutine "Start" auf den Handbetrieb beschränkt wurde, konnte der Fehler nichtmehr erzeugt werden. Ich gehe davon aus, dass sich die Steuerung aufgehängt hatte, weil die Initalisierung nicht durch war, bevor der erneue Systemeingang "Start" gesetzt wurde.

    Seither ist Ruhe und der Kunde ist zufrieden. Sollte der Fehler erneut aufkommen, werden wir es mit dem Update auf die RW6.15.08 versuchen. Wobei mir ABB ein anderes Fehlerbild bei dem Thema beschrieben hatte und der Kollege auch meinte, dass der Fehler bisher nur bei RW6.15.07 (also der direkten Vorgeängerversion) aufkam.

    Danke an alle, die zum Thema beigetragen haben. ^^:thumbup:

    Grüße DerWerner

ABB Roboter Support Forum

Hilfe und Support für ABB Roboter Programmierung, Konfiguration, Inbetriebnahme finden Sie hier im ABB Roboter Forum. ABB Rapid Programmierung ist einfach, die Roboterforum Community hilft sehr gerne.