Step7: while-Schleife führt zu Systemfehler

[Frank12NR]

Hallo zusammen,
bei mir tritt ein seltsames Problem in SCL auf.

Ich habe in einem FC folgendes Programm stehen:

while #Ventil1=0 and #Ventil2=0 and #Schalter1=1 and #Schalter2=1
Do #Ventil3:=1;
End while;

Lädt und startet man das Programm, passiert folgendes:

Die beiden ersten Ventilen sind standardmäßig "0", die Schalter standardmäßig unbetätigt. Die Anfangsbedingungen passen, #Ventil3 ist 0.

Betätige ich gleichzeitig die beiden Schalter, geht Ventil3 auf 1. Passt also auch.

Jetzt kommts:

FALL 1: Setze ich einen der beiden Schalter zurück auf "0", bleibt das Ventil3 trotzdem "1". Das ist meiner Meinung nach falsch.

Fall 2: Lasse ich an der Anlage in der Schule die beiden Eingänge auf "1", bleibt das Ventil3 auf "1". Nach einigen Sekunden meldet der OB80 einen Systemfehler (Laufzeitfehler) und versetzt die Anlage in Ruhezustand.

Fall 3: Lasse ich das Ganze als Simulation auf meinem Laptop laufen, tritt ebenfalls der Systemfehler auf. Nach ein bisschen warten, steigt dann das komplette TIA-Portal aus. (das mag allerdings am Laptop liegen).


Ich bin recht ratlos, sowohl was die eigentliche Funktion der while-Schleife angeht (SO schwer ist sie ja nun nicht) als auch diesen seltsamen Systemfehler.

Kann mich irgendjemand in die richtige Richtung schubsen, wo ich den Fehler suchen sollte?

Wir benutzen die S7 ET200s.

Danke und Gruß,
Frank

[Frank12NR]

Erstaunlich. Ich grüble seit Dienstag über diesem Problem, und kaum hab ich's aufgeschrieben, fällt mir die Lösung wie Schuppen von den Augen

Für interessierte Mitleser:

Ich habe vergessen, dem Programm mitzuteilen, was denn zu tun ist, wenn die Bedingungen nicht mehr erfüllt sind. Setzt man einen Eingang von 1 auf 0 zurück, ist der Zustand des Ventil3 nicht definiert.

Die Lösung war schlicht und einfach, unter der Schleife ein #Ventil3:=0; zu ergänzen.

Gruß,
Frank

[Lötauge35]

es ist wie im richtigen Leben, kaum macht mans richtig, schon funktionierts

[IH-Elektriker]

Warum in aller Welt wird sowas in SCL programmiert ?

SCL ist für mich dafür gedacht komplexe Anwendungen und Berechnungen usw. innerhalb einer SPS zu realisieren - und von komplex ist obiges Beispiel weit, weit weg

Oder geht es hier nur um das "wie" und das grundsätzliche erlernen und begreifen von SCL ?

Abgesehen davon beisst sich für mich "komplex" und eine 200er Steuerung bereits irgendwie....

Vieles lässt sich in der SPS grafisch lösen (KOP, FUP), komplexe Sachen dann in AWL. Bis man SCL benötigt brauchts schon einen erheblichen Schwierigkeitsgrad in der zu programmierenden Anwendung

[Frank12NR]

Oder geht es hier nur um das "wie" und das grundsätzliche erlernen und begreifen von SCL ?

Kurz und gut: Ja

Gruß,
Frank

[Bapho]

Hallo zusammen,

für den Fall sollte keine Schleife sondern eine if/then/else Anweisung genommen werden. Die SPS läuft eh zyklisch, also quasi in einer Endlosschleife und da sollte man mit Schleifen, wegen der Zyklusüberwachung, eh sehr vorsichtig sein und wenn möglich immer einen Ausstieg mit vorsehen.

Zum Thema SCL, wenn man einmal über das FUP/KOP Stadium hinaus ist und sich mit einer Hochsprache auskennt nimmt man doch nix anderes mehr.

[IH-Elektriker]

Hallo zusammen,
Zum Thema SCL, wenn man einmal über das FUP/KOP Stadium hinaus ist und sich mit einer Hochsprache auskennt nimmt man doch nix anderes mehr.

Aus Sicht eines Programmierers mag das okay sein und ist für mich auch nachvollziehbar.

Allerdings muss man auch mal die andere Seite sehen – nämlich die armen Schweine welche nachts um halb drei zu einer komplexen Anlage gerufen werden und dort Störungssuche und Diagnose machen sollen. Sprich den normalen Instandhalter einer Anlage.

Der braucht teilweise zwingend das SPS-Programm um sich die Abhängigkeiten zusammenreimen zu können – und um sinnvoll Fehlersuche zu betreiben und nicht nur im Nebel herumzustochern.

Grundlegende Programmierkenntnisse in Step7 sind heutzutage eher kaum mehr das Problem, das bringen viele gerade jüngere Mitarbeiter aus der Ausbildung mit – oder haben sich diese Dinge angeeignet. Allerdings meistens beschränkt auf eine gewisse Fehlersuche in grafischer Darstellung (KOP/FUP) welche ja von vielen „gestandenen Programmierern“ als Kinderkram abgestempelt wird, teilweise sind noch Kentnisse in AWL vorhanden – aber SCL ist kaum bis gar nicht verbreitet.

Wird nun eine Anlage oder Maschine komplett in SCL oder (abgeschwächt) auch in AWL programmiert so hat ein Instandhaltungsmitarbeiter in der Regel kaum eine Möglichkeit auch einfache Zusammenhänge aus dem Programm zu lesen….

Ende vom Lied ist die Tatsache dass die Maschine „steht“ – bei Stillstandskosten von teilweise 5-10€ pro Fertigungsminute sowie der heute üblichen Just-in-Time-Fertigung ohne große Zwischenpuffer kann so ein Ausfall ganz schnell sehr ärgerlich und teuer werden.

Daher ist es wichtig die Steuerungsprogramme so einfach wie möglich und nur so kompliziert wie nötig zu halten – das schließt auch die Wahl der Darstellungsart bzw. „Programmiersprache“ mit ein. Oftmals ist es so das viele Dinge grafisch darstellbar wären wenn denn der Programmierer nicht ellenlangen „Fließtext“ in AWL gebastelt hätte welcher nicht mehr in Kontakt- bzw. Funktionsplan umsetzbar ist.

Viele Maschinenhersteller erkennen dies zwischenzeitlich und setzen das auch konsequent um – und viele Kunden fordern das inzwischen explizit.

Andere Hersteller sind immer noch der Meinung das dann eben ihr Service anrücken muss – der aber nicht 24/7 zur Verfügung steht – um den Fehler zu beheben…..

Es ist nunmal Fakt das oft die maximal tolerierbare Ausfallzeit von Fertigungsmaschinen nur noch wenige Stunden beträgt – nicht immer, aber bei wichtigen Maschinen und Anlagen durchaus. Und dabei muss es sich nicht um komplexe Technik wie in einer Raffinerie oder so handeln, das sind teilweise popelige Drehmaschine oder Umformpressen, Montageautomaten o.ä.

Servus

Dirk

[Bapho]

Ich war selber lange so ein "armes Schwein" und hab da so meine Erfahrungen gemacht.
Irgendwie ist es auch immer eine Frage der Programmierphilosophie, viele Programmierer haben sich so eine Art Baukastensystem mit fertigen Bausteinen geschaffen und nutzen die immer als Gerüst. Meist fürt das zu unnötig komplexem Code und es ist sehr schwierig sich da einzuarbeiten.
Auch wenn viele Schnittstellen wie Leitsysteme existieren und da viele Daten geschoben werden müssen hat man oft keine Wahl der Sprache.

Für die "armen Schweine" haben sich bei uns folgende Sachen bewährt:
- gute Kommentierung und Strukturierung des Codes
- ordentliche Variablentabellen mit Kommentierung
- gründliche Schulung der Leute
- ein ordentliches Schichtlog mit Suchfunktion
- Aufarbeitung von bekannten Problemen in verständlichen Anleitungen
- kontinuierliche Pflege der Programme und Hilfsprogramme mit einfacher Bedienung aus der Visu

[IH-Elektriker]

Für die "armen Schweine" haben sich bei uns folgende Sachen bewährt:

Kann ich zu 100% unterschreiben !

Sauber strukturierte Programme, ordentliche Kommentierung der Variablen sowie der Netzwerke und der Bausteine sowie eine so weit wie möglich machbare Übersetzbarkeit in KOP und FUP sind für einen sauberen, schnellen Service extrem wichtig.

Betreffend Abläufe wie Anbindung an Leitsysteme – klar, irgendwann wird es komplex und komplizert. Dann muss man einfach damit leben das Programmteile nicht einfach zu durchschauen sind und auch ausführliche Dokumentation nicht mehr ausreicht, sondern wirkliches Expertenwissen gefordert ist. Aber diese Programmteile sollten so klein als möglich gehalten werden…

[Frank12NR]

So, um das Thema für ggf. interessierte Mitleser abzuschließen:

1. Meine Lösung funktionierte seltsamerweise in der Simulation, allerdings nicht an der realen Anlage. Der Grund war ebenso simpel wie doof: Ich habe das "return" vergessen! Das führte dazu, dass die schleife lief und lief, bis die Laufzeitüberwachung des OB1 ansprach. Warum dies in der Simulation trotzdem funktionierte, kann ich nicht sagen. Ich nehme an, es liegt tatsächlich am Laptop, der inzwischen in 50% der Step7-Aufrufe sowieso damit beschäftigt ist, sich aufzuhängen

2. Zur Kritik an SCL bzw. zu den "armen Schweinen": Wie geschrieben handelte es sich um eine Übungsaufgabe. Dass in der Praxis eher FUP bzw. KOP verwendet wird, wenn möglich, ist mir schon klar. Da wir aber "nach dem neuesten Stand" unterrichten sollen, muss SCL zumindest mal kurz im Unterricht auftauchen. Übrigens genauso wie instanzfähige Programmierung, die - wie mir meine Fachschüler ständig beteuern - in vielen Betrieben nicht eingesetzt wird.
Im Großteil des Unterrichts stelle ich den Schülern frei, was sie verwenden. Die meisten entscheiden sich für FUP, und um ehrlich zu sein, ich auch. M.E. ist das einfach die übersichtlichste Variante, schon alleine, weil sich die Signalwege am besten beobachten lassen.


Gruß,
Frank