Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 1 von 8 123 ... LetzteLetzte
Ergebnis 1 bis 10 von 78

Thema: Strukturiertes Programmieren durch Programmbausteine

  1. #1
    Registriert seit
    31.08.2010
    Ort
    NRW
    Beiträge
    64
    Danke
    8
    Erhielt 0 Danke für 0 Beiträge

    Standard


    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
    Zitieren Zitieren Strukturiertes Programmieren durch Programmbausteine  

  2. #2
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.218
    Danke
    533
    Erhielt 2.696 Danke für 1.948 Beiträge

    Standard

    Ich bevorzuge eher die letztere Möglichkeit.

    hier mal in AWL

    U Auto
    U Mx.1
    O
    U Hand
    U Mx.2
    = Ay.1
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  3. Folgender Benutzer sagt Danke zu Ralle für den nützlichen Beitrag:

    ducati (27.05.2014)

  4. #3
    Registriert seit
    06.01.2005
    Ort
    im schönen Lipperland
    Beiträge
    4.472
    Danke
    498
    Erhielt 1.143 Danke für 736 Beiträge

    Standard

    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
    Früher gab es Peitschen .... heute Terminkalender

  5. #4
    Registriert seit
    13.09.2010
    Beiträge
    2.292
    Danke
    178
    Erhielt 375 Danke für 355 Beiträge

    Standard

    .
    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
    Geändert von SoftMachine (26.05.2014 um 16:26 Uhr) Grund: Ergänzung
    kind regards
    SoftMachine

  6. Folgender Benutzer sagt Danke zu SoftMachine für den nützlichen Beitrag:

    Beck (26.05.2014)

  7. #5
    Registriert seit
    19.01.2007
    Beiträge
    109
    Danke
    14
    Erhielt 7 Danke für 7 Beiträge

    Standard

    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

  8. #6
    Registriert seit
    08.08.2007
    Ort
    Dresden
    Beiträge
    9.648
    Danke
    1.059
    Erhielt 2.046 Danke für 1.627 Beiträge

    Standard

    Zitat Zitat von SoftMachine Beitrag anzeigen
    .
    Ausgänge sollten tunlichst nur an einer Stelle
    gesetzt/rückgesetzt werden
    Ausgänge sollten tunlichst an keiner Stelle gesetzt werden
    Geändert von vierlagig (26.05.2014 um 07:27 Uhr)
    [SIGNATUR]
    Ironie setzt Intelligenz beim Empfänger voraus.
    [/SIGNATUR]

  9. #7
    Beck ist offline Benutzer
    Themenstarter
    Registriert seit
    31.08.2010
    Ort
    NRW
    Beiträge
    64
    Danke
    8
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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

  10. #8
    Registriert seit
    13.09.2010
    Beiträge
    2.292
    Danke
    178
    Erhielt 375 Danke für 355 Beiträge

    Standard

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

    Beck

    Zitat Zitat von vierlagig Beitrag anzeigen
    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.
    kind regards
    SoftMachine

  11. #9
    Registriert seit
    08.08.2007
    Ort
    Dresden
    Beiträge
    9.648
    Danke
    1.059
    Erhielt 2.046 Danke für 1.627 Beiträge

    Standard

    Zitat Zitat von SoftMachine Beitrag anzeigen

    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!

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

    hier noch ein Lesetipp: Schrittkettenprogrammierung und Ausgänge sicher schalten
    [SIGNATUR]
    Ironie setzt Intelligenz beim Empfänger voraus.
    [/SIGNATUR]

  12. #10
    Registriert seit
    03.04.2008
    Beiträge
    6.200
    Danke
    237
    Erhielt 815 Danke für 689 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von vierlagig Beitrag anzeigen
    Nette Ironie, danke!

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

    hier noch ein Lesetipp: Schrittkettenprogrammierung und Ausgänge sicher schalten
    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
    "Any fool can write code that a computer can understand.
    Good programmers write code that humans can understand."
    --Martin Fowler

  13. Folgender Benutzer sagt Danke zu bike für den nützlichen Beitrag:

    ducati (27.05.2014)

Ähnliche Themen

  1. Dokumentation erstellte Programmbausteine
    Von husox81 im Forum Simatic
    Antworten: 4
    Letzter Beitrag: 19.04.2010, 18:15
  2. Programmbausteine schachteln
    Von Seraph im Forum Programmierstrategien
    Antworten: 9
    Letzter Beitrag: 02.11.2009, 22:59
  3. Strukturiertes bibliotheksfähiges Programm
    Von Snake im Forum CODESYS und IEC61131
    Antworten: 3
    Letzter Beitrag: 15.10.2008, 11:30
  4. Opensource SPS-Programmbausteine
    Von Anonymous im Forum Programmierstrategien
    Antworten: 8
    Letzter Beitrag: 06.01.2006, 08:18
  5. Opensource SPS-Programmbausteine
    Von Der Nörgler im Forum Stammtisch
    Antworten: 9
    Letzter Beitrag: 25.11.2005, 19:52

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •