Strukturiertes Programmieren durch Programmbausteine

Zuviel Werbung?
-> Hier kostenlos registrieren
@4L+SoftMaschine

Darf ich euch bitten, das mal per PN zu klären und hier nicht weiter Beiträge mit recht wenig direktem Sachbezug zu produzieren!
Das nützt dem TE nun wirklich herzlich wenig.
 
Wenn ich das in SCL mache, habe ich ja keine Wahl als A1.0:=true bzw. A1.0:=false zu machen.
Wichtig ist einzig das nur an einer Stelle zu machen, da alle Bedingungen mit IF /Elsif verknüpfen und am Ende mit einer Else den Ausgang auf false bringen wenn keine Bedinung zutrifft.
So wie ich das lese meine wir ja alle dasselbe, nur drückt es jeder bissle anders aus :)
 
klar geht das auch, aber wie liest sich das dann wenn es komplexer wird

Code:
a1.0:=((e1.0 and e1.1) or e7.0) and (e2.0 and (not e2.1 or 3.1)) and ((e3.0 and not e3.3) or A2.0));

dann schaut da der arme Instanthalter rein und kratzt sich nachdenklich am Hinterkopf :)

edit: Strichpunkt vergessen
 
klar geht das auch, aber wie liest sich das dann wenn es komplexer wird

Code:
a1.0:=((e1.0 and e1.1) or e7.0) and (e2.0 and (not e2.1 or 3.1)) and ((e3.0 and not e3.3) or A2.0));

dann schaut da der arme Instanthalter rein und kratzt sich nachdenklich am Hinterkopf :)

edit: Strichpunkt vergessen

wie sähe das denn Deiner Meinung nach "richtig" aus?
 
Ahhh, ich liebe solche Verknüpfungsorgien. Am liebsten noch in einem FUP Netzwerk das man dann auf A0 ausdrucken muss nur um mal einen Überblick zu bekommen.
Wenn ihr z.B. ein Ventil habt, das in 5 verschiedenen Betriebsmodi der Anlage angesteuert wird. In jedem Modus gibt es 10- 15 Bedingungen die ein Öffnen oder Schließen des Ventils bewirken. Prügelt ihr das wirklich alles in eine einzige Verknüpfung damit ihr den Ausgang für das Ventil nur ein einziges mal im Programm steuert?
 
Ahhh, ich liebe solche Verknüpfungsorgien. Am liebsten noch in einem FUP Netzwerk das man dann auf A0 ausdrucken muss nur um mal einen Überblick zu bekommen.
Wenn ihr z.B. ein Ventil habt, das in 5 verschiedenen Betriebsmodi der Anlage angesteuert wird. In jedem Modus gibt es 10- 15 Bedingungen die ein Öffnen oder Schließen des Ventils bewirken. Prügelt ihr das wirklich alles in eine einzige Verknüpfung damit ihr den Ausgang für das Ventil nur ein einziges mal im Programm steuert?

ich prügel das in 5 Verknüpfungen, die Oder-Verknüpft dann = Ventil ansteuern - ist das falsch? :eek:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ahhh, ich liebe solche Verknüpfungsorgien. Am liebsten noch in einem FUP Netzwerk das man dann auf A0 ausdrucken muss nur um mal einen Überblick zu bekommen.
Wenn ihr z.B. ein Ventil habt, das in 5 verschiedenen Betriebsmodi der Anlage angesteuert wird. In jedem Modus gibt es 10- 15 Bedingungen die ein Öffnen oder Schließen des Ventils bewirken. Prügelt ihr das wirklich alles in eine einzige Verknüpfung damit ihr den Ausgang für das Ventil nur ein einziges mal im Programm steuert?

Natürlich nicht, für so etwas kann man ja Zwischenvariablen nutzen. :)
 
Ich bin nicht grundsätzlich gegen mehrfache Ausgangszuweisungen. Wichtig ist für mich nicht, nur eine Zuweisung zu programmieren, sondern nur eine pro Programmzyklus auszuführen. Das setzt natürlich bedingte FB- oder Aktionsaufrufe voraus, einen Gewinn an Übersichtlichkeit wird man nur bei der Programmierung in ST erzielen. Bei Verwendung anderer Sprachen halte ich auch die Verwendung von Hilfsvariablen für die bessere Variante.
 
selbstverständlich in fup :ROFLMAO:
und wie wärs denn wenn du die 5 modi auf temp-vars oder merker oder sonstiges legts und anschliessend veroderst?
 
Damit, dass man eine Ausgangsvariable nur einmal im Zyklus ansteuern sollte, gehe ich 100% mit. Das diese Ansteuerung aber nur ein einziges mal im Programmcode enthalten sein soll halte ich für übertrieben.
Ich programmiere nur in ST und definiere für die verschiedenen Anlagenteile Zustände. In jedem Zustand kann ich dann Ausgänge beschreiben. Das immer nur ein Zustand je Anlagenteil aktiv ist, dafür sorgt eine CASE -Verzweigung.
Das es in AWL, FUP oder KOP besser ist die Ausgänge wirklich nur an einer Stelle zu steuern leuchtet mir ein. Schrittketten sehen da ja auch anders aus und eine Zustandsorientierte Programmierung lässt sich da vieleicht nich so einfach realisieren.
In AS oder Graph werden Ausgänge idR ja auch direkt im Schritt gesetzt und das kann, je nach Umfang, mehrfach in einer Kette passieren.....

OHHH ha. Das wird ja immer besser.
Und irgendwann wird der Ausgang erst nach einer Sekunde geschaltet weil zu viele Zyklen dazwischenliegen.:confused:

Ich habe keinen blassen Schimmer was du meinst?
 
Zuletzt bearbeitet:
Damit, dass man eine Ausgangsvariable nur einmal im Zyklus ansteuern sollte, gehe ich 100% mit. Das diese Ansteuerung aber nur ein einziges mal im Programmcode enthalten sein soll halte ich für übertrieben.
Ich programmiere nur in ST und definiere für die verschiedenen Anlagenteile Zustände. In jedem Zustand kann ich dann Ausgänge beschreiben. Das immer nur ein Zustand je Anlagenteil aktiv ist, dafür sorgt eine CASE -Verzweigung.

So hatte ich es gemeint. Vielleicht sollte ich weniger schreibfaul sein, um Missverständnissen vorzubeugen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich bin nicht grundsätzlich gegen mehrfache Ausgangszuweisungen. Wichtig ist für mich nicht, nur eine Zuweisung zu programmieren, sondern nur eine pro Programmzyklus auszuführen. Das setzt natürlich bedingte FB- oder Aktionsaufrufe voraus, einen Gewinn an Übersichtlichkeit wird man nur bei der Programmierung in ST erzielen.
Da will ich widersprechen - für mich ist ST das "Übel" schlechthin, weil es dem 10-Minuten-Programmierer erlaubt, völlig planlos die unübersichtlichsten Programme überhaupt zu produzieren.

Was für umständliche, unübersichtliche und unvollständige IF..THEN..ELSIF..-Konstrukte in der Praxis tatsächlich verwendet werden sieht man ja immer wieder im IEC61131-Forumsbereich.

Wenn zu den mehrfachen Ausgangszuweisungen auch noch bedingte Programmausführung dazukommt ... na, viel Spaß bei der Programmanalyse!

Wenn die Ausgangszuweisung an nur einer Stelle zusammengfaßt ist, dann kann ich diese Stelle online beobachten. Ist sie auf mehrere Zuweisungen an mehreren Orten verteilt, dann habe ich kaum eine Chance, denn Grund für unerwartete Zustandsänderungen zu finden, zumal diese S/R-Bedingungen meistens auch noch nur 1 Zyklus lang erfüllt sind.

Harald
 
Da will ich widersprechen - für mich ist ST das "Übel" schlechthin, weil es dem 10-Minuten-Programmierer erlaubt, völlig planlos die unübersichtlichsten Programme überhaupt zu produzieren.

Hallo Harald,

da wiederspreche ich hingegen auch wieder.
Wenn ich so machen AWL oder FUP/KOP verseuchten Programmbaustein ansehe, dann kommt mir auch manches Mal der Brechreiz.

Im allgemeinen finde ich ST wunderbar dazu geeignet Programme 1A zu strukturieren. Natürlich gibt es immer schwarze Schafe aber wie heißt es denn so schön:

"Eine Programmiersprache kann nichts für die unübersichtliche Gestaltung durch den Programmierer,
eine Verbalsprache kann schließlich auch nichts für ihre Schimpfworte" - Kinghelmer, 2014

:ROFLMAO:

Grüße,
Flo
 
wie sähe das denn Deiner Meinung nach "richtig" aus?

Was heißt richtig, viele Wege führen nach Rom.
Da es hier aber um strukturiertes Programmieren geht, ging es mir eher um die Übersicht und Lesbarkeit des Codes. Die Religionsfrage nach der besten Programmiersprache bzw. dem besten Motoröl spielt doch da keine Rolle. Ich kann in jeder Sprache Spaghetti mit Kauderwelsch erzeugen, was dann auch funktioniert, nur sieht dann keiner mehr durch.

Mir gefällt halt eine klar strukturierte und kommentierte IF/ElSIF/ELSE Sache besser als das alles in zig Klammern hintereinander zu schreiben. Klar muß ich dabei aufpassen, aber lieber paar Zeilen mehr wenn es der Verständlichkeit dient.

Ist meine persönliche Meinung und jeder soll das doch machen wie er will.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Da will ich widersprechen - für mich ist ST das "Übel" schlechthin, weil es dem 10-Minuten-Programmierer erlaubt, völlig planlos die unübersichtlichsten Programme überhaupt zu produzieren.
Planlose Programmierung ist wohl keine Frage der Programmiersprache und wird von ST auch nicht in besonderer Weise unterstützt. Das einzige, was man ST in dieser Richtung vorwerfen kann, ist, dass die Sprache dem Standard-IT-Programmierer suggeriert, er könne mit den ihm bekannten Vorgehensweisen auch mal eben eine SPS programmieren. Das ist dann aber ein Problem des Programmierers und nicht der Sprache.

Was für umständliche, unübersichtliche und unvollständige IF..THEN..ELSIF..-Konstrukte in der Praxis tatsächlich verwendet werden sieht man ja immer wieder im IEC61131-Forumsbereich
Leider gibt es dort genug Beispiele, die Deine Meinung stützen. Aber wie schon gesagt, sind dafür die Programmierer verantwortlich.

Wenn zu den mehrfachen Ausgangszuweisungen auch noch bedingte Programmausführung dazukommt ... na, viel Spaß bei der Programmanalyse!
Den habe ich. Standardbeispiel für so eine Programmierung ist ja die hier schon genannte Fallunterscheidung zwischen mehreren Betriebsarten. Wenn ich bei der Fehlersuche weiss, in welcher Betriebsart die Maschine sich befindet (und davon gehe ich mal aus), dann interessiert mich doch auch nur der Teil des Programms, der in ebendieser Betriebsart die Steuerung übernimmt.
 
Zuletzt bearbeitet:
Zurück
Oben