Interrupt und Programmverschiebung

  • Hallo Zusammen,


    hier mein erster Beitrag :)


    Ich arbeite aktuell an der Programmierung eines ABB Roboters, Steuerung S4 und OS30 (Hoffentlich sind das ausreichende Infos, ich habe bisher nur mit KUKA gearbeitet).


    Folgendes Problem:

    Ich arbeite an einem Punkt mit Programmverschiebung und möchte im aufgerufenem, verschobenen Programm einen Interrupt mit Trap. Leider löst dieser nicht aus.

    Nur wenn der Interrupt vor der Programmverschiebung angelegt wird, funktioniert dieser. Aufgrund unterschiedlicher Programmaufrufe wäre es super wenn der Interrupt innerhalb der eigentlichen Routine funktionieren würde, nicht in der welche die Programmverschiebung durchführt. Wäre super wenn hier jemand weiterweiß.


    Siehe Code:


    funktioniert nicht:

    Funktioniert:

    Gibt es hier eine Limitierung oder irgendetwas was den Interrupt verhindert?

    Auch bin ich mir nicht sicher ob der Komplette block jedes mal wieder eingegeben werden muss oder würde es reichen den CONNECT Aufruf nur einmal im Haupt Proc auszuführen:

    Code
     CONNECT ibandriss WITH tbandriss;
     ISignalDI di_Band_Okay,0,ibandriss;

    Wenn noch Infos benötigt werden lasst es mich wissen.


    Danke schon mal und viele Grüße

    Andy

  • ANZEIGE
  • Hi Andy


    Arbeite auch viel mit interrupts. Wichtig ist das diese Interrupts schon vorher zugeordnet werden muss. Deswegen funtioniert die 2 version weil Dort am anfang steht beim este version ist Ganz hinten. Kansst diese zuweisung im Main modul auch machen.


    Mfg


    Tamas

  • Hi Tamas,

    Vielen Dank für die schnelle Antwort.

    Leider verstehe ich das nicht ganz...der Aufruf Connect und ISignalDi für den Interrupt ist doch in beiden Versionen jeweils direkt am Anfang einer Routine. Einmal in der Routine verschieben und einmal in der Routine Schl...oder sehe ich das falsch. Wie gesagt bin noch etwas neu auf Abb.

    Viele Grüße

    Andy

  • Einen offensichtlichen Grund scheint es nicht zu geben, ich würde fast die Satzvorlauf verantwortlich machen: durch das IDelete ist der Interrupt möglicherweise schon wieder gelöscht, bevor er überhaupt zum Tragen käme. Ist aber nur 'ne Vermutung.


    Bei ABB ist die Definition der Interrupts bzw. deren Ort nicht so kritisch wie beim KUKA, in Rapid pflegt man Interrupts eher global zu definieren, z. B. in einer Initialisierung am Start der Main-Routine. Der Interrupt ist dann im ganzen Programm bekannt. Definieren darf man ihn nur einmal, man kriegt einen Fehler, wenn man es mehrfach versucht, daher ist die einmalige Definition eigentlich die sinnvollere Variante, auch das Löschen ist unnötig oder sogar kontraproduktiv - löschen tut man ihn nur dann, wenn man ihn unbedingt neu definieren will.


    Für das De/Aktivieren nehmen man ISleep und IWatch.


    Bitte beachten: im Gegensatz zum KUKA, bei dem man die Priorität von Interrupts aussuchen kann und wo Interrupts andere Interrupts unterbrechen können, geht es beim ABB strikt first in - first out.


    Grüße,

    Michael

  • Hallo Michael,

    Danke für die ausführliche Antwort. Das mit dem sleep ist ein guter Hinweis, ich habe das delete verwendet um den Interrupt wieder abzuschalten wenn er nicht benötigt wurde, bisher aber immer nur einen Ablauf getestet. Das werde ich anpassen.

    Am Vorlaufzeiger kann es nicht liegen, der Ablauf ist sehr lange und wir haben den Interrupt gleich am Anfang getestet.

    Grüße Andy

  • Hallo Zusammen,

    wir haben das gestern mal weiter getestet, nur leider komme ich mit dem Interrupt nicht weiter.


    Hier mein Code:

    Das Programm fährt anstandslos, nur auf den Interrupt wird nicht reagiert, auch wen der IWatch überfahren wurde.

    Wenn ich den Interrupt wie im vorherigen Post direkt in das Unterprogramm schreibe funktioniert er auch nur, wenn ich das Programm über Routienen direkt anwähle und abfahre.

    Sobald der aufruf über die Hauptroutiene durchgefürht wird ist der Interrupt ohne funktion.


    Kann das daran liegen das ich von Haupt über mehrere unterrroutienen dahin komme bzw. ist die Steuerung (S4 mit OS30) zu alt.

    Haupt() -> aufruf Bearbeitungsroutiene über Test Case -> aufruf Routiene mit Pdisp -> aufruf Programm in dem der Interrupt wirken soll (über Pdisp)


    Wäre wirklich super wenn hier jemand etwas weiß, mir gehen die Ideen aus.


    Vielen Dank und viele Grüße

    Andy

  • Hm, normalerweise sollte das so gehen. Mit den Uralt-Steuerungen vor S4C+ kenne ich mich aber nicht mehr gut genug aus, um meine Hände dafür ins Feuer zu legen.

    Bist Du ganz sicher, dass der Eingang für die Bandspannung beim Überfahren der IWatch-Anweisung durch den Vorlaufzeiger noch 1 ist?


    Sorry, darüberhinaus bin ich dann ratlos.


    Grüße,

    Michael

  • Uralt-Steuerungen vor S4C+

    RAPID ist RAPID, egal ob S4, S4C+, IRC5, IRC6.
    Auch das alte S4 encode zum Verschlüsseln von Programmen keine Probleme auf der neuen Robotware.
    Selbst auf dem alten Teachpendant würdest Du dich noch zurechtfinden.

  • Andy,
    Du hast zwei Scheifbänder? Ist di_Band_Okay auch mit beiden Schleifbändern verknüpft?

    Ob der Interrupt schaltet, könntest Du während des Abfahren manuel testen, indem Du den Interrupt mit einem Ausgang verknüpfst, den Du dir auf die programmierbaren Tasten legst. Durch drücken der Taste simulierst Du dann den Bandriss.
    Wenn der Roboter in Automatik abfährt, muss Du die Taste für Automatik erlauben.

  • Hi Gerhard,

    danke dir für die Antwort.


    Ja es sind zwei Schleifbänder, der Eingang wird jedoch von der SPS gesetzt und ist bei beiden Bänder der Selbe am Roboter. Den Flankenwechsel haben wir am Bedienteil beobachtet, wie gewünscht von 1 auf 0 aber keine Reaktion des Roboters. Wie gesagt, wenn ich die Routine versch_XXX direkt über "Spezial -> Routinen" aufrufe funktioniert das mit dem Interrupt (wenn er direkt dort deklariert etc. wird...so wie in meinem ersten Post).


    Was ich noch im Handbuch gesehen habe ist das der "Vorwärtsbetrieb" bzw. das benützen der "Stopp" Taste einen Interrupt verhindert. Kann das das Problem sein? Wir fahren das Programm bis zur Verschiebung mit Start, dann mit vorwärts satzweise bis die Suchfahrt startet und dann mit Start weiter (um Kollisionen zu verhindern). Also wenn der Interrupt schalten soll ist der Roboter wieder im normalen Handverfahren mit Start. Ebenfalls im Haupt Programm wenn der Connect und ISignal Befehl ausgeführt wird.


    Ich werde bei Zeiten ein Programm mit der selben Struktur erstellen und mit einem Taster einen Interrupt auslösen um das mal ohne der Anlag zu simulieren. Wenn sich was ergibt gebe ich bescheid.


    Wenn trotzdem wer den Fehler wäre natürlich super.


    Danke euch und Grüße

    Andy

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.

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