TIA SCL sauber/ strukturiert programmieren

[Bit´ler]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich habe in den letzten 20 Jahren immer nur AWL programmiert. Nun sollte ich aber auf SCL unsteigen.
Nun meine Frage: Die Beispiele die mir bis jetzt vorgesetzt wurden sind für mich (und meine Kollegen) ziemlich unverständlich.

Nun meine Frage.

Gibt es Literatur oder Beispiele der Formunsmitglieder wie ein sauber strukturiertes Programm auszusehen hat so das es auch andere "durchsteigen" können.
Ich bezweifle die Fähigkeiten meines Kollegen überhaupt nicht, im Gegenteil, halte Ihn für genial. Trotzdem verstehen wie seine Programme nicht und wollen aus diesen Grund SCL "nachvollziehbar" programmieren.

Beispiele oder Literaturhinweise willkommen.

Grüßle

 

[hucki]

Mir stellt sich jetzt die Frage, sind Eure Beispiele strukturiert und trotzdem für Euch unverständlich, da ungewohnt, oder sind sie für Euch gerade deswegen unverständlich, weil unstruktuiert/unnötig kompliziert formuliert.

Typisches Beispiel für Letzteres wären z.B. unnötige IF-THEN-ELSE-Orgien ala:

IF #Merker1 = TRUE 
THEN 

    #Merker2 := TRUE;

ELSE 

    #Merker2 := FALSE;

END_IF;

statt einfach:

#Merker2 := #Merker1;

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Typisches Beispiel für Letzteres wären z.B. unnötige IF-THEN-ELSE-Orgien ala:

IF #Merker1 = TRUE 
THEN 

    #Merker2 := TRUE;

ELSE 

    #Merker2 := FALSE;

END_IF;

..

So ein Konstrukt habe ich neulich in einer Siemens-Bibliothek gesehen. Hat mich doch ein wenig nachdenklich gestimmt :sad: .



Nachtrag:
.. Andererseits ist es aber auch kein Fehler.

Bibliothek mit generellen Funktionen (LGF) für STEP 7 (TIA Portal) und S7-1200 / S7-1500

 

[rostiger Nagel]

Der Umstieg von AWL zu SCL ist erst einmal einmal eine Umstellung.

In AWL wird immer nur eine Operation bzw. Befehl in einer Zeile gepackt,
das Ergebnis (Befehl) kommt immer erst zum Schluß.

L #Wert_1
L #Wert_2
+D
L #Wert_3
/D
T #Ergebnis

Oder

U #IN1
U #IN2
O
U #IN1
U #IN3
= #OUT

In SCL wird so etwas schnell zum Einzeiler

#Ergebnis := (#Wert_1 + #Wert_2) / Wert_3;

Oder

#OUT := (#IN1 AND #IN2) OR (IN1 AND IN3);

Die Gefahr bei den Einzeiler ist das die schnell unübersichtlich werden, besonders
Wenn die Variablenbezeichnungen lang werden, das ist dann fast nicht zu überblicken.

Da hat ja TIA einen Fortschritt zur Classic Welt, das jetzt KOP oder FUP mit SCL gemischt
In einen Baustein erstellt werden können, so können Verknüpfungen in KOP oder FUP
Gemacht werden und Berechnungen, Schleifen oder andere Komplexen Anweisungen in SCL.

Egal wie die Vorlieben sind, mit jeder Sprache kann man unübersichtliche Programme
Erstellen. Wichtig ist eine Struktur, helfen kann dabei Progammblöcke in „Regions“ zu setzen,
Meiner Ansicht nach sollten, diese aber nicht zwei Stufen übersteigen.
Zeilen nicht zu lang werden lassen, auch in SCL kann man Verknüpfungen übersichtliche
gestalten, ohne gleich KOP oder FUP vermissen zu müssen.

OUT := (IN1 AND IN2)
OR (IN1 AND IN3);

Wichtig bei jeder Sprache sind einfach Kommentare, wobei SCL sehr oft selbstsprechend ist,
Ein IF ... THEN ... ELSE sagt doch schon viel aus.

 

[Deep Blue]

Ich programmiere mittlerweile bevorzugt mit SCL. Ist einfach eine super Sache wenn man auch mit "Hochsprachen" zu tun hat.

Lektüre gibt es ja eine Menge. Hatte mich bei der Einarbeitung stark mit Codesys beschäftigt.

Wenn ihr euch zum Anfang eine einheitliche Benennung der Variablen angewöhnt ist das mMn schon mal die Hälfte der Miete.

Also z. B. xTaster für ein Bit, bAmpel für ein Byte, iWert für ein Integer usw. Das macht den Code und das Verständnis was da passiert schon mal viel Einfacher.

Und das A und O ist mMn die Dokumentation in Form von Kommentaren im Quelltext.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

So ein Konstrukt habe ich neulich in einer Siemens-Bibliothek gesehen. Hat mich doch ein wenig nachdenklich gestimmt :sad: .

Programme, die laufen, werden ja auch nicht geändert, sondern von Generation zu Generation überliefert.
Oft lässt sich nicht einmal mehr feststellen, warum sie laufen und was sie überhaupt machen.

 

[rostiger Nagel]

Wenn ihr euch zum Anfang eine einheitliche Benennung der Variablen angewöhnt ist das mMn schon mal die Hälfte der Miete.

Also z. B. xTaster für ein Bit, bAmpel für ein Byte, iWert für ein Integer usw. Das macht den Code und das Verständnis was da passiert schon mal viel Einfacher.

Da stimme ich zu selbserklärende Variablen Bezeichnungen können sehr viel helfen,
ein Programm übersichtlich zu machen.

Mann kann schöne Einheiten in ein Struct packen und hier wieder für
unterstruckturen einheitliche Präfixe nutzen.

Transport1.Setp.velo := Transport1.Para.VeloSchleichgang;
Transport2.Setp.velo := Transport1.Act.Velo

Act = Istwert
Setp = Sollwert
Para = Parameter

macht das Beispiel schon wieder fast selbsterklärend.
Auf Präfixe um das Variablenformat kenntlich zu machen,
kann man im TIA Editor verzichten, der zeigt es schon gut
an, wenn etwas nicht zusammen passt. Man merkt schon
beim Schreiben, das sich ein Byte nicht mit einen Eingang
verheiraten lässt.

 

[Heinileini]

ich habe in den letzten 20 Jahren immer nur AWL programmiert. Nun sollte ich aber auf SCL unsteigen.
. . . Die Beispiele die mir bis jetzt vorgesetzt wurden sind für mich (und meine Kollegen) ziemlich unverständlich.

"Sauber strukturiert" betrifft die Denkweise und nicht die ProgrammierSprache.
Sauber strukturiert beschränkt sich nicht auf das Programm, sondern betrifft auch die Daten.
Wer in AWL 20 Jahre lang sauber strukturiert programmiert hat - bewusst oder unbewusst - der kann das auch in SCL.
Wer BitVerknüpfungen in AWL versteht, der hat weniger Probleme sie in SCL zu verstehen, als jemand, der von der "HochSprachenProgrammierung" kommt.
Wer täglich mit zyklischen Programmen zu tun hat, dem bleiben auch die diesbezüglichen VerständnisProbleme erspart, mit denen "HochSprachenProgrammierer" (anfangs?) zu kämpfen haben.
Wer in AWL mit den verschiedenen Datentypen (Bit, Byte, Wort, DoppelWort, INT, DINT, REAL, Char, String, UnsignedIrgendwas, . . .) klar kommt, der weiss auch in SCL, was er tut bzw. tun muss.
Wer mit einem TaschenRechner aus dem Radius die KreisFläche berechnen kann, kann dies auch in SCL.
Wer in AWL schon "zu Fuss" ein Array oder eine ProgrammSchleife "gebastelt", einen bedingten Sprung, einen SprungVerteiler angewendet hat, der wird sehen, dass es in SCL einfacher/lesbarer/übersichtlicher geht.
Wer in AWL SprungMarken verwendet hat (weil alternativlos!), wird sehen und muss sich daran gewöhnen, dass man sie in SCL nicht mehr benötigt.
Die Konsequenz aus dem Verzicht auf SprungMarken ist, dass man automatisch "strukturiert" programmiert.
Man hat es tun mit Sequenzen (Folgen von nacheinander abgearbeiteten Befehlen), Selektionen (ProgrammVerzweigungen) und Iterationen (ProgrammSchleifen).
Es gibt Befehle, um von einer Stelle in einer Schleife an das Ende derselben Schleife zu springen
- ohne die Schleife zu verlassen
- mit Verlassen der Schleife.
Verpönt bis nicht zulässig bzw. nicht möglich sind auf jeden Fall Sprünge "kreuz und quer" - aber die habt ihr doch auch schon in AWL gemieden!?
Umständlich und unübersichtlich kann man in SCL sowie in AWL programmieren.
Und komplexe Zusammenhänge, die sich aus der Aufgabenstellung ergeben, lassen sich weder in AWL noch in SCL so programmieren, dass sie jeder sofort und gleichermassen problemlos durchschauen kann.
Und nicht vergessen: das Programmieren beginnt nicht mit dem Schreiben der ersten ausführbaren Anweisung, sondern bei der Umsetzung der Aufgabenstellung in die DatenStruktur, auch bzw. insbesondere dann, wenn man den Eindruck hat, dass schon alles betoniert (Schnittstellen) und man dem hilflos ausgeliefert ist.
Nur Mut!

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich programmiere auch zu 80% in SCL,

ein häufiger Fehler, den ich sehe ist, dass keine ARRAY´s benutzt werden.
Also statt

SollwertDrehzahlPumpe : ARRAY[1..30] OF INT
dann so:
SollwertDrehzahlPumpe1 : INT;
SollwertDrehzahlPumpe2 : INT;
SollwertDrehzahlPumpe3 : INT;
SollwertDrehzahlPumpe4 : INT;
.....

Da hat man dann später die Probleme, dass man nicht symbolisch durchindexieren kann ála:

FOR i := 1 TO 30 BY 1 DO
     SollwertDrehzahlPumpe[i] := 0;
END_FOR;

 

[Thomas_v2.1]

Ich programmiere auch zu 80% in SCL,

ein häufiger Fehler, den ich sehe ist, dass keine ARRAY´s benutzt werden.

Es gibt aber Fälle da hat man als Parameter lieber Einzelwerte (Beispielsweise wenn du in CFC programmierst haben Array-Parameter Nachteile). Diese kann man dann ja zur einfacheren Verarbeitung wieder in ein Array kopieren.

SollwertDrehzahlPumpe[1] := SollwertDrehzahlPumpe1;
SollwertDrehzahlPumpe[2] := SollwertDrehzahlPumpe2;
SollwertDrehzahlPumpe[3] := SollwertDrehzahlPumpe3;
SollwertDrehzahlPumpe[4] := SollwertDrehzahlPumpe4;
SollwertDrehzahlPumpe[5] := SollwertDrehzahlPumpe5;
...

FOR i := 1 TO 30 BY 1 DO
     SollwertDrehzahlPumpe[i] := 0;
END_FOR;

 

[blackpeat]

Ich empfehle da eigentlich immer mal in den StyleGuide von Siemens zu gucken. Da sind ein paar gute Ideen drin. Ob die alle für jeden Sinnvoll sind kann man drüber streiten aber ich denke das Grund Konzept hinter dem StyleGuide ist nicht ganz falsch.

https://support.industry.siemens.co...ür-simatic-s7-1200-und-s7-1500?dti=0&lc=de-CH

 

[hucki]

Zuviel Werbung?
-> Hier kostenlos registrieren

... helfen kann dabei Progammblöcke in „Regions“ zu setzen ...

*ACK*

Seit dem dies möglich ist, hab' ich das in meinen bestehenden SCL-Bausteinen auch noch überall nachträglich eingefügt, da es die Übersicht doch erheblich verbessert.
Im Normalfall sind dann alle Regionen ein- und nur die gerade Gebrauchte wird ausgeklappt.

 

[Zombie]

Regions haben einem das Leben wirklich einfacher gemacht. Ich hab früher immer Kommentarbalken über die gesamte Zeilenbreite gemacht wenn ich einen "Abschnitt" vom nächsten trennen wollte. Heute mache ich nur noch ne Überschrift und eine Region außendrum.
Hilfreich sind sie besonderns (finde ich) wenn man die Stelle gefunden hat an der man eine Änderung vornehmen müsste, dies aber in der Onlinesicht getan hat. Gibt man das erste Zeichen ein, schnurrt alles zusammen und man findet sich gar nicht mehr zurecht. Vor allem da Scrollen im SCL Code mit dem Trackpad ebenfalls nicht so der Bringer ist.

Wenn man dann weiß in welcher Region man war, kann man wenigstens wieder an den Anfang gehen und dann mit den Pfeiltasten Zeile um Zeile durchgehen.

 

[H-Cl]

Bei den Regions sollte man auch die Möglichkeit nutzen, diese zu verschachteln.
In Verbindung mit der Übersicht der Regions neben dem Editor hat man automatisch ein strukturiertes inhaltsverzeichnis und kann sehr schnell an gesuchte Stellen springen.

 

[Bit´ler]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

erst mal ein dickes Danke an die sich hier beteiligt haben.
Ja das mit dem Style-Guide werde ich mir mal ansehen und auch die anderen Gedankengänge halt ich mir im Hinterkopf.
Es geht mir eigentlich um die Struktur des Programms.
Unterprogramme für welche Funktionen?

Wie unterteilt Ihr das ..

Handfunktionen, Automatik, Übergabe der Ausgänge, HMI, Schnittstellenhandling

Möchte keinen Technologietransfer aber vielleicht gbits ein paar Beispiele in TIA V15....

Ich möchte halt SCL so lernen wie es "sein" soll...Wie immer das auch ist so das es andere möglichst leicht nachvollziehen können.
Sicherlich schwer weil ja jeder seinen Stil hat.

Nochmals Danke.

Gruß

 

[RedCali]

Ich möchte halt SCL so lernen wie es "sein" soll...Wie immer das auch ist so das es andere möglichst leicht nachvollziehen können.
Sicherlich schwer weil ja jeder seinen Stil hat.

damit hast schon viel gesagt - jeder hat seinen eigen Still, manche auch einen Stiefel

Regions sind sehr gut um sein Programm zu clustern und Kommentare können das Leben auch oft erleichtern!
Viele Kommentare können ein Anzeichen für schlechten oder komplexen Code sein, was aber ist schlecht oder komplex?
Letztendlich wird jeder seinen Weg selbst finden, wie er es gerne hat - das sieht dann auch jeder gerne etwas anders...

Man kann sich auch mal neben dem Styleguide den Programmierleitfaden ansehen, oder auch nach den Stichwörtern "Code Metriken" und "Softwarequalität" suchen, da gibt es auch sehr viel zu lesen und unterschiedliche Ansätze und Denkweisen.

VG
Bastian

 

[Paul]

....... Wie unterteilt Ihr das ..
Handfunktionen, Automatik, Übergabe der Ausgänge, HMI, Schnittstellenhandling.......

Hallo
zunächst ein mal möchte ich sagen, dass ich mich momentan in genau der selben Situation befinde wie Du.
Habe auch seit mehr als 20 Jahren alles in AWL gemacht und versuche mich jetzt in SCL einzuarbeiten.
Einfach weil man nicht mehr daran vorbei kommt und weil ich befürchte, dass Siemens AWL über kurz oder
lang sterben lässt.
Meine Ausführungen sind also nicht die eines erfahrenen SCL Programmierers, deshalb bin ich für
konstruktive Kritik auch jederzeit offen.

Also: Ich baue meine Programme immer so auf, dass ich das Große Ganze in kleinere, überschaubare Teilfunktionen
aufteile. Dabei greife ich auf einen Grundstock zurück den ich immer wieder brauchen kann (z. B. Zylinderansteuerung mit Endlagenüberwachung, Meldungsbearbeitung etc....). Was ich in diesem Fundus nicht habe wird eben für die jeweilige
Anlage individuell neu gemacht, möglichst so dass es auch für später wieder verwendbar ist.

Ich habe vor, das in SCL genauso zu handhaben.

Wenn du schon lange AWL programmierst ist das aber wahrscheinlich nichts Neues für Dich.

Einerseits bin ich begeistert, mit wie wenigen Zeilen man in SCL etwas machen kann, was
in AWL einen meterlangen Code bedeuten wurde.
Andererseits tut man sich aber sehr schwer einen Bug zu finden
weil das Online beobachten sehr eingeschränkt ist (z.B. FOR-Schleifen).

Dem allgemeinen Tenor, dass SCL viel schöner, besser, einfacher, übersichtlicher, schneller, ist als AWL
kann ich mich leider (noch) nicht anschließen, aber wer weiß, vielleicht kommt's ja noch.
Mit TIA hab ich mich inzwischen ja auch halbwegs zusammengerauft.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dem allgemeinen Tenor, dass SCL viel schöner, besser, einfacher, übersichtlicher, schneller, ist als AWL
kann ich mich leider (noch) nicht anschließen, aber wer weiß, vielleicht kommt's ja noch.
Mit TIA hab ich mich inzwischen ja auch halbwegs zusammengerauft.

Mir ging es ähnlich, 15 Jahre nur AWL, jetzt 75% nur noch SCL/ST.

Beide Sprachen haben Vor- und Nachteile. Dadurch, dass man mit SCL sehr kompakt schreibt,
ist das beobachten schwieriger aber machbar. Was mich am meißten stört, ist der Bausteinvergleich.
Wenn Online <> Offline unterschiedlich ist, kann man nicht in SCL vergleichen sondern bekommt beide
SCL Bausteine in AWL kompilierter Form zu sehen. Und dann wirds kompliziert ( ich rede von Step7 V5.x )

Aber im Großen und Ganzen bin ich von SCL begeistert. Wenn man sich an Strukturen usw. hält und
vor allem symbolisch arbeitet kann man komplexe Aufgaben leicht lesbar lösen.

 

[hans_a1977]

Ich persönlich fand das Vogel-Fachbuch immer gut. Falls es in der Firma Codesys-Projekte gibt, sollten die evtl. vorher angegangen werden.
Da lernt man es auch ganz gut. (zumindest die ungefähren Strukturen)
Fakt ist: SCL ist deutlich schneller und leserlicher als AWL, wenn man es kann.
Wobei man beim TIA SCL ein paar andere Befehle und teilweise auch anderes Verhalten hat, als beim Classic SCL.
Einer meiner MA hatte sich einen Online-Kurs und das Buch gekauft ( [FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]https://trainmatic.de/scl-programmierung-grundlagen )
Er konnte allerdings vorher schon Codesys-Programmierung.
lg
[/FONT]

 

[JesperMP]

Der Umstieg von AWL zu SCL ist erst einmal einmal eine Umstellung.

In AWL wird immer nur eine Operation bzw. Befehl in einer Zeile gepackt,
das Ergebnis (Befehl) kommt immer erst zum Schluß.

[..]
U #IN1
U #IN2
O
U #IN1
U #IN3
= #OUT

In SCL wird so etwas schnell zum Einzeiler

[..]
#OUT := (#IN1 AND #IN2) OR (IN1 AND IN3);

Man kann von diesen Beispiel sehen, dass viele Programmierer beim Programmieren von SCL "zusätzliche" Klammern hinzufügen, um die logische Reihenfolge der Ausführung zu verdeutlichen.
Ich mache das auch und finde es ein Vorteil, dass es möglich ist.
Es hätte eigentlich genug mit diese Zeile gewesen sein, weil OR eine höhere Rang als AND hat (d.h. OR word spähter ausgeführt als AND).

#OUT := #IN1 AND #IN2 OR #IN1 AND #IN3;

Das eine wichtige Programmfunktionalität implicit ist finde ich nur eine Nachteil (egal AWL oder SCL). Besser mehr Klammer als zu wenig Klammer.
Grosse logische Netzwerke in AWL habe ich nie geliebt. Das obigen Beispiel ist ziemlich Einfach, aber ich habe Netzwerke gesehen wo ich frage "was macht dies ?".
AWL hat den Vorteil über SCL bei logische Netzwerke dass man Online Zeile-für -Zeile den logische Zustand von den Variabel in die Zeile und den logische Zustand von den VKE. Aber, wenn man es braucht weil es auf die Schnelle schwierig zu erkennen was passiert, dann hätte man lieber KOP vewenden.

Es gab in STEP7 Classic einige Vorteile bei SCL die es nicht gab in die andere Sprachen - einfache Indexe, wenig bedarf von Pointer, Type-checking, AT-Sicht.
In TIA hat die Sprachen fast denselbe Funktionalität. Das man KOP mit ein bisschen SCL kombinieren kann finde ich genial.
Vorher mit Classic hatte ich ungf. AWL=5%, KOP=30%, SCL=65%.
Heute mit TIA habe ich ungf. AWL=0%, KOP=50%, SCL=50%. Ja, KOP ist gestiegen. Der Grund ist das ich Indexe und AT-Sicht in KOP habe was vorher nur in SCL gab.