voll Überraschung habe ich festgestellt, dass Aktionen in Schritten ausgeführt werden, obwohl diese inaktiv sind.
Ich verwende in einem Schritt die Aktion "R boolvariable". Diese Aktion soll natürlich nur ausgeführt werden, wenn der Schritt auch wirklich aktiv ist. Nun habe ich in der Bugliste von Codesys einen Hinweis dazu gefunden dem ich entnehmen kann, dass das so gewollt ist?!!!
Wenn ich die Beschreibung richtig interpretieren heißt das, das man in Aktionen keine Variablen direkt beschreiben kann sondern nur Funktionen über die Qualifier gesteuert aufrufen darf? Was für einen Sinn macht dann eine "R"- Aktion?????
Was ist der "action control block". Wie kann ich Einfluss auf ihn nehmen?
Hier der Text der Bugmeldung:
3760 High >> SFC: Reset action of an inactive step resets output
Reset action of an inactive step resets output.
RID Note: The activation state of a step is not directly linked with the execution of the action. Each action is controled by an implicit action control block. The state of the step is used as input for some inputs of the action control block. Depending on the value of these inputs, the action is executed or not. If a variables name is used instead of an actions name, this variable is linked with the output of the action control block, no matter whether a certain step is active in a certain cycle or not. The action control block does not know anything about any step states!
13.10.2004CoDeSysErrorAsDesigned
14.12.2004
v 23004
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-08-27
Originally created by: Bernhard Werner
Hallo,
da kann man trefflich drüber streiten, ob das sinnvoll ist. Das Problem ist folgendes: es kann mehrere Schritte geben, an denen dieselbe Aktion hängt.
Ob die Aktion nun ausgeführt wird, kann daher nicht vom Zustand eines einzelnen Schritts abhängen.
Deswegen gibt es den Action control block, das ist ein Funktionsblock aus der IECSFC.lib, dessen Implementierung können Sie sich übrigens auch anschauen. Vom Zustand dieses Action control blocks hängt es ab, ob die dazugehörige Aktion aufgerufen wird oder nicht.
Wenn statt einer Aktion direkt eine Variable assoziiert wird, dann fangen die Probleme an.
Klar ist, die Variable sollte dann den Wert TRUE annehmen, wenn eine Aktion an derselben Stelle ausgeführt würde. Aber wann soll die Variable auf FALSE gesetzt werden? Wir können das nur so machen, dass die Variable auf FALSE gesetzt wird, wenn eine Aktion an derselben Stelle nicht ausgeführt würde. Das heisst aber, die Variable wird in jedem
Zyklus geschrieben! Mit dem R-Qualifizierer hat das gar nichts zu tun, sobald eine Variable in der AKtionsliste aufgeführt wird, wird diese in jedem Zyklus geschrieben. Das ist verwirrend geht aber nicht anders.
Aus meiner persönlichen Sicht ist hier in der IEC mal wieder ein logisches Problem aufgetaucht, man hat eine ein bisschen überkandidelte SFC-Spezifikation verfasst und am Ende sagt man lapidar: "... und boolsche Variablen darf man auch verwenden", ohne darüber nachzudenken was das bedeutet.
Zur Praxis: wenn man boolsche Variablen so verwendet, dann sollten die nirgends anders geschrieben werden, wenn man nur lesend auf diese zugreift, dann sollte es kein Problem sein. Oder man setzt die Variable in der Eingangs- oder Ausgangsaktion des Schrittes zurück (oder verwendet gleich die "einfachen" Schritte). Dann passiert ziemlich genau das, was man erwartet.
Grüße,
Bernhard Werner
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm, Streitpunkte sehe ich aus Sicht des Anwenders überhaupt nicht.
Der Anwender erwartet:
R und S Aktionen z.b. werden nur ausgeführt, wenn der Schritt aktiv ist. Der Zustand bleibt bei Verlassen des Schritts erhalten.
N, L und D Aktionen werden ausgeführt wenn der Schritt aktiv ist. Wenn der Schritt verlassen wird, wird das Aktions-Bit zurückgesetzt.
Der Fehler liegt also in der Implementierung:
Die Aktionen inaktiver Schritte dürfen überhaupt nicht bearbeitet werden. Stattdessen müssen bei der Deaktivierung der Schritte die Aktionen letztmalig ausgeführt werden und dabei eventuell zurückgesetzt werden.
Der Tipp für die Praxis ist recht unbrauchbar. Wenn ich in einer Anlage z.B. Zylinder verwende will ich diese natürlich auch an verschiedenen Stellen im Ablauf ansteuern können.
Ok, also IEC-Schritte gar nicht verwenden. Der Nachteil ist, dass die Umsetzung einer simplen N-Aktion in "einfachen" Schritten wesentlich mehr Programmier- und vor allem Klick-Aufwand beim Programm lesen bedeutet.
Bei der Umsetzung der IEC sollte man im Zweifelsfalle vielleicht die Sicht des Anwenders bevorzugen. Er muss sich schließlich am Ende mit dem Produkt abmühen.
Apropos IEC-Schritte: Die minimale Schrittaktivierungszeit hat hier keine Wirkung? Bei mir läuft ein Schritt trotz eingestellter Minimalzeit von 3s direkt weiter.
Gruß Georg Bertram
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-08-28
Originally created by: Bernhard Werner
Hallo,
Dieser Punkt sorgt immer wieder für Verwirrung, ich möchte mir schon Mühe geben darzulegen, warum es nicht anders sein kann wie es ist.
Im Prinzip ist es schon so, wie Sie sich das denken.
Nur: ob eine Aktion ausgeführt werden soll oder nicht, hängt nicht direkt am Zustand eines Schrittes, sondern am Zustand des Action Control Blocks. (das ist IEC).
Denn es können mehrere Schritte gleichzeitig aktiv sein (Parallelverzweigung) und mehrere Schritte die Aktivierung der Aktion bewirken. Auf keinen Fall darf eine Aktion mehrmals in einem Zyklus ausgeführt werden, nur weil eine Aktion an zwei Schritten hängt (IEC!).
Also Schritt x sagt "bitte in diesem Zyklus Aktion A ausführen"
Es sagt aber kein Schritt "bitte in diesem Zyklus Aktion A nicht ausführen". Sondern, wenn kein Schritt sagt "bitte Aktion A ausführen", dann wird Aktion A nicht ausgeführt. (das ist IEC).
Was heisst das nun für Variablen?
Schritt x sagt -> "bitte Variable a auf TRUE setzen"
niemals sagt ein Schritt "bitte Variable a auf FALSE setzen"
sondern,
wenn kein Schritt sagt "bitte Variable a auf TRUE setzen" wird die Variable auf FALSE gesetzt.
Es ist also in ihrem Programm nicht so, dass unerklärlicherweise der RESET auf die Variable ausgeführt wird, sondern weil niemand den Action control block für die Variable bedient, wird diese zurückgesetzt.
Noch ein Beispiel: zwei Schritte x, und y in zwei Parallelen verzweigungen schreiben beide mit dem Qualifizierer N auf die Variable a. a muss TRUE sein, wenn einer der beiden Schritte aktiv ist. Nehmen wir an Schritt x wird deaktiviert und setzt die Variable a zurück, Schritt y ist aber noch aktiv. Dann käme es nach Ihrem Verständnis auf die Reihenfolge der auswertung an ob a am Ende des Zyklus noch TRUE ist oder nicht. Schaue ich mir Schritt x zuerst an, dann ist a TRUE. im anderen Fall ist a FALSE.
ich hoffe, mich jetzt verständlich gemacht zu haben. Es geht hier nicht um eine Interpretation der IEC. Hier geht es wirklich um den Inhalt der IEC.
mit freundlichen Grüßen,
Bernhard Werner
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ich sehe, dass nicht Ihre Umsetzung, sondern die IEC das Problem darstellt. Trotzdem noch ein paar Kommentare:
Bernhard Werner hat geschrieben:
Hallo,
Dieser Punkt sorgt immer wieder für Verwirrung, ich möchte mir schon Mühe geben darzulegen, warum es nicht anders sein kann wie es ist.
Aber das zeigt natürlich schon, dass hier etwas nicht stimmt. Auf jeden Fall sollte das Thema in der Dokumentation intensiv behandelt werden.
[quote]
Nur: ob eine Aktion ausgeführt werden soll oder nicht, hängt nicht direkt am Zustand eines Schrittes, sondern am Zustand des Action Control Blocks. (das ist IEC).
[/qoute]
Und der Zustand des ACB wird bestimmt über den letzten Schritt in der Abarbeitungsfolge in dem die Aktion verwendet wird, wenn ich das jetzt richtig verstanden habe?
[qoute]
Denn es können mehrere Schritte gleichzeitig aktiv sein (Parallelverzweigung) und mehrere Schritte die Aktivierung der Aktion bewirken. Auf keinen Fall darf eine Aktion mehrmals in einem Zyklus ausgeführt werden, nur weil eine Aktion an zwei Schritten hängt (IEC!).
[/qoute]
Ok, IEC. Allerdings würde jeder Programmierer an dieser Stelle sogar erwarten, dass eine Aktion zweimal ausgeführt wird wenn er sie zweimal aufruft!
[qoute]
Noch ein Beispiel: zwei Schritte x, und y in zwei Parallelen verzweigungen schreiben beide mit dem Qualifizierer N auf die Variable a. a muss TRUE sein, wenn einer der beiden Schritte aktiv ist. Nehmen wir an Schritt x wird deaktiviert und setzt die Variable a zurück, Schritt y ist aber noch aktiv. Dann käme es nach Ihrem Verständnis auf die Reihenfolge der auswertung an ob a am Ende des Zyklus noch TRUE ist oder nicht. Schaue ich mir Schritt x zuerst an, dann ist a TRUE. im anderen Fall ist a FALSE.
[/qoute]
Ok, auch IEC. Ich halte es aber für einen leicht nachzuvollziehenden Programmierfehler, wenn jemand versucht in zwei aktiven Schritten auf die gleiche Variable zu schreiben. Dafür muss sich die IEC keine schwer verständliche Umgehungstaktik für ausdenken.
Gruß Georg Bertram
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-08-29
Originally created by: Bernhard Werner
georg.bertram hat geschrieben:
Und der Zustand des ACB wird bestimmt über den letzten Schritt in der Abarbeitungsfolge in dem die Aktion verwendet wird, wenn ich das jetzt richtig verstanden habe?
Nein eben nicht, alle Schritte setzen - je nach Qualifizierer - ein bestimmtes Flag im Action Control block. Die Reihenfolge ist dabei egal, weil alle nur positiv setzen, keiner setzt einen Eingang negativ. Am Ende des Zyklus wird dann ausgewertet. Beim nächsten Zyklus wird der ACB zurückgesetzt und das Spiel beginnt von vorn.
georg.bertram hat geschrieben:
Ok, auch IEC. Ich halte es aber für einen leicht nachzuvollziehenden Programmierfehler, wenn jemand versucht in zwei aktiven Schritten auf die gleiche Variable zu schreiben. Dafür muss sich die IEC keine schwer verständliche Umgehungstaktik für ausdenken.
Na ja, deswegen meine ich ja auch das die IEC hier ein bisschen versponnen ist. Unsere erste Umsetzung, die einfachen Schritte, sind viel geradliniger implementiert, da ist es eben genau so wie man sich das denkt. Schritt ist blau -> Code wird ausgeführt. Schritt ist nicht blau -> Code wird nicht ausgeführt.
Zur Zeitüberwachung noch: eine Minimale Zeit bedeutet, dass der Schritt erst nach dieser Zeit inaktiv werden kann. Die Transition muss dazu aber trotzdem schalten.
eine Maximale Zeit bedeutet, dass der Schritt überwacht wird. Es wird bei Zeitüberschreitung ein Fehlerflag (SFCError) gesetzt. Es wird also nicht das weiterschalten erzwungen, das kann man dann aber programmatisch erreichen. (schauen sie dazu in der Online-Hilfe unter AS-Flags nach).
Gruss,
Bernhard Werner
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo,
voll Überraschung habe ich festgestellt, dass Aktionen in Schritten ausgeführt werden, obwohl diese inaktiv sind.
Ich verwende in einem Schritt die Aktion "R boolvariable". Diese Aktion soll natürlich nur ausgeführt werden, wenn der Schritt auch wirklich aktiv ist. Nun habe ich in der Bugliste von Codesys einen Hinweis dazu gefunden dem ich entnehmen kann, dass das so gewollt ist?!!!
Wenn ich die Beschreibung richtig interpretieren heißt das, das man in Aktionen keine Variablen direkt beschreiben kann sondern nur Funktionen über die Qualifier gesteuert aufrufen darf? Was für einen Sinn macht dann eine "R"- Aktion?????
Was ist der "action control block". Wie kann ich Einfluss auf ihn nehmen?
Hier der Text der Bugmeldung:
3760 High >> SFC: Reset action of an inactive step resets output
Reset action of an inactive step resets output.
RID Note: The activation state of a step is not directly linked with the execution of the action. Each action is controled by an implicit action control block. The state of the step is used as input for some inputs of the action control block. Depending on the value of these inputs, the action is executed or not. If a variables name is used instead of an actions name, this variable is linked with the output of the action control block, no matter whether a certain step is active in a certain cycle or not. The action control block does not know anything about any step states!
14.12.2004
v 23004
Originally created by: Bernhard Werner
Hallo,
da kann man trefflich drüber streiten, ob das sinnvoll ist. Das Problem ist folgendes: es kann mehrere Schritte geben, an denen dieselbe Aktion hängt.
Ob die Aktion nun ausgeführt wird, kann daher nicht vom Zustand eines einzelnen Schritts abhängen.
Deswegen gibt es den Action control block, das ist ein Funktionsblock aus der IECSFC.lib, dessen Implementierung können Sie sich übrigens auch anschauen. Vom Zustand dieses Action control blocks hängt es ab, ob die dazugehörige Aktion aufgerufen wird oder nicht.
Wenn statt einer Aktion direkt eine Variable assoziiert wird, dann fangen die Probleme an.
Klar ist, die Variable sollte dann den Wert TRUE annehmen, wenn eine Aktion an derselben Stelle ausgeführt würde. Aber wann soll die Variable auf FALSE gesetzt werden? Wir können das nur so machen, dass die Variable auf FALSE gesetzt wird, wenn eine Aktion an derselben Stelle nicht ausgeführt würde. Das heisst aber, die Variable wird in jedem
Zyklus geschrieben! Mit dem R-Qualifizierer hat das gar nichts zu tun, sobald eine Variable in der AKtionsliste aufgeführt wird, wird diese in jedem Zyklus geschrieben. Das ist verwirrend geht aber nicht anders.
Aus meiner persönlichen Sicht ist hier in der IEC mal wieder ein logisches Problem aufgetaucht, man hat eine ein bisschen überkandidelte SFC-Spezifikation verfasst und am Ende sagt man lapidar: "... und boolsche Variablen darf man auch verwenden", ohne darüber nachzudenken was das bedeutet.
Zur Praxis: wenn man boolsche Variablen so verwendet, dann sollten die nirgends anders geschrieben werden, wenn man nur lesend auf diese zugreift, dann sollte es kein Problem sein. Oder man setzt die Variable in der Eingangs- oder Ausgangsaktion des Schrittes zurück (oder verwendet gleich die "einfachen" Schritte). Dann passiert ziemlich genau das, was man erwartet.
Grüße,
Bernhard Werner
Hallo,
Hmm, Streitpunkte sehe ich aus Sicht des Anwenders überhaupt nicht.
Der Anwender erwartet:
R und S Aktionen z.b. werden nur ausgeführt, wenn der Schritt aktiv ist. Der Zustand bleibt bei Verlassen des Schritts erhalten.
N, L und D Aktionen werden ausgeführt wenn der Schritt aktiv ist. Wenn der Schritt verlassen wird, wird das Aktions-Bit zurückgesetzt.
Der Fehler liegt also in der Implementierung:
Die Aktionen inaktiver Schritte dürfen überhaupt nicht bearbeitet werden. Stattdessen müssen bei der Deaktivierung der Schritte die Aktionen letztmalig ausgeführt werden und dabei eventuell zurückgesetzt werden.
Der Tipp für die Praxis ist recht unbrauchbar. Wenn ich in einer Anlage z.B. Zylinder verwende will ich diese natürlich auch an verschiedenen Stellen im Ablauf ansteuern können.
Ok, also IEC-Schritte gar nicht verwenden. Der Nachteil ist, dass die Umsetzung einer simplen N-Aktion in "einfachen" Schritten wesentlich mehr Programmier- und vor allem Klick-Aufwand beim Programm lesen bedeutet.
Bei der Umsetzung der IEC sollte man im Zweifelsfalle vielleicht die Sicht des Anwenders bevorzugen. Er muss sich schließlich am Ende mit dem Produkt abmühen.
Apropos IEC-Schritte: Die minimale Schrittaktivierungszeit hat hier keine Wirkung? Bei mir läuft ein Schritt trotz eingestellter Minimalzeit von 3s direkt weiter.
Gruß Georg Bertram
Originally created by: Bernhard Werner
Hallo,
Dieser Punkt sorgt immer wieder für Verwirrung, ich möchte mir schon Mühe geben darzulegen, warum es nicht anders sein kann wie es ist.
Im Prinzip ist es schon so, wie Sie sich das denken.
Nur: ob eine Aktion ausgeführt werden soll oder nicht, hängt nicht direkt am Zustand eines Schrittes, sondern am Zustand des Action Control Blocks. (das ist IEC).
Denn es können mehrere Schritte gleichzeitig aktiv sein (Parallelverzweigung) und mehrere Schritte die Aktivierung der Aktion bewirken. Auf keinen Fall darf eine Aktion mehrmals in einem Zyklus ausgeführt werden, nur weil eine Aktion an zwei Schritten hängt (IEC!).
Also Schritt x sagt "bitte in diesem Zyklus Aktion A ausführen"
Es sagt aber kein Schritt "bitte in diesem Zyklus Aktion A nicht ausführen". Sondern, wenn kein Schritt sagt "bitte Aktion A ausführen", dann wird Aktion A nicht ausgeführt. (das ist IEC).
Was heisst das nun für Variablen?
Schritt x sagt -> "bitte Variable a auf TRUE setzen"
niemals sagt ein Schritt "bitte Variable a auf FALSE setzen"
sondern,
wenn kein Schritt sagt "bitte Variable a auf TRUE setzen" wird die Variable auf FALSE gesetzt.
Es ist also in ihrem Programm nicht so, dass unerklärlicherweise der RESET auf die Variable ausgeführt wird, sondern weil niemand den Action control block für die Variable bedient, wird diese zurückgesetzt.
Noch ein Beispiel: zwei Schritte x, und y in zwei Parallelen verzweigungen schreiben beide mit dem Qualifizierer N auf die Variable a. a muss TRUE sein, wenn einer der beiden Schritte aktiv ist. Nehmen wir an Schritt x wird deaktiviert und setzt die Variable a zurück, Schritt y ist aber noch aktiv. Dann käme es nach Ihrem Verständnis auf die Reihenfolge der auswertung an ob a am Ende des Zyklus noch TRUE ist oder nicht. Schaue ich mir Schritt x zuerst an, dann ist a TRUE. im anderen Fall ist a FALSE.
ich hoffe, mich jetzt verständlich gemacht zu haben. Es geht hier nicht um eine Interpretation der IEC. Hier geht es wirklich um den Inhalt der IEC.
mit freundlichen Grüßen,
Bernhard Werner
Ok,
ich sehe, dass nicht Ihre Umsetzung, sondern die IEC das Problem darstellt. Trotzdem noch ein paar Kommentare:
Aber das zeigt natürlich schon, dass hier etwas nicht stimmt. Auf jeden Fall sollte das Thema in der Dokumentation intensiv behandelt werden.
[quote]
Nur: ob eine Aktion ausgeführt werden soll oder nicht, hängt nicht direkt am Zustand eines Schrittes, sondern am Zustand des Action Control Blocks. (das ist IEC).
[/qoute]
Und der Zustand des ACB wird bestimmt über den letzten Schritt in der Abarbeitungsfolge in dem die Aktion verwendet wird, wenn ich das jetzt richtig verstanden habe?
[qoute]
Denn es können mehrere Schritte gleichzeitig aktiv sein (Parallelverzweigung) und mehrere Schritte die Aktivierung der Aktion bewirken. Auf keinen Fall darf eine Aktion mehrmals in einem Zyklus ausgeführt werden, nur weil eine Aktion an zwei Schritten hängt (IEC!).
[/qoute]
Ok, IEC. Allerdings würde jeder Programmierer an dieser Stelle sogar erwarten, dass eine Aktion zweimal ausgeführt wird wenn er sie zweimal aufruft!
[qoute]
Noch ein Beispiel: zwei Schritte x, und y in zwei Parallelen verzweigungen schreiben beide mit dem Qualifizierer N auf die Variable a. a muss TRUE sein, wenn einer der beiden Schritte aktiv ist. Nehmen wir an Schritt x wird deaktiviert und setzt die Variable a zurück, Schritt y ist aber noch aktiv. Dann käme es nach Ihrem Verständnis auf die Reihenfolge der auswertung an ob a am Ende des Zyklus noch TRUE ist oder nicht. Schaue ich mir Schritt x zuerst an, dann ist a TRUE. im anderen Fall ist a FALSE.
[/qoute]
Ok, auch IEC. Ich halte es aber für einen leicht nachzuvollziehenden Programmierfehler, wenn jemand versucht in zwei aktiven Schritten auf die gleiche Variable zu schreiben. Dafür muss sich die IEC keine schwer verständliche Umgehungstaktik für ausdenken.
Gruß Georg Bertram
Originally created by: Bernhard Werner
Nein eben nicht, alle Schritte setzen - je nach Qualifizierer - ein bestimmtes Flag im Action Control block. Die Reihenfolge ist dabei egal, weil alle nur positiv setzen, keiner setzt einen Eingang negativ. Am Ende des Zyklus wird dann ausgewertet. Beim nächsten Zyklus wird der ACB zurückgesetzt und das Spiel beginnt von vorn.
Na ja, deswegen meine ich ja auch das die IEC hier ein bisschen versponnen ist. Unsere erste Umsetzung, die einfachen Schritte, sind viel geradliniger implementiert, da ist es eben genau so wie man sich das denkt. Schritt ist blau -> Code wird ausgeführt. Schritt ist nicht blau -> Code wird nicht ausgeführt.
Zur Zeitüberwachung noch: eine Minimale Zeit bedeutet, dass der Schritt erst nach dieser Zeit inaktiv werden kann. Die Transition muss dazu aber trotzdem schalten.
eine Maximale Zeit bedeutet, dass der Schritt überwacht wird. Es wird bei Zeitüberschreitung ein Fehlerflag (SFCError) gesetzt. Es wird also nicht das weiterschalten erzwungen, das kann man dann aber programmatisch erreichen. (schauen sie dazu in der Online-Hilfe unter AS-Flags nach).
Gruss,
Bernhard Werner