Gerüch(t)e und Wahrheit zu SCL

kiestumpe

Level-1
Beiträge
726
Reaktionspunkte
84
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

aus aktuellem Anlass (und auch auf die Gefahr hin, Sturm zu ernten) möchte diesen Thread für alle zur jener ST/SCL-Sekte gehörigen Fraktion eröffnen. ;)
Und jene, die sie bekehren wollen.

(Vielleicht muss gehörts auch unter Stammtisch)

Gerücht Nr.1: SCL verursacht Blähungen ;).
Bzw. ist Ressourcen verbrauchend und kostet viel Speicherplatz.
Wer sich die Mühe machen will, kann den SCL-Zähler unter:
http://www.sps-forum.de/showthread.php?t=18651&page=3
gern mal anders implementieren, wer bei gleicher Funktionalität den Speicherbedarf signifikant erniedrigt, darf das Gerücht gerne behaupten..

Gerücht Nr2: Komplizierte Sachen lassen sich eh nur in AWL programmieren:
Der solle sich mal an folgendes Beispiel machen und das Verhalten eines Tankes nachprogrammieren, nach folgenden Daten (Anhang).
Gerade in der Verfahrenstechnik ist das Ding für Programmtests sehr nützlich. Wer es schafft mit AWL unter ein kB zu kommen und es in einem Jahr noch zu ändern, darf auch Gerücht Nr.2 gerne als wahr sehen. Funktionieren soll's natürlich auch ;-)
Der Baustein hat in der derzeitigen Ausführung 1354Bytes Größe, die Instanz liegt bei 164Bytes
 

Anhänge

  • TankDaten.pdf
    8,3 KB · Aufrufe: 200
Zuletzt bearbeitet:
Werter Herr sps-concept,
auch wenn Sie es nicht wahr haben wollen. Man schaut sich doch den Code in der Form an wie es ihnen der Kollege kiestumpe gezeigt hat.
Schauen Sie sich Ihre :TOOL:s auch immer im Maschinen Code an? Soweit ich informiert bin Programmieren Sie Ihre :TOOL:s doch auch in VisualBaisc und nicht in Assembler.

Klar fällte es Ihnen schwer die Ausführung von dem geschätzten Kollegen kiestumpe zu verstehen.
Da ihre Programme ja anscheinend auch das Verunden von Drei Eingängen beschränkt sind. Um komplexe Aufgaben lösen zu können braucht man eine Strukturierte Programmierung.
 
Selbst bei einer reinen Bitverknüpfung, erzeugt SCL bei effizienter Programmierung desjenigen
der VOR dem Bildschirm sitzt, nach dem kompilieren ziemlich genau 5? Zeilen mehr Code
als das reine AWL.

Und diese 5 Zeilen beziehen sich allesamt auf Bie-Bit.

Ergo, wie effizient der SCL-Code ist, wird vorm Bildschirm entschieden.

Code:
//Aus SCL:
A1.0:= E1.0 AND E1.1 AND E1.2;

wird:

Code:
      SET   
      SAVE  
      =     L      0.1
      U     E      1.0
      U     E      1.1
      U     E      1.2
      =     A      1.0
      U     L      0.1
      SAVE

Edit: Und das Handling des Bie-Bits ist auch gut so, für einen Allgemein-gültigen Compiler, um derartige Probleme: http://www.sps-forum.de/showthread.php?t=18631 zu vermeiden.

Mfg
Manuel
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Vielleicht liegt das Missverständnis auch an der unterschiedlichen verstehensweise von "Kompliziert".:rolleyes:
Für SPS-Concept scheints die dreifach UND-Verknüpfung zu sein, für mich wär's der oben beschrieben Baustein. :ROFLMAO:
... und tschüss
 
Bezeichnend ist natürlich schon wieder, das ein gewisser andré r schon mal wieder den
Schwanz eingezogen hat, und den Beitrag um den es die letzten Beiträge ging,
also den zwischen 13:00 und 13:12 gelöscht hat.

Mfg
Manuel
 
Bezeichnend ist natürlich schon wieder, das ein gewisser andré r schon mal wieder den
Schwanz eingezogen hat, und den Beitrag um den es die letzten Beiträge ging,
also den zwischen 13:00 und 13:12 gelöscht hat.

Mfg
Manuel
Das ist normal bei ihm, das macht der öfter.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

aus aktuellem Anlass (und auch auf die Gefahr hin, Sturm zu ernten) möchte diesen Thread für alle zur jener ST/SCL-Sekte gehörigen Fraktion eröffnen. ;)
Und jene, die sie bekehren wollen.

(Vielleicht muss gehörts auch unter Stammtisch)

Gerücht Nr.1: SCL verursacht Blähungen ;).
Bzw. ist Ressourcen verbrauchend und kostet viel Speicherplatz.
Wer sich die Mühe machen will, kann den SCL-Zähler unter:
http://www.sps-forum.de/showthread.php?t=18651&page=3
gern mal anders implementieren, wer bei gleicher Funktionalität den Speicherbedarf signifikant erniedrigt, darf das Gerücht gerne behaupten..

Gerücht Nr2: Komplizierte Sachen lassen sich eh nur in AWL programmieren:
Der solle sich mal an folgendes Beispiel machen und das Verhalten eines Tankes nachprogrammieren, nach folgenden Daten (Anhang).
Gerade in der Verfahrenstechnik ist das Ding für Programmtests sehr nützlich. Wer es schafft mit AWL unter ein kB zu kommen und es in einem Jahr noch zu ändern, darf auch Gerücht Nr.2 gerne als wahr sehen. Funktionieren soll's natürlich auch ;-)
Der Baustein hat in der derzeitigen Ausführung 1354Bytes Größe, die Instanz liegt bei 164Bytes


SCL ist für Ingeneuere un Prozesstechniker die auf Grund ihrer Ausbildung nocht sehr tief in eine Programmierung und Hardware einsteigen konnten sehr vorteilhaft.
Es lässt für Sie (ein Programmierer würde da er im Detail arbeitet das gegenteil sagen) sehr einfache Denkweise der Programmierung zu.
SCL hat gerade in der Prozesstechnik ganz klar dadurch einen festen und gleichwertigen Platz verdient.
SCL würde sich aber in der Anlagentechnik auch klar nicht praktikabel erweisen.
 
Bezeichnend ist natürlich schon wieder, das ein gewisser andré r schon mal wieder den
Schwanz eingezogen hat, und den Beitrag um den es die letzten Beiträge ging,
also den zwischen 13:00 und 13:12 gelöscht hat.

Mfg
Manuel

Ach so.... deswegen verstehe ich Zusammenhänge nicht.... Schade eigentlich das man so etwas macht. Eigentlich sollte man zu dem stehen was man geschrieben hat.... oder gar nicht erst abschicken...
 
Vielleicht liegt das Missverständnis auch an der unterschiedlichen verstehensweise von "Kompliziert".:rolleyes:
Für SPS-Concept scheints die dreifach UND-Verknüpfung zu sein, für mich wär's der oben beschrieben Baustein. :ROFLMAO:
... und tschüss


Stomme dir da zu das es mit der Sichtwiese und dem erlernten zu tun hat.
Früher mussten wir in der Digitaltechnik auch x=A and B or C lernen udn als negierungen etc. dann striche drüber
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo kiestumpe,

zu den von dir genanten Gerüchten möchte ich folgendes sagen:

Um Flankenmerker oder einfache SR - Glieder zu codieren, würde ich
nicht SCL benutzen, da unterscheidet sich evtl. der "Hochsprachenprogrammierer"
vom erfahrenen SPS-Programmierer.

Auch sollte man einen SCL - Baustein nicht am generierten AWL-Code
bewerten. Der AWL-Code sollte dann tabu sein, eine Bausteinänderung
oder Diagnose nur über den SCL - Editor erfolgen.

Will man die Möglichkeiten der SPS richtig ausschöpfen und dabei
transparent und strukturiert bleiben, ist es notwendig,
die zur Verfügung stehenden Sprachen und Werkzeuge sinnvoll
zu nutzen!


SCL (z.B. für mathematische Algorithmen und komplexe Feldzugriffe)
und
S7-Graph (für größere Ablaufsteuerungen mit alternativen und simultanen Verzweigungen)
sind hierbei praktische und leistungsfähige Werkzeuge, die ich nicht missen möchte.


Allerdings ist das Step7 - SCL hinsichtlich Codegenerierung dem alten
Step5 - SCL deutlich überlegen.
Das Step5 - SCL war eine fürchterliche Ressourcenschleuder, hauptsächlich
wegen der vielen indirekten Zugriffe / Adressberechnungen.

Beispiel:

Vor einigen Jahren habe ich einen komplexen Auswahl - Algorithmus, der über
verschachtelte Schleifen aus verschiedenen Feldern wählen, sortieren
und zusammenstellen musste, mit Step5 - SCL programmiert.

Der SCL-Baustein war recht groß und hat eine erhebliche Zykluszeit
benötigt.

Daraufhin habe ich die Funktion nochmals in AWL codiert.
Der S5 - AWL Baustein war ca. um den Faktor 3 kleiner und schneller!

Allerdings hat die Erstellung des S5-AWL Bausteins auch ca. 3 mal
länger gedauert...

Unter S7 habe ich dann den alten SCL - Code neu generiert,
mit folgendem Ergebnis:


Hinsichtlich Bausteingröße und Zykluszeitbelastung war kein
signifikanter Unterschied zum S7-AWL Baustein mehr festzustellen, der
SCL-Baustein war (wohl aufgrund der optimierten Sprungverteilung)
sogar geringfügig schneller.


Fazit:
Wenn man SCL für die richtigen Zwecke einsetzt, erhält man optimierten
Code und eine transparente Programmdarstellung, die auch nicht -
SPSler verstehen können.
Wenn man SCL für einfache binäre Dinge einsetzt, wie Flankenmerker
usw., dann hat man vielleicht noch nicht die richtige Erfahrung in
Sachen SPS - Programmerstellung.

Nachteil von Step7 - SCL:
Die Diagnose ist umständlich durchzuführen,
darin ist IMHO FUP unschlagbar.


CU

Jürgen
IBN-Service
 
Ach so.... deswegen verstehe ich Zusammenhänge nicht.... Schade eigentlich das man so etwas macht. Eigentlich sollte man zu dem stehen was man geschrieben hat.... oder gar nicht erst abschicken...

Wieder etwas dazu gelernt: Beim Antworten auf Beiträge von sps-concept immer die Zitier/Quote Funktion nutzen. Ach wenn man direkt Antwortet, wer weis ob er in fünf Minuten noch zu seinem Beitrag steht.
 
Neuer Bereich nötig..

Hi,
@zotos

ein neuer Forum Bereich wäre nicht schlecht: "Kindergarten"

Da können bestimmte Leute gerne posten, und löschen, und posten..und weinen..:ROFLMAO:

Vladi
 
Zuviel Werbung?
-> Hier kostenlos registrieren
SCL würde sich aber in der Anlagentechnik auch klar nicht praktikabel erweisen.

Und nun auch noch mein Beitrag dazu ... tut mir leid.
Ich programmiere Anlagen ... und bei keiner von den neuen, die ich bei uns im Hause gemacht habe, möchte ich SCL missen müssen. Ich gebe allerdings zu, das ich meine Schrittketten (noch) nicht in SCL schreibe ... kommt aber vielleicht auch noch.
Mir ist es dabei schnurzegal, ob der Code etwas länger oder kürzer ausfällt ... die Durchschaubarkeit ist entscheidend. Schon eine einfache Berechnungsformel sieht in SCL entscheidend schöner aus als in AWL. Und sogar meine Elektriker können sie lesen, auch wenn sie nicht selber SCL programmieren können ...

Gruß
LL
 
Allerdings ist das Step7 - SCL hinsichtlich Codegenerierung dem alten
Step5 - SCL deutlich überlegen.
Das Step5 - SCL war eine fürchterliche Ressourcenschleuder, hauptsächlich
wegen der vielen indirekten Zugriffe / Adressberechnungen.

Step 5 SCL??? nie gehört
Würde mich aber brennend Interessieren also wer Unterlagen und Infos hat alles zu mir!!

Ist das SCL ein COM Paket??
 
Quellen bitte !!!!

Hallo,

IBN-Service schrieb:
Allerdings ist das Step7 - SCL hinsichtlich Codegenerierung dem alten Step5 - SCL deutlich überlegen.
Das Step5 - SCL war eine fürchterliche Ressourcenschleuder, hauptsächlich
wegen der vielen indirekten Zugriffe / Adressberechnungen.

Boah ey, ich kann es nicht glauben *ROFL*
Gibt es eine Beschreibung des Step5-SCL irgendwo im www ???
Hab ich irgendetwas verpasst ??? Für Hinweise auf Quellen zum Step5-SCL wäre ich echt dankbar ...

Gruß

Question_mark
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo!

In dem Handbuch zur Programmierung von der S5 155 findet man unter den Literaturhinweisen folgendes:
/12/ Handbuch SCL
Bestell-Nr. C79000-G8500-C162

/13/ S5-C-Compiler für S5-155U
Bestell-Nr. 6ES5 886-1MA11

Und mitten im Handbuch von der CPU 928B:
· in einer höheren Programmiersprache:
Wenn Sie gewohnt sind, Programme in einer höheren Programmiersprache
zu schreiben, können Sie bei der CPU 928B Ihr STEP-5-Programm
auch in folgenden Sprachen formulieren:
- SCL (siehe /12/ – Literaturhinweise, der SCL-Compiler ist in
der PG-Software "S5-DOS/MT" ab Version 6 enthalten.)

Ich schätze mal das es zur S5 135 und 155 einen SCL Compiler gegeben hat und einen C Compiler für die 155 (H)

godi
 
Glaubt Ihr alles was im Katalog steht ???

Hallo,

Quod esset demonstrandum ...

Und die Erwähnung im Handbuch sehe ich nicht als Beweis.

Gruß

Question_mark
 
Hallo,

Quod esset demonstrandum ...

Und die Erwähnung im Handbuch sehe ich nicht als Beweis.

Gruß

Question_mark

Du bist mir ja ein schöner S5 - Profi.
Die größeren Step5 - CPU's der 135U und 155U liesen sich mit dem SCL-Compiler programmieren.

http://support.automation.siemens.c...r=true&siteid=cseus&query2=&modelled=&lang=de

http://support.automation.siemens.c...r=true&siteid=cseus&query2=&modelled=&lang=de

http://support.automation.siemens.c...r=true&siteid=cseus&query2=&modelled=&lang=de

http://support.automation.siemens.c...r=true&siteid=cseus&query2=&modelled=&lang=de

Vielleicht findest du weitere Infos in einem alten S5 - Katalog (älter als 1999)


CU
 
Zurück
Oben