TIA SCL Laufzeitoptimierung

Zuviel Werbung?
-> Hier kostenlos registrieren
Morgen erstmal...

Mal was grundsätzliches zu diesem Forum: Beleidigen lassen muss ich mich nicht und wer nichts fachliches zu sagen hat, sollte mal besser ruhig sein!

Dachte dies währe ein Forum indem sich Programmierer und Softwareentwickler sich austauschen können...

Persönlich habe ich mich die letzten Tage um SCL gekümmert und so einiges gelernt. Und Ihr?

Wer nichts ändert kann nichts verbessern und wer sich keine Gedanken macht lernt nichts neues.
Macht nur weiter so...

Oh, danke für die Standpauke, wir werden nun in uns gehen und deiner Worte gedenken.

Ich weiß ja nicht, wie lange du schon programmierst und wie oft du das Forum so nutzt, aber wenn du bei diesen leisen Worten schon am Heulen bist, frag ich mich ernsthaft, was mit dir in extremeren Steßsituationen so los ist. Harte Ausrutscher werden hier ganz sicher geahndet. Ansonsten ist m.E. bisher nichts passiert, was deine Beschwerde rechtfertigt.

Aber ich will auch was zum Thema sagen:

Zumindest in Step7 V5.5 kann man sich den übersetzten Code ja ansehen. Ich bin zwar auch nicht der Meinung, das der Compiler das immer optimal macht, aber in einigen Fällen geht er da schon recht clever vor (Nutzung von TAK usw.) Ansonsten hat man leider keine Garantie, wie genau er das übersetzt, besonders bei Versionsänderungen kann sich das deutlich im Ergebnis unterscheiden. Der Rat mit IF ... then ... Else ist schon ein wenig amüsant, denn genau wegen dieser Möglichkeiten nutzt man SCL ja, sonst kann ich auch gleich weiter in AWL programmieren. Ohnehin gibt es ein paar Dinge (viel reine Logic im Code) die ich in SCL (und auch ST) nicht schön finde, aber man kann nicht alles haben. Wirklich zuverlässig optimalen Code bekommt man natürlich am ehesten auf der untersten Ebene, das wäre hier AWL, aber auch das hängt dann vom Können und Wissen des Programmierers ab. Zumindest Nachdenken, sollte man auch in SCL, das betrifft z.Bsp. den Einsatz von Schleifen. Wer da planlos agiert (und es geht ja so schön einfach) zwingt die schnellste SPS in die Knie.
 
Na endlich mal ein paar klare Worte. Bisher kam ja nur: Blos nichts optimieren, das kann ja keiner mehr lesen.

Also IF THEN generiert einen Sprung der ggf. vermieden werden kann: Hier mal 3 Beispiele:

- IF #WERT >100 THEN;
#Bit:=TRUE;
ELSE;
#Bit:=FALSE;
END_IF;
=> #Bit:= #WERT > 100;

- IF #Bit1 THEN;
#Bit2:=True;
END_IF;
=> #Bit2 := #Bit2 OR #Bit1;

- IF #Bit1 THEN;
#Bit2:=False ;
END_IF;
=> #Bit2 := #Bit2 AND NOT( #Bit1);
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Zeile:

WORD_TO_BLOCK_DB(#Verbindung[#Cnt].DB_SEND).DW(40) := #Verbindung[#Cnt].IP_Data.TSAP_ID_01_remote;

Generiert 68Byte Code, finde ich was viel. Bei mehreren solcher Zeilen lohnt die Nutzung des Tempbereiches und ein Block-Move.

Eine Typwandlung generier12Byte Code. Mit der AT-Funktion geht es auch mit 0 Byte!

Im Übrigen: Es ist in diesem Beispiel egal was die Zeile oben im Detail macht!
 
Na endlich mal ein paar klare Worte. Bisher kam ja nur: Blos nichts optimieren, das kann ja keiner mehr lesen.

Würde ich so nicht unterschreiben. Wenn Du das so aus den Antworten gelesen hast, ist das einfach nicht korrekt interpretiert.

Du schreibst:
Wer nichts ändert kann nichts verbessern und wer sich keine Gedanken macht lernt nichts neues.
...willst Dich aber auch nicht mit dem Gedanken anfreunden, dass lesbarer Code ggf. über die Performance gestellt werden sollte.
Die Antworten waren alle ernst gemeint. Dass diese dann etwas abgedriftet sind mag auch daran liegen, dass Du Dich als ein wenig "beratungsresistent" gezeigt hast.
Die meisten der user habe schon etliche Jahre auf dem Buckel, da darf man einen Rat auch mal annehmen, selbst wenn dieser vielleicht nicht so lautet wie Du Dir das gewünscht hättest.
 
Die meisten der user habe schon etliche Jahre auf dem Buckel, da darf man einen Rat auch mal annehmen, selbst wenn dieser vielleicht nicht so lautet wie Du Dir das gewünscht hättest.
wobei man m.E. durchaus mal hinterfragen darf, ob sich hinter dem Rat nicht auch Altersstarrsinn (der, wie man liest, auch seine guten Seiten hat) verbirgt. Auf Lebenserfahrung zu verweisen, kommt allerdings Schopenhauers Kunstgriff#30 nahe. Und dem Totschlagargument „Wenn du mal so alt bist wie ich, wirst du das auch so sehen“.

In der Zwickmühle Performance <--> Lesbarkeit habe ich mich regelmäßig genug befunden. Oftmals ist es dann zugunsten von Performance ausgegangen. Immer wieder stelle ich jedoch auch fest, welchen Wert Lesbarkeit hat. Leider ist aber Lesbarkeit nicht schwarz-weiß entscheidbar. Was dann zu den allseits bekannten Diskussionen (z.B. KOP-FUP-AWL-Debatte) hier im Forum führt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Zeile:

WORD_TO_BLOCK_DB(#Verbindung[#Cnt].DB_SEND).DW(40) := #Verbindung[#Cnt].IP_Data.TSAP_ID_01_remote;

Generiert 68Byte Code, finde ich was viel. Bei mehreren solcher Zeilen lohnt die Nutzung des Tempbereiches und ein Block-Move.

Eine Typwandlung generier12Byte Code. Mit der AT-Funktion geht es auch mit 0 Byte!

Im Übrigen: Es ist in diesem Beispiel egal was die Zeile oben im Detail macht!

Hallo,
ich weiß nicht, ob du hier ganz richtig liegst ...
Die Zeile mit dem Word_to_Block_DB erbringt aufgrund der von dir gewählten Vorgehensweise natürlich einen Riesen-Code, da SCL ein großer Pointer-Ersteller und -Berechner vor dem Herrn ist.
Zu dem Blockmove kann ich so erstmal nichts sagen, meine jedoch, dass du da ggf. Schiffbruch erleiden könntest - da gibt es innerhalb von SCL ein paar Einschränkungen.
Die Sache mit der AT-Sicht verbraucht deshalb keinen Speicher, weil es hier nur um eine andere Sichtweise eines bekannten Speicherbereichs geht - der Fokus liegt hier dann tatsächlich bei SICHT.
Wenn du jedoch so Werte hin und herschiebst dann wird in dem Moment auch wieder Code generiert - in welchem Umfang und ob es verhältnismäßig ist hat mich persönlich noch nie interessiert.
Ich habe aber auch noch nie eine AT-Sicht auf einen Global-DB gemacht, den ich nur symbolisch kenne. ich würde hier behaupten, dass auch das nicht funktionieren wird ...

Gruß
Larry
 
Hallo NBerger,
darf ich Dir ehrlich antworten oder bekommst Du dann wieder einen Heulkrampf?
Anscheinend bin ich etwas aus der Übung, was den Umgang mit hochnäsigen Noobs angeht.
Ich werde den Welpenschützer Auffrischungskurs im Neuen Jahr buchen.

So nun mal zum Thema. Ich kenne ST/SCL jetzt nicht nur vom hören sagen, hin und wieder verdiene ich damit mein Geld.
Das was Du bisher abgeliefert hast, ist in meinen Augen ein Witz und widerspricht dem Grundgedanken der hinter ST (Strukturierter Text) bzw. SCL (Structured Control Language) steht. ST/SCL soll mehr Möglichkeiten bieten den Programm Code zu strukturieren und den Code lesbarer zu machen. Man lehnt sich wie in Hochsprachen an die menschliche Sprache an und nicht wie in Assembler und AWL an die Funktionsweise der CPU. Les Dir mal das Kommentar von IBFS im Beitrag Nr #12 durch und frag Dich mal was er damit wohl ausdrücken wollte.

So nun zu dem Schwachsinn den Du hier ablieferst:

Hier mal 3 Beispiele:

- IF #WERT >100 THEN;
#Bit:=TRUE;
ELSE;
#Bit:=FALSE;
END_IF;
=> #Bit:= #WERT > 100;

- IF #Bit1 THEN;
#Bit2:=True;
END_IF;
=> #Bit2 := #Bit2 OR #Bit1;

- IF #Bit1 THEN;
#Bit2:=False ;
END_IF;
=> #Bit2 := #Bit2 AND NOT( #Bit1);

Das erste Beispielist absolut OK aber die Beispiele 2 und 3 sind unterirdisch schlecht.
zu 2 Selbsthaltung in SCL? Das tut weh.
zu 3 ein Setz- bzw Rücksetzbefehl mit einer Zuweisung? Wo setzt Du den Scheiß und wie setzt Du ihn wieder zurück?!

Übrigens kann man Deinen drecks Code besser lesen wenn Du ihn in die da für vorgesehenen Code Tags setzt.

Code:
Doof := Doof; //Doof bleibt doof.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
SIEMENS hat keine Doku o.ä. bezüglich Laufzeitbelastung durch SCL-Befehle...
Jedoch folgende Tipps:
- IF-THEN vermeiden wenn möglich
- Baustein-Attributen der SCL-Bausteine "Erweiterte Statusinformationen erstellen" deaktivieren
- Der Zugriff auf temporäre Variablen ist schneller

So eine Antwort habe ich von der Siemens Hotline erwartet...

Das mit IF/THEN haben die vermutlich in meinem Post #3 gelesen :confused:

Und das mit den Temp-Variablen wird Dir vermutlich bald auf die Füsse fallen, wenn die "aus versehen" mal den Inhalt im nächsten Zyklus abfragen willst... Dadurch entstehen sowas von unvorhersehbare Fehler, dass ich TEMP so gut wie nie verwende.

der Rest ist schon gesagt...
Gruß.
 
Was ich selbst bei wohlwollendster Betrachtung auch nicht verstehe:
Ist doch heutzutage ziemlich egal, wie "groß" der Code wird, die CPUs haben speichermäßig ja massiv aufgerüstet.
Ob der jeweilige Code nun aber "schnell" oder "langsam" ist lässt sich damit noch nicht mal im Ansatz erkennen.

Das extremste Beispiel wären hier jetzt Schleifen jeglicher Art, in der Kurzform also wenig Programmspeicher aber viel Laufzeit.

Kurzum, du hast bei SCL keine Chance zielsicher vorherzusagen was der Compiler daraus macht und bezogen auf die Laufzeit von irgendwas schon überhaupt nicht.
Der SCL Kompiler dessen Arbeit man (wegen AWL) wenigstens halbwegs nachvollziehen kann, geht da teilweise wirklich richtig Klever vor.

Temp-Variablen sicherlich, aber nur mit den altbekannten Einschränkungen ...

Mfg
Manuel
 
Mit der Zuweisung statt IF-THEN sehe ich ein.

Schon mal "ENO automatisch setzen" oder "Array-Grenzen prüfen" aktiviert?
Da kommt schnell der dreifache Speicherbedarf bei raus.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Schon mal "ENO automatisch setzen" oder "Array-Grenzen prüfen" aktiviert?
Da kommt schnell der dreifache Speicherbedarf bei raus.
Aber auch hier wieder
Speicher ungleich Laufzeit

Wenn dann müsstest du schon so eine Art Benchmark machen,
also den fertigen SCL-Baustein x-Mal in einer Schleife aufrufen, und dann die Zykluszeit beobachten.
 
Zurück
Oben