S5 AWL Programm in FUP übersetzen

Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hab schon lange nichtsmehr geschrieben, daher dachte ich... ich melde mich auch mal zu Wort. :)

Es handelt sich hier um eine Flankenerkennung im Code, wie ihr ja auch schon alle festgestellt habt.

Bei Flankenerkennung ist es oft erwünscht, dass die Steuerungslogik bei jedem Neustart der Steuerung von einem definierten Anfangszustand ausgeht. Nicht-remanente Merker stellen sicher, dass sie bei jedem Einschalten oder Neustart der Steuerung zurückgesetzt werden, wodurch vermieden wird, dass ein vorheriger Zustand fälschlicherweise als neue Flanke interpretiert wird.

Was nicht bedeutet das der M81.x nicht-Remanent ist:

Bei der S5 war die erste Gruppe an Merkerbytes remanent und die zweite Gruppe an Merkerbytes nicht-remanent.

Wie groß die Gruppen sind, liegt an dem Modell:

Bei einer S5-100U ist es z.B. 0.0-63.7 und dann 64.0-127.7
Bei einer S5-115U ist es z.B. 0.0-M127.7 und dann M128.0-255.7
ABER nur wenn die Schalterstellung auf RE steht,
wenn die Schalterstellung auf NR steht gibt es KEINEN remanenten Merker
und das ist auch nur sinnvoll bei intakter Batterie!

Man kann das also so pauschal leider nicht beantworten.

Zum Code:

Steigende Flanke:

Wenn E106.5 von Low zu High wechselt, wird M81.0 gesetzt (= M81.0), da E106.5 aktiv ist (durch U E106.5) und M81.1 zu diesem Zeitpunkt noch nicht gesetzt ist (durch UN M81.1).

Unmittelbar danach wird M81.1 gesetzt (S M81.1), was verhindert, dass M81.0 erneut gesetzt wird, solange E106.5 aktiv bleibt.

Fallende Flanke:

Wenn E106.5 von High zu Low wechselt, wird M81.1 zurückgesetzt (R M81.1), da E106.5 nicht mehr aktiv ist (durch UN E106.5).
Dies ermöglicht es dem System, bei der nächsten steigenden Flanke von E106.5 wieder M81.0 zu setzen.

Der zweite Block funktioniert analog zum ersten, nur mit anderen Adressen (E106.6, M81.3, M81.4).


Für die steigende Flanke kannst du den Zustand von M81.0 abfragen.

Für die fallende Flanke gibt es keinen direkten Merker, der diese Flanke anzeigt.

Stattdessen ermöglicht das Zurücksetzen von M81.1, dass der Prozess für die Erkennung der nächsten steigenden Flanke zurückgesetzt wird.


Es wurde noch ein Beispiel zur Flankenauswertung als Code hier geschrieben und gefragt weshalb der Code hier so kompliziert ist.

Grundsätzlich gibt es verschiedene Modelle zur Flankenauswertung.

Die Verwendung von einer einfachen Zuweisung "=" wie in den anderen, einfacheren, Code und wie hier mit Setzen "S" und Rücksetzen "R"

Bei der einfachen Zuweisung hat man den S- und R- Befehl in einem und kann die Bedingungen für das S- und R- nicht differenziert formulieren. Außerdem ist es für die Leserlichkeit des Codes hervorragend wenn man zwischen dem Setzen und dem Rücksetzen unterscheidet.
Der Code lässt sich außerdem leichter verändern, wenn sich etwas an den Bedingungen ändert.

Zudem bringt es Vorteile wenn man einen Zustand über mehrere Zyklen hinweg überwachen will.

Insgesamt, während der "=" Befehl in einfacheren Anwendungen effizient und angemessen sein kann, stellt er in komplexeren Steuerungsumgebungen, die eine feingranulare Kontrolle und Flexibilität erfordern, eine weniger ideale Wahl dar.
In solchen Fällen sind dedizierte Setz- und Rücksetzbefehle in der Regel vorzuziehen, um eine klarere, sicherere und wartungsfreundlichere Steuerungslogik zu gewährleisten.

Man könnte also sagen, es ist eine Art "Code-Konvention".


Das ist aber nur meine bescheidene Interpretation... Ich hoffe Sie ist angemessen und richtig. :)

Gruß
 
Insgesamt, während der "=" Befehl in einfacheren Anwendungen effizient und angemessen sein kann, stellt er in komplexeren Steuerungsumgebungen, die eine feingranulare Kontrolle und Flexibilität erfordern, eine weniger ideale Wahl dar.
In solchen Fällen sind dedizierte Setz- und Rücksetzbefehle in der Regel vorzuziehen, um eine klarere, sicherere und wartungsfreundlichere Steuerungslogik zu gewährleisten.
Naja ... deine Meinung.
"komplexen, feingranularen S/R-Code" finde ich meistens da, wo die Anlage offenbar erst bei der Inbetriebnahme verstanden wurde und daher ..zig Sonderregeln überwiegen vor einfachen geradlinigen Regeln. Mit S/R läßt sich super unverständlicher Code programmieren, wo man lange zur Analyse braucht, der Code am Ende aber doch meistens nichts bewirkt....
 
Zuviel Werbung?
-> Hier kostenlos registrieren
In solchen Fällen sind dedizierte Setz- und Rücksetzbefehle in der Regel vorzuziehen, um eine klarere, sicherere und wartungsfreundlichere Steuerungslogik zu gewährleisten.
... da muss ich Harald (@PN/DP ) uneingeschränkt zustimmen - ich sehe das aber auch aus der Sicht eines "Fehlersuchenden".
Bei S und R ist, wenn sie für dieselbe Variable mehrfach im Programm verwendet werden (was dann ja meißtens der Fall ist) für den Suchenden meißt nicht mehr nachzuvollziehen woher der jeweilige Befehl gekommen ist - man kann also einen möglichen Fehler nicht mehr ohne Weiteres finden.
Ich hatte schon oft mit Programmen zu tun wo dieselbe Variable dutzende Male im Programm gesetzt und rückgesetzt worden ist.
Bei so etwas würde ich allerdings auch generell sagen, dass die Verwendung von Variablen dem Programmierer nicht wirklich klar gewesen ist - oder es ist eine bei der Inbetriebnahme gewachsene "Struktur" gewesen - wie auch immer - ich halte generell das inflationäre Ändern des Zustands einer Variablen in einem Programm für bedenklich ...
 
Da ist mir ein sauber strukturiertes Programm mit SR-Gliedern, gerne auch über zwei Netzwerke, tausendmal lieber als eine elend lange Verknüpfungskette mit fünf oder sechs Klammerebenen...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Na ... wenn eine Verknüpfungskette so aussieht dann ist da aber auch schon etwas gehörig schief gelaufen - die ist dann natürlich fast genauso schlecht zu diagnostizieren ...
Es geht am Ende ja darum, dass man wissen möchte warum etwas passiert ist ... oder umgekehrt : warum es nicht passiert obwohl es passieren sollte ... das ist dann mit einer Handvoll (oder mehr) S-R's auf dieselbe Variable nur noch sehr schwer herauszubekommen ...
 
Interessante Meinungen, die zum Nachdenken anregen.
Also, ich denke, es ist wie mit jedem Werkzeug: Es kommt darauf an, was man damit macht.

Ich stimme euch zu, wenn man eine Variable an verschiedenen Stellen im SPS-Programm schreibt, wird es unleserlich.

Das Problem ist dabei aber nicht das S/R, sondern dass man überhaupt eine Variable an verschiedenen Stellen beschreibt.

Ich speichere mit S/R-Gliedern z.B. einen Zustand, hervorgerufen durch die steigende Flanke eines flüchtigen Signals, um ihn über einen Zyklus hinweg zu persistieren. Mir würde auch kein schönerer Weg dafür einfallen.

Ich bin davon ausgegangen, dass wir mit einem SR-Glied einen Zustand wie „Band 72 ist mit Fördergut belegt“ speichern und den Zustand mit einem Folgeereignis wie „Band 72 hat abgekippt und auf Band 73 wurde Fördergut erkannt“ zurücksetzen und keinen Spaghetti-Code fabrizieren.

Ich wünsche euch einen guten Rutsch ins neue Jahr.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
„Fördergut belegt“ mit einer Flanke zu erzeugen ist nicht gut. Auch Motten können eine Fotozelle auslösen 🧐.
Bei Fördertechnik kommst du oft nicht um solche Konstrukte herum.
Das Problem ist dabei eigentlich gar nicht das Setzen des Signals, sondern wie stabilisiert sich das Ganze wieder nach einer Fehlauslösung.
Ich hab bei sowas immer irgendwelche Timeouts, Laufzeitüberwachungen oder Ähnliches.
Wir haben aber auch Fördertechnikanlagen wo es dann einen Reset in einem per Chip geschützten Servicemenü gibt. ... Absoluter Mist.
 
Für mich gilt „ belegt“ wenn das entsprechende Band läuft und der Sensor eine gewisse Zeit belegt ist. Damit sind die Motten raus 😀… und vorstehende Folie/Papier am Fördergut auch. ( meistens )
 
Zurück
Oben