Strukturiertes Programmieren durch Programmbausteine

Beck

Level-1
Beiträge
64
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Profis,

macht es Sinn, seinen SPS-Code nach Anwendungsfällen zu sortieren, sofern unterschiedliche Anwendungsfälle auf dieselben Outputs zugreifen?
Beispiel:
Es gibt es eine manuelle Steuerung, bei der Output A durch Taster A und Output B durch Taster B gesteuert wird.
Daneben gibt es aber noch eine Notfallsteuerung, die Output A und Output B setzen soll, wenn ein Notfall eintritt.
Darüber hinaus gibt es noch einen zeitgesteuerten Automatismus, der Output A steuert.

Am liebsten würde ich drei Programmblöcke bilden "Handsteuerung", "Notfall" und "Automation", die alle drei vom Hauptprogramm aufgerufen werden.
Da ich in einem Zyklus Output A und Output B jeweils eindeutig setzen sollte (also nicht zweimal: erst aus, dann sofort wieder ein), darf es nur ein FUP-Netzwerk geben, dass in Output A endet. Oder?

Damit ist eine Strukturierung nach Anwendungsfällen eigentlich nicht möglich. Es bleibt nur, nach Outputs zu sortieren und ggf. ähnliche Outputs in einem Programmbaustein zusammenzufassen.

Oder wird es in der Praxis so gehandhabt, dass man zwar nach Anwendungsfällen gruppiert, in jedem Programmbaustein aber nur eine Hilfsvariable setzt oder löscht und dann im Hauptprogramm die Prioritäten der einzelnen Anwendungsfälle zu einer Antwort "mischt"? Also, z.B. Output A von "Automation" kann durch Output A von "Handsteuerung" überschrieben werden, welcher wiederum durch Output A von "Notfall" überschrieben werden kann.
Oder wird das dann auch nur unnötig komplex?


Wie jeder an dieser Stelle schnell erkennen kann, habe ich keinerlei Praxiserfahrung, bin aber begierig darauf, von Profis zu lernen.

Vielen Dank,

Beck
 
Ich bevorzuge eher die letztere Möglichkeit.

hier mal in AWL

U Auto
U Mx.1
O
U Hand
U Mx.2
= Ay.1
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn das eine Abstimmung ist : letzte Möglichkeit


Ich habe grade eine Anlage von S5 auf S7 umgerüstet. Im alten Programm wurden getrennte Bausteine für Hand- und Automatikbetrieb programmiert und je nach Betriebsart aufgerufen. Kann man so machen aber wenn man z.B. den A0.0 in der Querverweisliste 2x zugewiesen wird ist es schon etwas verwirrend
 
.
Ausgänge sollten tunlichst nur an einer Stelle
gesetzt/rückgesetzt werden, damit die QVL
übersichtlich bleibt.

Ich gehe mal von STEP 7 aus, dort könntest
du es so machen, indem du einen Zweig für
HAND, einen für AUTO und den dritten für den
NOTFALL veroderst.

Die Rücksetzbedingungen baust du ähnlich auf,
für den OUTPUT_B erzeugst du ein weiteres
Netzwerk.


Output_A mit Selbsthaltung

Output_AmitSH.JPG

Outpot_A mit RS-Glied

Output_A.JPG
 
Zuletzt bearbeitet:
Ich tendiere auch zu der 2.ten Varainate

aber in der Praxis findest Du alle nur denkbaren Möglichkeiten.
angefangen
von "alles im OB1"
über Versuche "wir programmieren Objektorientiert in S7"
oder ich programmiere so das keiner durchblickt
bis hin zu "Top so hätte ich es auch gemacht".

für mich ist ein Programm "Strukturiert" wenn ein anderer ohne grosse Erklärungen sich darin zurechtfindet

Beste Grüsse aus
OWL
Norton
 
Hallo SoftMachine,

ich nutze zwar CodeSys und ziehe FUP einem KOP vor. Aber ich habe verstanden, was Du meinst.
Letztlich waren "Hand", "Auto" und "Notfall" ja auch nur Beispiele.
In der Gebäudeautomation könnten es noch mehr werden. So fallen mir folgende Anwendungsbereiche als zu bündelnde Logiken allein mit Fokus auf die Lichtsteuerung ein: "Taster/Lichtszenen", "Visu", "Notfall", "Urlaub/Anwesenheitssimulation", "Alarmanlage".
Im Lichtszenenmodul taucht Lampe 1 ggf. in vier verschiedenen Szenen auf. Sofern das Gebäude im "Urlaubsmodus" ist, wird diese Lampe per Zufallsprinzip abends ein- und ausgeschaltet. Im Alarmfall soll sie blinken. Im Notfall dauerleuchten. Und per Visu und Taster soll all das überschrieben werden können.
Wenn ich alle vier Lichtszenen, die zeitliche Steuerung und das Blinken mit in den gleichen Block code, ist es definitiv nicht mehr leicht lesbar.

Wahrscheinlich ist Folgendes sinnvoll:
1. einen FB Lichtszenen zu haben, der eine Variable xLampe1_szenen setzt oder löscht
2. einen FB Urlaub zu haben, der eine Variable xLampe1_urlaub setzt oder löscht
3. einen FB Alarm zu haben, der eine Variable xLampe1_alarm bei Bedarf blinken lässt
....etc...
Im Hauptprogramm werden die einzelnen xLampe1_* dann - so wie von Dir dargestellt - miteinander verknüpft. Dort muss man dann die Prioritäten festlegen, welches Szenario Vorrang hat. Das ist dann also eine UND/ODER-Verknüpfung, die ggf. noch Flankenübergänge der einzelnen xLampe1_* mitberücksichtigt.

Die Hilfsvariablen blähen das Ganze natürlich sehr auf. Letztlich hat mal aber keine andere Wahl, wenn man den Gesamtzusammenhang lesbar halten will.

Ich bin jetzt hier von der Verwendung von FBs und nicht Funktionen ausgegangen. Funktionen wären vielleicht noch schicker, da man sich globale Hilfsvariablen spart. Aber wenn ein FB "Lichtszenen" Lampe 1, 2, 3 und 4 steuert, ich im Hauptprogramm aber Lampe 1, 2, 3 und 4 völlig getrennt beschreiben möchte, muss ich das doch so tun, oder?

Stimmen mir die Profis zu? Oder würdet Ihr das anders realisieren?


Beck
 
.
...
Stimmen mir die Profis zu? Oder würdet Ihr das anders realisieren?

Beck


Ausgänge sollten tunlichst an keiner Stelle gesetzt werden

@Beck
Ich würde jetzt erstmal klären, was der nach längerer
Abstinenz seit kurzem ins Forum zurückgekehrte
User <vierlagig> dir mit seinem obigen Beitrag für eine
Hilfestellung geben will.
Ich kann mir vorstellen, da kommen sicher fundierte
Hinweise heraus.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich würde jetzt erstmal klären, was der nach längerer
Abstinenz seit kurzem ins Forum zurückgekehrte
User <vierlagig> dir mit seinem obigen Beitrag für eine
Hilfestellung geben will.
Ich kann mir vorstellen, da kommen sicher fundierte
Hinweise heraus.

Nette Ironie, danke! :ROFLMAO:

Ich bleib dabei, ein Ausgang soll nur einmal beschrieben werden und S/R sind nun mal zwei Schreibvorgänge.

hier noch ein Lesetipp: http://www.sps-forum.de/programmierstrategien/21714-schrittkettenprogrammierung-und-ausgaenge-sicher-schalten.html
 
Nette Ironie, danke! :ROFLMAO:

Ich bleib dabei, ein Ausgang soll nur einmal beschrieben werden und S/R sind nun mal zwei Schreibvorgänge.

hier noch ein Lesetipp: http://www.sps-forum.de/programmierstrategien/21714-schrittkettenprogrammierung-und-ausgaenge-sicher-schalten.html

Ausgänge sollen, wie beschrieben, nur einmal zugewiesen werden.
Dann kann man an einer Stelle prüfen, warum ein Ausgang 1 ist oder nicht.
Für die einzelnen Funktionen Hand Automatik Urlaub Tage / Nacht sollten Merker verwendet werden.
Es ist einfacher direkt einen Ausgang an verschieden Stellen zu zuweisen, doch es ist weder schön noch sinnvoll, noch fair für die Nachfolger, die mit dem Programm leben müssen.

Da hat der user <vierlagig> absolut recht.


bike
 
Meine Erfahrung: Schon die Ausdrucksweise "einen Ausgang setzen" zeugt davon, daß die Funktionslogik falsch gedacht wird.

NICHT:
Wenn Taster_A gedrückt wird, dann Lampe_1 setzen und Lampe_2 setzen. Achja, und ganz dahinten auch noch Lampe_27 einschalten und das Rollo_12 schließen. Und vorsichtshalber Lampe_3 ausschalten, aber nur wenn sie an ist... *grauenhaft*
Bei allen nicht genannten Situationen bleiben die Ausgänge unschlüssig in dem Zustand wie sie gerade sind.

SONDERN:
Lampe_1 ist Ein wenn Taster_A gedrückt ist oder Notsituation oder Nachtschaltung aktiv ist oder ...
Bei allen nicht genannten Situationen ist die Lampe automatisch Aus.


Eine Elektroschaltung und ebenso eine Software"schaltung" in einer SPS verarbeitet normalerweise nicht Ereignisse sondern Zustände. Von daher kommt auch die zyklische Abarbeitung eines SPS-Programms.

Bei Programmen welche in der ereignisorientierten Denkweise programmiert sind, muß man bei jeder Programmänderung davon ausgehen, daß neue Fehler drin sind und das Programm müsste KOMPLETT neu getestet werden (was aber objektiv gar nicht möglich ist!). Weil dieses Kreuz-und-quer-setzen auch Programmteile außer Kraft setzen kann, welche man gar nicht angefasst hat. Das letzte Schreiben im Zyklus gewinnt, egal wie sinnvoll die vorherigen Zuweisungen programmiert waren. Bei solchen Programmen ist gegenüber Zustandsverknüpfungen auch die Wahrscheinlichkeit höher, daß noch unentdeckte Fehler im Programm enthalten sind.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Lieber Harald,

handelt es sich nicht um eine Mischung aus Zuständen und Ereignissen?

Anlage nimmt durch Ereignis a den Zustand A an, durch Ereignis b den Zustand B.

Die Ereignisse a,b,[...] sind die eingelesenen Zustände, Kombinationen daraus und entstehen aus Vergleichen zu bekannten Werten.
Am Ende geht es darum, die Zustandsbeschreibung auf die Aktoren zu schreiben - also die Wichtung entsprechend Deiner Ausführungen zu setzen.
 
Ereignisse können in einer vom Programmierer unerwarteten Reihenfolge auftreten (und dadurch wirkungslos bleiben), die dadurch erreichten (Teil-)Zustände bleiben aber meistens bestehen. Wenn der Programmierer die Zustände verknüpft, dann ist es egal in welcher Reihenfolge die sich eingestellt haben.

Natürlich kann man auch Ereignisse verknüpfen (z.B. Flanken), ich wollte aber betonen, daß das in einer einzigen = Zuweisung gemacht werden soll, aber nicht in zig S/R quer übers Programm verstreut.

Harald
 
Ereignisse können in einer vom Programmierer unerwarteten Reihenfolge auftreten (und dadurch wirkungslos bleiben), die dadurch erreichten (Teil-)Zustände bleiben aber meistens bestehen. Wenn der Programmierer die Zustände verknüpft, dann ist es egal in welcher Reihenfolge die sich eingestellt haben.

Ziel sollte es sein, Ereignisse so auszuwerten, dass sie sicher einem Zustand zugeordnet werden können. Und ja, eine erwartete Reihenfolge hat man idR nur in Schrittketten. Nichts desto trotz möchte ich beachtet wissen, dass ereignissgetriggerte Zustandswechsel mindestens auch erkannt werden sollten um den genauen Anlagenzustand verfügbar zu haben.

Aber das hängt alles zu sehr von der Zustand- und Ereignissbegriffdefinition ab, die wir ja nicht geklärt haben. :D

Natürlich kann man auch Ereignisse verknüpfen (z.B. Flanken), ich wollte aber betonen, daß das in einer einzigen = Zuweisung gemacht werden soll, aber nicht in zig S/R quer übers Programm verstreut.

Harald

mein Reden, eine Zuweisung und nicht zwei (S/R) oder mehr.
 
.
Das Thema ist wohl etwas seitwärts gelaufen.
Ich habe da mal den Beitrag #4 auf die Schnelle
ergänzt, um dem TE ein anderes Beispiel zu liefern.
 
Früher habe ich Ausgänge direkt in der Schrittkette Ge/Rückgesetzt, spart ja so schön Tipparbeit. Nach einigen unschönen Scenen auf IBN hab ich mir dann auch angewöhnt, Ausgänge nur mit "=" anzusprechen.

wobei R/S Glieder meiner Meinung nach auch noch akzeptabel sind.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
.
Das Thema ist wohl etwas seitwärts gelaufen.
Ich habe da mal den Beitrag #4 auf die Schnelle
ergänzt, um dem TE ein anderes Beispiel zu liefern.

das nächste Beispiel mit Konfliktpotential.

wie dem auch sei, was war die eigentliche Frage?

Ich bin jetzt hier von der Verwendung von FBs und nicht Funktionen ausgegangen. Funktionen wären vielleicht noch schicker, da man sich globale Hilfsvariablen spart. Aber wenn ein FB "Lichtszenen" Lampe 1, 2, 3 und 4 steuert, ich im Hauptprogramm aber Lampe 1, 2, 3 und 4 völlig getrennt beschreiben möchte, muss ich das doch so tun, oder?

Stimmen mir die Profis zu? Oder würdet Ihr das anders realisieren?

es gibt der Realisierungsmöglichkeiten viele, wie man auch an der Diskussion merkt.
Je nach Umfang des Aktors kann ein FB alle Betriebsarten abarbeiten. Man übergibt die aktuelle Betriebsart und die den Zustand des Aktors beschreibenden Signale und bekommt den Zustandsorientierten Wert entsprechend der vorhergehenden Ereignisse geliefert. Das muss nicht nur das Bit Ein/Aus sein, kann auch noch zusätzlich Langsam Ein oder Schnellgang Ein oder der anzufahrende Positionswert, die Abzufahrende Kurve etc. sein.
 
.
das nächste Beispiel mit Konfliktpotential.

wie dem auch sei, was war die eigentliche Frage?


Lieber Steffen,

die "eigentliche Frage" des Themas steht in Beitrag #1,
mit Beitrag #4 habe ich darauf geantwortet.

Du gehst auf den Beitrag #7 vom TE ein, produzierst
hier Beiträge und betitelst dann in deinem Beitrag #18
meinen Beitrag #4 nachträglich als "Konfliktpotential" ?

Sicher wirst du nochmal lesen und auch darlegen können,
wie du mich mit deiner ausschweifenden Diskussion und
dem Beitrag #7 in Verbindung bringst ?

Gruss
 
.
Lieber Steffen,

die "eigentliche Frage" des Themas steht in Beitrag #1,
mit Beitrag #4 habe ich darauf geantwortet.

Du gehst auf den Beitrag #7 vom TE ein, produzierst
hier Beiträge und betitelst dann in deinem Beitrag #18
meinen Beitrag #4 nachträglich als "Konfliktpotential" ?

Sicher wirst du nochmal lesen und auch darlegen können,
wie du mich mit deiner ausschweifenden Diskussion und
dem Beitrag #7 in Verbindung bringst ?

Gruss

Die Konfliktpotentialfeststellung bezieht sich tatsächlich auf Deinen Beitrag 4. Dann folgt eine sprachliche Trennung und ich gehe auf Beitrag siebn ein ohne auch nur einen Gedanken an Dich zu verschwenden.

Nicht böse sein, dass ich Dich in meiner Antwort auf 7 nicht bedacht habe!
 
Zurück
Oben