AS: Aktion mit P Qualifier nur einmal ausführen

Deutsch 🇩🇪
pischky
2010-03-31
2010-04-21

  • pischky - 2010-03-31

    Hallo,

    erst mal Danke für die Hilfe bei den anderen (blöden) Fragen.

    Hier ist noch eine:

    Ich Programmiere eine Ablaufsteuerung mit IEC-Schritten und habe eine Aktion mit dem Qualifier "P" (Pulse). Diese wird ja nach Doku auch bei Deaktivierung noch einmal (also insgesamt zweimal) ausgeführt (-> 2.2.3 im Handbuch CoDeSys 2.3). Ich will aber sicherstellen das mein Programm-Stück nur einmal durchlaufen wird. Zwei Möglichkeiten:

    1.) Ich definiere ein "setResetTrg : R_TRIG" und schreibe in der Aktion (Name der Aktion ist "SetReset"):

    setResetTrg( CLK := SetReset.x );
IF setResetTrg.Q THEN
   ;; (*dieses hier soll nur einmal durchlaufen werden*)
END_IF;

    2.) Ich habe beim Debuggen gesehen das SetReset._x = FALSE ist beim zweiten Durchlauf. Also sollte auch

    IF SetReset._x THEN
   ;; (*dieses hier soll nur einmal durchlaufen werden*)
END_IF;

    funktionieren. Laut Handbuch ist aber SetReset._x bei IEC-Aktionen nur für "interne Zwecke".

    Was ist den die bessere Lösung?

    Gruß

    Martin

     

  • pischky - 2010-03-31

    Ich stelle beim Testen gerade fest: Lösung 1 funktioniert nur beim ersten Durchlauf nach dem Starten. "setResetTrg" wird ja nicht in jedem Zyklus berechnet

    Gibt es keine elegante Lösung?

     

  • Anonymous - 2010-04-01

    Originally created by: jl

    Hallo!

    Ich löse das immer mit einer boolschen Variablen die ich beim Aufrufen sofort auf TRUE setze.

    Beispiel:

    IF NOT macheAktion THEN

      macheAktion := TRUE;

  (* Anweisungen die Ausgeführt werden sollen *)

    END_IF

    Wenn die Anweisungen nochmal ausgeführt werden sollen, einfach Variable wieder auf FALSE setzen

     

  • Michael Hulsch - 2010-04-19

    pischky hat geschrieben:
    2.) Ich habe beim Debuggen gesehen das SetReset._x = FALSE ist beim zweiten Durchlauf. Also sollte auch
    [code]IF SetReset._x THEN
    ;; (dieses hier soll nur einmal durchlaufen werden)
    END_IF;
    funktionieren. Laut Handbuch ist aber SetReset._x bei IEC-Aktionen nur für "interne Zwecke".
    Was ist den die bessere Lösung?

    Die IEC würde den Action-Q nehmen, den es aber so bei 3S nicht gibt. Die Funktion des Action-Q übernimmt hier der <aktionsname>._x. Man sollte dieses Flag NICHT beschreiben - darin sehe ich die Einschränkung!</aktionsname>

    Man kann dieses Flag lesend nutzen um eben genau so etwas zu erreichen, nämlich festzustellen ob eine Aktion regulär bearbeitet wird, oder sich in der Nachbearbeitungsphase befindet.

    Das Gute an der IEC-SFC ist ja gerade die Nachbearbeitung der Aktionen! Es gibt einem unabhängig von der Transitionslogik die Möglichkeit des "Aufräumens". Wenn man z.B. einen Funktionsblock beschaltet, kann man einfach den <aktion>._X auf den Start-Eingang geben. Wird die Aktion aktiv, ist der <action>._X TRUE, und wenn die Aktion deaktivert wird, z.B. durch das Weiterschalten des Schrittes, wird für einen Bearbeitungszyklus der Baustein mit "FALSE" auch deaktiviert und ist bereit für den nächsten Aufruf.</action></aktion>

    Gruß

    Michael

     

  • pischky - 2010-04-21

    Michael Hulsch hat geschrieben:
    Die IEC würde den Action-Q nehmen, den es aber so bei 3S nicht gibt. Die Funktion des Action-Q übernimmt hier der <aktionsname>._x. Man sollte dieses Flag NICHT beschreiben - darin sehe ich die Einschränkung!</aktionsname>

    Hallo,

    Danke für die genaue Erläuterung.

    Ich habe das jetzt in einer Applikation mit <aktionsname>._x am laufen. Kein Problem soweit.</aktionsname>

    Mit "Action-Q" ist der Aktionsmerker (Q-Ausgang) gemeint. Oder?

    Gruß

    Martin

     

  • Michael Hulsch - 2010-04-21

    pischky hat geschrieben:
    Mit "Action-Q" ist der Aktionsmerker (Q-Ausgang) gemeint. Oder?
    Gruß
    Martin

    Richtig. Den gibt es sogar auch bei CoDeSys, so wie es den ActionControl-FB gibt, aber hat definitiv nicht die gleiche Wirkung, da dem ActionControl-Baustein der "A"-Ausgang fehlt.

    Die Aktionen im SFC werden zwei mal pro Zyklus "gescannt", d.h. die Aktionen, bzw. der ActionControl der Aktionen im Bausteintree werden in alphabetischer Reihenfolge zwei mal bearbeitet. Im ersten Durchlauf werden die Aktionen bearbeitet die sich in der Nachbearbeitung befinden (<aktionsname>.X ist TRUE) und im zweiten Durchlauf die aktiven (<aktionsname>._X ist TRUE). Innerhalb der Aktion ist der <aktionsname>._X nur in der Nachbearbeitungsphase für einen Zyklus FALSE.</aktionsname></aktionsname></aktionsname>

    Die sichtbare Aktionsreihenfolge am Schritt hat also absolut nichts mit der wirklichen Reihenfolge zu tun, wenn sie nicht zufällig in der Reihenfolge ist wie im Baum! Und man sollte beachten das eine Aktion auch nur einmal pro SPS-Zyklus bearbeitet wird, auch wenn sie an mehreren parallelen Schritten gleichzeitig hängt - das Licht wird ja auch nicht heller, wenn man es an zwei Schaltern gleichzeitig anschaltet

    Gruß

     

  • pischky - 2010-04-21

    Also ist ```

    SetReset._x

    gleichbedeutend mit

    SetReset.AC.Q

    ``` ?

    Und der ActionControl-FB ist der SFCActionControl aus Iecsfc.lib ?

    Sehr interessant...

    Gruß

    Martin

     

  • Michael Hulsch - 2010-04-21

    pischky hat geschrieben:
    Also ist SetReset._x gleichbedeutend mit SetReset.AC.Q ?

    Nein, nicht ganz! Der ActionControl selbst weis nichts von der Nachbearbeitung. Der regelt nur ob oder ob nicht bearbeitet wird, in dem der Action.Q im ersten Aktionsscann auf den <aktionsname>.x kopiert wird und im zweiten Scann auf den <aktionsname>._x.</aktionsname></aktionsname>

    pischky hat geschrieben:
    Und der ActionControl-FB ist der SFCActionControl aus Iecsfc.lib ?

    Ja.

    Gruß

     

Log in to post a comment.