SCL kontra KOP-FUP-AWL

[Fluffi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Gegenfrage: Warum sollte man mit SCL überhaupt versuchen sauber und strukturiert programmieren, wenn es FUP gibt was in sich schon sauber und strukturiert ist, sogar ohne eigenes Zutun?

Ok, für mathematische Berechnungen, Datenverarbeitung, Arrayhandling etc. nutze auch ich SCL (statt früher AWL). Davon rede ich nicht. Aber das Programm einer Maschine besteht doch mindestens zu 90% aus einem Berg an Bitgeschubse und einem nicht enden wollenden Wulst an If-Else Bedingungen. Warum sollte man sich antun, ein mehrstufiges FUP Netzwerk mit SCL programmieren zu wollen? Selbst wenn es gekonnt programmiert ist, es ist kaum zu debuggen, schwer erweiterbar und für andere wie auch später für einen selbst nicht mehr oder nur noch schwer zu dechiffrieren. In FUP ist das gleiche Programm statt der mehrschichtigen If-Else-Schleifen mit den Und-Verknüpfungen auf einen Blick leicht durchschaubar, erweiterbar und leicht zu debuggen. Warum also der übertriebene Hang zu SCL wenn es FUP gibt? Programmiert ihr echt alles mit SCL und wenn ja, warum um alles in der Welt?

 

[H-Cl]

Im Prinzip sehe ich das ähnlich wie du, man sollte nach Möglichkeit die für die Aufgabe am besten geeignete Programmiersprache verwenden.
Das Verhältnis FUP/SCL hängt aber stark von der Anlage ab. Eine SPS hat heutzutage oft viel mehr Aufgaben als nur den Ersatz einer Schützschaltung.

Was sonst noch für SCL spricht, ist der Einsatz einer externen Versionsverwaltung. Die XLM-Dateien von KOP/FUP lassen sich mit Diff-Programmen nicht ansatzweise so gut vergleichen wie SCL Programme.

 

[Sarek]

Zuviel Werbung?
-> Hier kostenlos registrieren

Gegenfrage: Warum sollte man mit SCL überhaupt versuchen sauber und strukturiert programmieren, wenn es FUP gibt was in sich schon sauber und strukturiert ist, sogar ohne eigenes Zutun?

Ok, für mathematische Berechnungen, Datenverarbeitung, Arrayhandling etc. nutze auch ich SCL (statt früher AWL). Davon rede ich nicht. Aber das Programm einer Maschine besteht doch mindestens zu 90% aus einem Berg an Bitgeschubse und einem nicht enden wollenden Wulst an If-Else Bedingungen. Warum sollte man sich antun, ein mehrstufiges FUP Netzwerk mit SCL programmieren zu wollen? Selbst wenn es gekonnt programmiert ist, es ist kaum zu debuggen, schwer erweiterbar und für andere wie auch später für einen selbst nicht mehr oder nur noch schwer zu dechiffrieren. In FUP ist das gleiche Programm statt der mehrschichtigen If-Else-Schleifen mit den Und-Verknüpfungen auf einen Blick leicht durchschaubar, erweiterbar und leicht zu debuggen. Warum also der übertriebene Hang zu SCL wenn es FUP gibt? Programmiert ihr echt alles mit SCL und wenn ja, warum um alles in der Welt?

Ich bin deiner Meinung, ausser das ich FUP sehr selten benutze aber dafür AWL.
Aber wir hatten vor kurzem einen Kunden der gefordert hat alles in SCL zu machen....
Hat er dann auch bekommen, wirklich Sinn macht es nicht.
Das kommt meiner Meinung nach von den jungen Ing. die heutzutage nur noch "Hochsprachen" beherrschen...

 

[Larry Laffer]

Ich denke mal, dass diese Diskussion hier zu nichts führen wird.
Ganz grundsätzlich sehe ich es aber auch so :
- es gibt Dinge, die man schon am Besten in SCL erstellt / erstellen sollte
- es gibt Dinge, die zu programmieren in SCL nicht der richtige Ansatz ist
- der Kunde hat oft / immer Recht
und Nachtrag (wegen dem Beitrag von Oliver hinter diesem) :
- nicht jede Steuerung setzt jede Programmier-"Sprache" gleich gut um - Beispiel : bei Beckhoff ist es ggf. in Krampf im KOP/FUP zu programmeren - SCL ist dort aber durchaus die Wahl der Dinge / also nicht immer alles nur durch die Siemens-Brille sehen ...

Gruß
Larry

 

[oliver.tonn]

Aber wir hatten vor kurzem einen Kunden der gefordert hat alles in SCL zu machen....
Hat er dann auch bekommen, wirklich Sinn macht es nicht.
Das kommt meiner Meinung nach von den jungen Ing. die heutzutage nur noch "Hochsprachen" beherrschen...

Dem möchte ich im gewissen Rahmen widersprechen. Ich habe in den 80ern angefangen mir das Programmieren von Computern selbst beizubringen, zunächst in Basic und weil mir das zu langsam und eingeschränkt war dann in Assembler, was mit AWL vergleichbar ist. Später kam dann noch Pascal und die verschiedenen C-Sprachen, dann allerdings im Zuge einer Umschulung/Fortbildung, dazu. Wenn ich diese Sprachen vergleiche ist mir Pascal/C immer noch am liebsten. Und so sehe ich es auch im SPS-Bereich. Für logische Verschaltungen nutze ich FUP, für alles Andere meist ST, weil, zumindest ich, der Meinung bin, dass das Debuggen wesentlich einfacher ist als bei AWL, da man sich auch nicht immer Gedanken machen muss, welche Register der aktuelle Befehl gerade beeinflusst.
Mittlerweile wird allerdings AWL teilweise gar nicht mehr (z.B. Beckhoff TwinCAT 3) oder nur noch eingeschränkt (S7-1500) unterstützt, so das man keine Wahl mehr hat.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Gegenfrage: Warum sollte man mit SCL überhaupt versuchen sauber und strukturiert programmieren, wenn es FUP gibt was in sich schon sauber und strukturiert ist, sogar ohne eigenes Zutun?

Egal in welcher ProgrammierSprache, ich finde, man sollte überhaupt nicht versuchen, sauber und strukturiert zu programmieren!
Man sollte aber unbedingt sauber und strukturiert denken.
Dann wird das Programm automatisch sauber und strukturiert ... na ja, wenigstens in dem Rahmen der Möglichkeiten, die die verwendete Sprache bietet (das geht sogar in AWL!).
Leider lässt sich ein noch so schön sauber und strukturiert programmierter Code nachträglich beim Testen und "Korrigieren" schnell noch in Spaghetti-Code streichen, erweitern und ändern.
Wenn sich dabei aber - allem ZeitDruck und aller Bequemlichkeit zum Trotz - die saubere und strukturierte Denkweise durchsetzt ... wird man dies später nicht bereuen.

 

[H-Cl]

Das kommt meiner Meinung nach von den jungen Ing. die heutzutage nur noch "Hochsprachen" beherrschen...

Früher hots des net gewwe.

SCNR

 

[Heinileini]

Das kommt meiner Meinung nach von den jungen Ing. die heutzutage nur noch "Hochsprachen" beherrschen...

... und nie Einblick in die SPS-Programmierung hatten.
Na ja, "beherrschen" ist meiner Meinung nach übertrieben. Diejenigen, die Hochsprachen kennengelernt haben, haben i.A. in Beispielen und Anwendungen nicht wirklich etwas über boolesche Verknüpfungen mitbekommen. Na gut, ansatzweise in IF-Abfragen und SchleifenBedingungen ... aber sonst? Viele sind ja durchaus überrascht, dass man in Hochsprachen überhaupt SPS-mässige BitKnippsereien programmieren kann. Für die meisten Hochsprachler unbekannt oder zumindest ungewohnt, aber im SPS-Geschäft ursprünglich die einzige Anwendung und immer noch ein sehr wichtiges BetätigungsFeld.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

... Diejenigen, die Hochsprachen kennengelernt haben, haben i.A. in Beispielen und Anwendungen nicht wirklich etwas über boolesche Verknüpfungen mitbekommen. Na gut, ansatzweise in IF-Abfragen und SchleifenBedingungen ... aber sonst ?

Wenn du dich da mal nicht täuscht ... ich zum Beispiel behaupte mal beides zu beherrschen ... und auch die Hochsprachen (.Net) recht passabel ...

 

[Heinileini]

Wenn du dich da mal nicht täuscht ... ich zum Beispiel behaupte mal beides zu beherrschen ... und auch die Hochsprachen (.Net) recht passabel ...

Umso besser, wenn ich mich täusche, Larry!
Ich hatte ja auch geschrieben "i.A." und damit "im Allgemeinen" gemeint.

Mal ganz ehrlich, hast Du zuerst eine Hochsprache kennengelernt und dann erst die SPS-Programmierung?
Falls zuerst die Hochsprache, hast Du da wirklich schon gelernt, dass es auch boolesche Variablen gibt und, dass man darin z.B. das Ergebnis eines Vergleichs abspeichern kann?
Hast Du dabei auch schon erfahren, dass man ganze Bytes, Worte u.s.w. "bitweise" logisch verknüpfen kann? Ganz zu schweigen von schieben und rotieren?
Oder musstest Du das nach einer "üblichen" Einführung in eine Hochsprache selbst nachholen ("erarbeiten"), weil SPS- bzw. BetriebsSystem- bzw. Hardware-nahe Aufgaben zu lösen waren?
In diese "Tiefen" wird in ProgrammierKursen bei Hochsprachen eher selten eingedrungen. Hochsprachen sind aber auch nicht gleich Hochsprachen.
COBOL z.B. wurde erfunden, um kaufmännische Aufgaben zu lösen und C, um AssemblerProgrammierung auf ein höheres Niveau zu katapultieren. Verallgemeinerungen sind sowieso immer mit Vorsicht zu geniessen.
Wie oft bin ich schon von Kollegen ausgelacht worden, nach dem Motto "Das kann man doch gar nicht in XY programmieren, das ist doch [k]eine zyklische ProgrammierSprache!".
Wenn ich das alles tatsächlich nicht hätte programmieren können, weil es angeblich nicht möglich war ... z.B. WerkzeugMagazine in G-Code oder einen Editor in BASIC, jedoch aufgebaut, wie zyklische Programme. Oder ProgrammSchleifen in S5/S7, aufgeteilt auf mehrere Zyklen. Oder zyklische Programme in PASCAL oder C (FANUC-Steuerungen). Wenn man weiss, was man tut und, wenn man sich notfalls etwas einfallen lässt, wie man mit vermeintlichen Hürden umgeht ... warum nicht?

Ich behaupte auch nicht, wer über eine Hochsprache in die Programmiererei eingestiegen ist, der ist dadurch für alle Zeiten so "versaut", dass er niemals mit der zyklischen Programmierung klarkommen kann.
Umgekehrt genau so wenig.
Natürlich kann man beides beherrschen und gaaanz viele bis alle beherrschen auch beides - spätestens nach einer kleinen EingewöhnungsPhase.
Dass der Umstieg vom einen Bereich in den anderen am Anfang vielen schwer fällt, das müssen wir nicht wegdiskutieren, dafür gibt es allein in diesem Forum genügend Belege.
Und, dass man für den Umstieg keine "übernatürlichen" Fähigkeiten benötigt, müssen wir hoffentlich auch nicht diskutieren.

Und, dass boolsche Variablen in der SPS-Technik eigentlich mal ganz simple Bits und somit ganz "normale" Bestandteile von Bytes, Worten, DoppelWorten u.s.w. waren und mittlerweile anscheinend nicht mehr sind, dem können wir nun nachtrauern. Die vielen verschiedenen Sprach-, Versions- und CPU-abhängigen Varianten, um an die Bits in nicht booleschen Variablen heranzukommen, machen mich ganz schwindelig. Aber nicht nur mich, wie man viel zu oft diesem Forum entnehmen kann.

Gruss, Heinileini

 

[getOptimum]

SCL sauber/ strukturiert programmieren

Selbst wenn es gekonnt programmiert ist, es ist kaum zu debuggen, schwer erweiterbar und für andere wie auch später für einen selbst nicht mehr oder nur noch schwer zu dechiffrieren.

Sehe ich exakt auch so.
Zumal der Debugger bei TIA immer noch lausig ist im Vergleich zu CODESYS.
DV = SCL
I/Os = KOP/FUP
Wozu hat man sonst die Möglichkeiten der IEC 61131-3?


Gesendet von iPhone mit Tapatalk

 

[jasko]

Zuviel Werbung?
-> Hier kostenlos registrieren

:shock: was habe ich da bloß in Bewegung gesetzt????

 

[Heinileini]

:shock: was habe ich da bloß in Bewegung gesetzt????

Ei nee La wie nee

 

[Larry Laffer]

... ich habe das jetzt mal aus dem anderem Beitrag heraus-isoliert ... die ganze Meinungs-Geschichte gehört m.E. da nun wirklich nicht herein. Jetzt darf sich aber gerne weiter ausgetobt werden

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich programmiere beide Ansätze (KOP/FUP/SCL und nur SCL) (wegen Kundenwünschen) und muß sagen, man kann sich an beide Varianten recht gut gewöhnen.
Logik in SCL ist ein wenig anstrengender, aber wenn man es ein wenig struturiert (Klammern versetzt etc.) kommt man klar.
KOP/FUP/SCL ist für mich irgendwie schöner, komplizierte Logik (Freigaben einers Servos in Handlings können es in sich haben) dann in KOP/FUP, Bausteinaufrufe, Berechnungen etc, in SCL, denn große Bausteine in KOP/FUP erreihen locker mal mehr als eine Bildschirmlänge, das ist dann auch wieder ätzend. Seitdem man in KOP/FUP-Bausteinen SCL-Netzwerke programmieren kann mache ich das auch, schön ist hier, dass man immer noch Netzwerke mit Überschriften hat, das hat man ja bei reinen SCL-Bausteinen inzwischen mit den REGION-Pragmas in ähnlicher Weise.

Immer dran denken, "Was der Bauer nicht kennt ..." Man muß es erst einmal eine Weile selbst in beiden Versionen gemacht haben, ehe man das wirklich vergleichen kann.

 

[hucki]

Logik in SCL ist ein wenig anstrengender, aber wenn man es ein wenig struturiert (Klammern versetzt etc.) kommt man klar.

Gerade das von MFreiberger vorgeschlagenbe Aufteilen in mehrere Zeilen:

#Ergebnis :=
#Bedingung1 AND
#Bedingung2 OR
#Bedingung3;

erleichtert Fehlersuchen in SCL, weil einzelne Zeilen einfach auskommentiert werden können und auch die Variablenanzeige bei TIA zu den einzelnen Zeilen passt.

 

[Ralle]

Gerade das von MFreiberger vorgeschlagenbe Aufteilen in mehrere Zeilen:erleichtert Fehlersuchen in SCL, weil einzelne Zeilen einfach auskommentiert werden können und auch die Variablenanzeige bei TIA zu den einzelnen Zeilen passt.

Richtig, mach ich auch so aber AND und OR vorn dran. Aber das ist auch reine Gewöhnungssache.

#Ergebnis :=            #Bedingung1
                    AND #Bedingung2 
                    OR
                   (     #Bedingung3
                     AND #Bedingung4)

;

So ungefähr. Hauptsache, man kann es gut unterscheiden und Gruppen erkennen.

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Huch genauso wie Ralle mach ich das auch,
Alte Gewohnheit aus AWL Zeiten.

 

[hucki]

Alte Gewohnheit aus AWL Zeiten.

Keine AWL-Zeiten und trotzdem genau so...


Blöd ist nur, dass die TIA-Smart-Einrückfunktion diese Schreibweise so gar nicht mag und das immer sonstwohin verschiebt (ich weiß, kann man abschalten - aber das will ich nun auch wieder nicht ganz).
:evil:

 

[blimaa]

So wie Ralle mache ich das auch aber nicht wegen AWL Vergangenheit (obwohl es diese gibt ), sondern zum Debuggen ist es besser, da man nicht immer zuerst aufklappen muss).
Das Einrücken finde ich mittlerweile nicht mehr so schlecht. Müsste nur noch den Shortcut herausfinden um alles richtig einrücken zu lassen

Auch Schrittketten finde ich mit SCL (Switch Case) einfacher umzusetzen als in KOP/FUP.
Jeder hat halt seine vorlieben