Strukturiertes Programmieren durch Programmbausteine

Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn ich so lese, dann stellt sich mir die Frage, warum gibt es flags?
Es ist doch Mist, wenn in verschiedenen Bausteinen ein Ausgang oder flag zugewiesen bzw gesetzt / rückgesetzt werden.
Wo soll ein Instandhalter anfangen Fehler zu suchen?

Und dabei ist es doch völlig egal, in welcher Programmiersprache das Programm erstellt wird.

Und es ist so, dass die Hochsprachenprogrammierer?, die sich als PLC Programmierer profilieren wollen, zuerst einmal die Technik verstehen sollen.

PLC ist eben eine andere Welt und das ist auch gut so.


bike

btw: Also ich kann auch Netzwerke in jeder Sprache schreiben und in in einer Länge, die in keinem Editor angeschaut werden können. Doch muss das sein?
 
Als Beispiel das Thema Betriebzustände. Es gibt AUS/HAND/AUTO/EINRICHTEN. Der Ausgang ist eine Lampe und sie soll ausser bei AUS bei allen anderen Zuständen an sein. Da mach ich die Verknüpfungen in einem FC und setze mir dafür Bits in einem DB oder halt Merker. Wenn ich dann den Ausgang für die Lampe ansteuer sieht das so aus.
Code:
if DB1.DBX0.0       // Auto FC1 Zeile 20
   or DB1.DBX0.1  // Hand FC1 Zeile 40
   OR DB1.DBX0.2 // Einrichten FC1 Zeile 60
   then
   A1.0:=true; // Lampe EIN 
else 
   A1.0:=false; // Lampe AUS
end_if;

Die andere Schreibweise ist ja dasselbe, nur verkürzt. Nur wenn hier einer reinschaut ist es auf Anhieb klar was fehlt bzw. wo was herkommt um weiter zu suchen. Ausserdem kann man besser kommentieren.

Nochmal, es geht mir nicht um irgendwelche Grundsatzdiskussionen, aber ich hab mir früher als Instandhalter oft sowas gewünscht um gerade im Stress früh 3.00 Uhr auf die Schnelle nachschauen zu können. Gerade weil sich das SCL in Step7 beim Beobachten mitunter so zickig hat.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Um mich auch mal hier in der Grundsatzdiskussion einzubringen:
Ich finde dass obiges OR in FUP oder KOP viel übersichtlicher und besser gelöst ist (imho ist es sogar in AWL klarer). Nicht umsonst hat sich für binäre Logiken FUP und KOP durchgesetzt. Bei komplexeren Dingen sieht es natürlich wieder anders aus.
 
Wenn ich so lese, dann stellt sich mir die Frage, warum gibt es flags?
Es ist doch Mist, wenn in verschiedenen Bausteinen ein Ausgang oder flag zugewiesen bzw gesetzt / rückgesetzt werden.
Wo soll ein Instandhalter anfangen Fehler zu suchen?
Klar, meistens beginnt die Fehlersuche beim Ausgang. Wenn der nur an einer Stelle des Programms zugewiesen wird, hat man natürlich einen eindeutigen Einsprungspunkt für die Suche. Aber wie geht es dann weiter? Im Hauptprogramm wird ja etwas stehen wie
Code:
HWAusgang:=(Hand AND HandAusgang) OR (Auto AND AutoAusgang);
Angenommen, Auto=1, AutoAusgang=0. Dann muss ich ja doch in dem Programmteil oder FB weitersuchen, in dem AutoAusgang programmiert ist.

Wenn ich die Ausgangszuweisungen in den FB's für die einzelnen Betriebsarten habe, fange ich mit der Suche auf der anderen Seite an. Erstmal schauen, welche Betriebsart aktiv ist, und dann in den entsprechenden FB springen. Dort habe ich dann alles, was ich brauche, vor mir, inklusive der Ausgangszuweisung.
Ich erhebe für so eine Struktur keineswegs allein selig machenden Anspruch, aber für die Art der Maschinen, die wir bauen, hat sie sich als recht praktikabel erwiesen.
 
@Bapho:
es geht konkret um dieses besipiel!

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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es gibt meist mehr als einen Weg zum Ziel.
Es ist doch aber meist aufwendiger, wenn man in den verschieden Funktionen schauen muss, in welcher der Ausgang aktiviert wird.
Ich finde es persönlich leichter, wenn im Querverweis immer nur eine Position angezeigt wird, an der die Zuweisung erfolgt.
Wenn komplette Funktionen portabel programmiert werden, dann kann man ohne viel zu tun diese verschiedene Projekte einfügen.

Jeder nach seiner Art, denn die einzig glücklich machende Lösung gibt es wohl nicht.


bike
 
So wie ich es oben geschrieben habe, die 3 Zustände in 3 separaten if Zweigen erzeugen und ein Bit setzen, dann nur die Bits und für den Ausgang verknüpfen.
Oder reitest du so drauf rum weil ich ganz hinten eine Klammer zuviel hab?

ich reite nicht darauf rum, schon gar nicht wegen einer Klammer.

Du hast dies als Beispiel für Unübersichtlichkeit ins Feld geführt und musst Dich nun leider an der Übersichtlichkeit messen lassen.
Obiger Extrakt mit den Datenbausteinzugriffen spiegelt nicht das Eingangs erwähnte Beispiel wider.

Wie dem auch sei - ST/SCL ist nach wie vor nach meinem Dafürhalten nicht für ausschweifendere Bitoperationen geeignet, wohl aber für das Arbeiten mit Zustandsentsprechungen im INT-Format so dass man auf so komfortable Befehle wie CASE zurückgreifen kann.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
So wie ich es oben geschrieben habe, die 3 Zustände in 3 separaten if Zweigen erzeugen und ein Bit setzen, dann nur die Bits und für den Ausgang verknüpfen.
Oder reitest du so drauf rum weil ich ganz hinten eine Klammer zuviel hab?
Ist das so schwer, das einfach mal mit Deinem IF..THEN-Konstrukt zu formulieren? Oder würdest Du dann feststellen, daß es keineswegs übersichtlicher aussieht? (und viel mehr Platz auf dem Bildschirm oder Ausdruck benötigt?)

Nochmal zu den Instandhaltern - es geht nicht darum, ob die womöglich zu dumm für AWL oder SCL oder mehrfach-Zuweisungen sind, sondern die haben einfach keine Zeit zu verschwenden wenn die Anlage steht. Da ist keine Zeit erst 7 falsche Programmstellen zu beobachten... oder die ganze Bildschirmseite Text zu lesen statt das fehlende Bit in KOP direkt auf den ersten Blick zu sehen. Oder noch zusätzlich eine Variablentabelle öffnen zu müssen, um zu sehen, ob die im beobachteten Programmteil eindeutig zu sehende Zuweisung auch tatsächlich am Ende des Zyklus am Ausgang ankommt.

Harald
 
Wie dem auch sei - ST/SCL ist nach wie vor nach meinem Dafürhalten nicht für ausschweifendere Bitoperationen geeignet, wohl aber für das Arbeiten mit Zustandsentsprechungen im INT-Format so dass man auf so komfortable Befehle wie CASE zurückgreifen kann.

Ich stimme bedingt zu.
Bei Operationen, welche in einem Baustein hunderte Bitzuweisungen auf Eingänge von Datenbausteinen haben, würde FUP zwar besser aussehen, aber die Arbeit bei einer Änderung vervielfachen. Bei sehr kleinen Bit-Logiken hat ST auch wieder den Vorteil der (finde ich) Übersichtlichkeit.

Bei mittleren, sich nie ändernden Situationen mag vieleicht eine visuelle Sprache richtig gewählt sein.

Habe ich große Mengen an Variablennamen zu ändern (als Beispiel), dann kann ich dies ganz locker in word oder einem .txt bearbeiten und einfach in das ST Programm einfügen.
Mit FUP oder anderen "visuellen" Sprachen geht das leider nicht.

Ich handhabe es so, dass ich alles, was den Anwender angeht (vieleicht die ersten beiden Bausteinebenen) mit FUP zuweise. Alles andere ist ausschließlich ST und kann schön von Projekt zu projekt einfach kopiert werden anstatt umständlich exportiert/importiert oder als .lib angelegt.

Piece and Out für heute!
Grüße und schönen Feierabend für alle die, wie ich, gleich nach Hause gehen!
Flo
 
Habe ich große Mengen an Variablennamen zu ändern (als Beispiel), dann kann ich dies ganz locker in word oder einem .txt bearbeiten und einfach in das ST Programm einfügen.
Mit FUP oder anderen "visuellen" Sprachen geht das leider nicht.

geht das nicht? die Darstellung in eine Textsprache umstellen oder besser noch in der "visuellen" Sprache [sic!] die Funktion Suchen/Ersetzen verwenden?
um an die Welt anzuknüpfen in der ich die meiste Zeit unterwegs bin: Bei Step7 kann ich Operanden- oder Symbolvorrang für das gesamte Programm wählen und mit der Funktion "Umverdrahten" oder mit der Änderung des Symbols programmweite Änderungen durchführen - klingt komisch...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Habe ich große Mengen an Variablennamen zu ändern (als Beispiel), dann kann ich dies ganz locker in word oder einem .txt bearbeiten und einfach in das ST Programm einfügen.
Mit FUP oder anderen "visuellen" Sprachen geht das leider nicht.

Ich handhabe es so, dass ich alles, was den Anwender angeht (vieleicht die ersten beiden Bausteinebenen) mit FUP zuweise. Alles andere ist ausschließlich ST und kann schön von Projekt zu projekt einfach kopiert werden anstatt umständlich exportiert/importiert oder als .lib angelegt.

Also dafür gibt es doch Quellen in Step 7 z.B. und das funktioniert perfekt.
Ich schreibe viel in irgendeinem Editor und kompiliere es.

Und in ST bzw SCL Netzwerke mit umfangreichen Bitverknüpfungen zu debuggen, das ist es Erlebnis. Doch muss nicht wirklich sein.


bike
 
Code:
if DB1.DBX0.0       // Auto FC1 Zeile 20
     or DB1.DBX0.1  // Hand FC1 Zeile 40
   OR DB1.DBX0.2 // Einrichten FC1 Zeile 60
   then
   A1.0:=true; // Lampe EIN 
else 
   A1.0:=false; // Lampe AUS
end_if;
Genau sowas ist für mich das Paradebeispiel für 'ne IF-THEN-Orgie unter SCL/ST (ungeachtet der Absolutadressierung)

Ich würde da immer eine Zuweisung bevorzugen:
Code:
A1.0 := DB1.DBX0.0       // Auto FC1 Zeile 20
    OR DB1.DBX0.1  // Hand FC1 Zeile 40
    OR DB1.DBX0.2; // Einrichten FC1 Zeile 60
 
Ich habe das Gefühl ich werde missverstanden.

Ich lass das ganze Code Zeugs mal weg und möchte nochmal meinen Standpunkt zum Thema verdeutlichen. "strukturiertes Programmieren"
Wie ich oben schon schrub geht es mir dabei ums Prinzip.
Ich betreue komplexe Fertigungszellen, so etwa in der Größenordnung von 6 Maschinen mit je eigener SPS, Roboter, Messautomaten, Laser, vor- uind nachgelagerte Anlagen + übergeordnetes Leitsystem. Diese Kisten sind fast alle, ausser Leitsystem, mit DP/DP Kopplern mit der Zellensps verbunden. Warenträger läuft ein, ID wird beim Leitsystem aungefragt, Material ID + Rezepte + Kommisionierdaten werden zurückgeschickt und die Zelle reagiert entsprechend darauf.
Wenn das Material fertig bearbeitet ist, wird der Warenträger wieder abgemeldet und weitergeschickt, inkl. diverser Meldungen wie NIO, Zustand der Anlagen usw.
Das der ganze Spass recht anfällig ist, liegt in der Natur der Sache, hat das Leitsystem richtig geantwortet, ist überhaupt ein Telegramm raus, ist auf einem Band ein Ini kaputt, hat der Robi übergriffen, ist eine Maschine in Störung usw. usf.
Man kann sowas bis zu einem bestimmten Punkt im Programm abfangen bzw. konkrete Meldungen ausgeben, aber es wird immer zu unvorhergesehenen Zuständen kommen und dann muß der Instandhalter zügig den Fehler finden und dafür ist unbedingt eine klar strukturierte und verständliche Programmierung notwendig, gepflegte und kommentierte Varablentabellen und regelmäßige Unterweisungen.
Meine Erfahrungen haben folgendes gezeigt, meterlange UND Verknüpfungen in FUP sind für die meisten Leute unverständlich, SCL/ST wird meist in Servickursen sehr stiefmütterlich behandelt, super laufende Anlagen die komplett in AWL sind, inkl. massenweise indirekter Adressierung + Sprunglisten sind für Instandhalter fast nicht zur durchschauen.
Deswegen von mir das Beispiel mit der verschachtelten Zuweisung. Jemand der nicht jeden Tag damit zu tun hat, beißt sich dann an sowas die Zähne aus.
Auch wenn ihr mich dafür verteufelt, ich mache endlose if/then Orgien, ordentlich und sinnvoll in beschriftete FC/FB verpackt mit Kommentaren zu den Querverweisen. Das mag sich auf den ersten Blick schlecht lesen lassen, ok, aber bei der Fehlersuche kann man sich ratzbatz zum Problem durchhangeln, die Leute wollen das ja nicht alles von oben bis unten lesen, nur über die QVL hinspringen und sehen wo es klemmt.

Außerdem hab ich euch alle lieb und jetzt sage ich gfanz laut JEHOVAAA!
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe das Gefühl ich werde missverstanden.

Ich lass das ganze Code Zeugs mal weg und möchte nochmal meinen Standpunkt zum Thema verdeutlichen. "strukturiertes Programmieren"
Wie ich oben schon schrub geht es mir dabei ums Prinzip.
Ich betreue komplexe Fertigungszellen, so etwa in der Größenordnung von 6 Maschinen mit je eigener SPS, Roboter, Messautomaten, Laser, vor- uind nachgelagerte Anlagen + übergeordnetes Leitsystem. Diese Kisten sind fast alle, ausser Leitsystem, mit DP/DP Kopplern mit der Zellensps verbunden. Warenträger läuft ein, ID wird beim Leitsystem aungefragt, Material ID + Rezepte + Kommisionierdaten werden zurückgeschickt und die Zelle reagiert entsprechend darauf.
Wenn das Material fertig bearbeitet ist, wird der Warenträger wieder abgemeldet und weitergeschickt, inkl. diverser Meldungen wie NIO, Zustand der Anlagen usw.
Das der ganze Spass recht anfällig ist, liegt in der Natur der Sache, hat das Leitsystem richtig geantwortet, ist überhaupt ein Telegramm raus, ist auf einem Band ein Ini kaputt, hat der Robi übergriffen, ist eine Maschine in Störung usw. usf.
Man kann sowas bis zu einem bestimmten Punkt im Programm abfangen bzw. konkrete Meldungen ausgeben, aber es wird immer zu unvorhergesehenen Zuständen kommen und dann muß der Instandhalter zügig den Fehler finden und dafür ist unbedingt eine klar strukturierte und verständliche Programmierung notwendig, gepflegte und kommentierte Varablentabellen und regelmäßige Unterweisungen.
Meine Erfahrungen haben folgendes gezeigt, meterlange UND Verknüpfungen in FUP sind für die meisten Leute unverständlich, SCL/ST wird meist in Servickursen sehr stiefmütterlich behandelt, super laufende Anlagen die komplett in AWL sind, inkl. massenweise indirekter Adressierung + Sprunglisten sind für Instandhalter fast nicht zur durchschauen.
Deswegen von mir das Beispiel mit der verschachtelten Zuweisung. Jemand der nicht jeden Tag damit zu tun hat, beißt sich dann an sowas die Zähne aus.
Auch wenn ihr mich dafür verteufelt, ich mache endlose if/then Orgien, ordentlich und sinnvoll in beschriftete FC/FB verpackt mit Kommentaren zu den Querverweisen. Das mag sich auf den ersten Blick schlecht lesen lassen, ok, aber bei der Fehlersuche kann man sich ratzbatz zum Problem durchhangeln, die Leute wollen das ja nicht alles von oben bis unten lesen, nur über die QVL hinspringen und sehen wo es klemmt.

Außerdem hab ich euch alle lieb und jetzt sage ich gfanz laut JEHOVAAA!


Also langsam solltest du dir Gedanken mache, ob du vielleicht dein Problem völlig falsch beschrieben hast.

Es gibt in vielen Firmen den Ansatz zu standardisieren.
Dass in in einem bestimmten Baustein diese, in einem anderen ein andere Funktion ausprogrammiert wird und so schnell bei Störungen zum Ziel gekommen wird. (HMI - lite / transline 2000)
Aber so wie du schreibst, kann dir vermutlich niemand folgen.

Und noch ein Hinweis:
Wenn die Instandhaltung ein PG brauchen, dann ist das ein Tiefschlag für die Programmierer (sagt ein anderer User hier, aber der hat absolut recht)


bike
 
Zurück
Oben