Gerüch(t)e und Wahrheit zu SCL

Lipperlandstern · 15 März 2008

Question_mark schrieb:
Hallo,

Quod esset demonstrandum ...

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

Gruß

Question_mark

Hallo QM.

Nun gib doch endlich zu, das Dir ein kleiner Teil der S5-Welt entgangen ist.......*ROFL*

Ist doch nicht schlimm.......

Grüsse aus dem Lipperland

Axel

Question_mark · 15 März 2008

Gerücht oder Wahrheit

Hallo Lipperlandstern,

Lipperlandstern schrieb:
Nun gib doch endlich zu, das Dir ein kleiner Teil der S5-Welt entgangen ist

Wenn mich jemand davon überzeugen kann, gebe ich das gerne zu. Nur die bisherigen Links stammen alle aus Simatic-Katalogen. Und da hat schon manches gestanden, was nie das Siemens Entwicklungslabor verlasssen hat.
Ich habe selber mal recherchiert und nur eine Produktankündigung aus 1996 gefunden. Da wurde ein S5-SCL in Verbindung mit dem S5DOS-MT V6 unter Flexos angekündigt. Hat mich auch noch nicht so richtig überzeugt. Ich hatte gehofft, irgend ein User hier im Forum könnte das mit dem S5-SCL bestätigen oder auch widerlegen. Aber so wichtig ist das nun auch wieder nicht, Schnee von gestern...

Gruß

Question_mark

godi · 15 März 2008

Question_mark schrieb:
Hallo Lipperlandstern,

Wenn mich jemand davon überzeugen kann, gebe ich das gerne zu. Nur die bisherigen Links stammen alle aus Simatic-Katalogen. Und da hat schon manches gestanden, was nie das Siemens Entwicklungslabor verlasssen hat.
Ich habe selber mal recherchiert und nur eine Produktankündigung aus 1996 gefunden. Da wurde ein S5-SCL in Verbindung mit dem S5DOS-MT V6 unter Flexos angekündigt. Hat mich auch noch nicht so richtig überzeugt. Ich hatte gehofft, irgend ein User hier im Forum könnte das mit dem S5-SCL bestätigen oder auch widerlegen. Aber so wichtig ist das nun auch wieder nicht, Schnee von gestern...

Gruß

Question_mark

IBN-Service hat ja schon im Beitrag 12 geschrieben das er es selbst verwendet hat!

maxi · 25 März 2008

Larry Laffer schrieb:
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

Jemand anderes an einer normalen Anlage hat aber kein SCL.
Umgekehrt wirst du in der Prozesstechnik eher wneiger finden die AWL können.

maxi · 25 März 2008

Lipperlandstern schrieb:
Hallo QM.

Nun gib doch endlich zu, das Dir ein kleiner Teil der S5-Welt entgangen ist.......*ROFL*

Ist doch nicht schlimm.......

Grüsse aus dem Lipperland

Axel

Wer will den schon freiwillig etwas an einer s5 machen?

Ich lang ausser mit Geldmotivationen usw. so etwas altes, vergammeltes, schäbiges, überholtes, stromfressendes, igitigit ned an

Andreas · 25 März 2008

HEY!
Lass die S5 in RUH! Die iss voll OK

Gruß
Andi

Perfektionist · 26 März 2008

kiestumpe schrieb:
...
auf die Gefahr hin, Sturm zu ernten
...

nur mal rein wissenschaftlich, ganz ohne Leidenschaft ...

kiestumpe schrieb:
...
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..
...

kiestumpe schrieb:

...

Code:

    q := FALSE;
    IF Z < 32767 THEN
        IF FLANKE AND NOT FL_BIT THEN
            Z:=Z+1;
        END_IF;
    ELSE
        q := TRUE;
   END_IF;
    IF RESET THEN
        Z := 0;
    END_IF;
    FL_BIT := FLANKE;
 
  FC192 := q;

Größe: 146 Bytes

das würde bei mir in AWL so aussehen:

Code:

      ON    #FLANKE
      O     #FL_BIT
      SPB   m001
      L     1
      L     #Z
      +I    
      U     OV
      =     #q
      SPO   m001
      T     #Z
m001: U     #FLANKE
      =     #FL_BIT
 
      UN    #RESET
      SPB   m002
      R     #q                 // EDIT !!!!!!
      L     0
      T     #Z
m002: NOP   0

So, je nachdem, wie man nun den Speicherbedarf ermittelt, komme ich auf große bis kleine Zahlen.

Brutto, das komplette Programm inklusive Aufruf etc. will 428 Bytes Ladespeicher. Arbeitspeicher Code 194 Bytes, Daten 44 Bytes, 238 gesamt.

Netto betrachtet, nur den Code an sich, komme ich auf 68 Bytes Ladespeicher und 62 Bytes Arbeitsspeicher (ich habe den Code im FB dupliziert und den Zuwachs gemessen).

Also, nur rein wissenschaftlich (weil ich nicht über SCL verfüge und es daher nicht selbst prüfen kann): wie hast Du Deine Codegröße gemessen?

EDIT:
habe das Verhalten vom Ausgang #q noch im Code korrigiert - siehe dortiges EDIT - damit wächst der Speicherbedarf nochmals geringfügig - Anhang habe ich unverändert gelassen

Perfektionist · 3 April 2008

jetzt hab ich endlich mal ein SCL-Programm in die Finger gekriegt ...

Bei den Schulungsunterlagen http://www.automation.siemens.com/fea/html_00/down_module.htm hab ich den Block C2 "SCL" gefunden - und ein SCL-Beispielprogramm mit Blähungen:

Code:

                   SCL  AWL
Lokaldaten          10    0
MC7                 90   44
Ladespeicher       188  140
Arbeitsspeicher    126   80
Codeverdopplung     72   42

Codeverdopplung: damit habe ich den Zuwachs an Arbeitsspeicherbedarf gemessen, wenn ich den Programmcode im Baustein verdoppelt habe. Fazit: das Beispielprogramm von Siemens ist gegenüber dem von mir entworfenen AWL-Code um Faktor 1,7 länger im Arbeitsspeicher, über die Laufzeiteffizienz möchte ich wegen der Real-Arithmetik schon gar nicht reden.

um den SCL-Code zu optimieren: kann die Variable Ergebnis auch als Integer deklariert werden? Oder ist der Rückgabewert von SQR() grundsätzlich ein Real?

Larry Laffer · 3 April 2008

Hallo Perfektionist,
was du da beschreibst ist m.E. das generelle Problem von Compilern. Trotzdem gibt es Aufgabenstellungen (z.B. Schleifen-Bearbeitungen oder komplexere Formeln), wo ich auf einen Code-Zuwachs sch..., da ich durch den Compiler einen eleganteren, besser lesbaren Code erhalte - nicht in AWL aber in der Ausgangssprache ... hier SCL.

Gruß
LL

zotos · 3 April 2008

Der Vergleich hinkt. Der SCL-Code in dem Beispiel ist ja auch nicht auf Größe optimiert. Man könnte die Aufgabe sicher auch umständlicher in AWL lösen.
Hier mal eine abgewandelte Version vom SCL Code.

Code:

FUNCTION Quadrat : INT
// Quadriert eine Zahl im Integer-Format wenn der Betrag <= 181 ist
// Rückgabewert ist das Ergebnis des Quadrates oder -1 im Fehlerfall
// Der Rückgabewert ist im Integer Format

VAR_INPUT
  Zahl      :INT;                   //Eingangsvariable definieren
END_VAR

BEGIN
  IF ABS(Zahl) <=181 THEN           //Prüfen ob der Betrag der Zahl <= 181
    Quadrat := Zahl*Zahl;           //Wenn ja, Ergebnis ist Quadrat der Zahl
  ELSE
    Quadrat:= -1;                   //Wenn nein, Ergebnis ist -1
  END_IF;
END_FUNCTION

Das was der Compiler daraus mach ist sich auch noch größer aber ich würde da nicht von einer Aufblähung sprechen. Er fügt die Bie-Bits Behandlung noch hinzu.

@Perfektionist: Dein AWL Code hat übrigens ein anderes Verhalten bei negativen Zahlen als das SCL Beispiel das Dir als Vorlage diente.

Perfektionist · 3 April 2008

zotos schrieb:
...
@Perfektionist: Dein AWL Code hat übrigens ein anderes Verhalten bei negativen Zahlen als das SCL Beispiel das Dir als Vorlage diente.

ja, der erste Vergleich hätte natürlich auf -181 lauten müssen
Altes Basic-Leiden - bei SQR denkt der alte Knochen halt reflexartig an einen anderen Wertebereich

Perfektionist · 3 April 2008

... und überhaupt: seit wann mach ich mir als AWL-Proggi vor einer Berechnung Gedanken über den Wertebereich?

Code:

FUNCTION "awl-quadrat" : VOID
TITLE =
VERSION : 0.1
 
VAR_INPUT
  I_Wert : INT ; 
END_VAR
VAR_OUTPUT
  Q_Wert : INT ; 
END_VAR
BEGIN
NETWORK
TITLE =
      L     #I_Wert; 
      PUSH  ; 
      *I    ; 
      UN    OV; 
      SPB   m001; 
      L     -1; 
m001: T     #Q_Wert; 
END_FUNCTION

MC7: 24Bytes

ist es in SCL möglich, OV auszuwerten?

zotos · 3 April 2008

Perfektionist schrieb:
...
ist es in SCL möglich, OV auszuwerten?

Meines Wissens nach nicht.

Jetzt haben wir eine sehr kleine Aufgabe durchexerziert. Sollen wir uns jetzt den anspruchsvolleren Aufgaben widmen?

Perfektionist · 3 April 2008

zotos schrieb:
... Sollen wir uns jetzt den anspruchsvolleren Aufgaben widmen?

ja, da muss ich jetzt mal ran, da hab ich nämlich noch immer was im Hinterkopf:
http://www.sps-forum.de/showthread.php?t=16981
Damit kann ich mir als AWL-Mensch einen schönen Abend versauen

Wolflesch · 24 April 2008

AWL als Quelle

Hallo ich wollte mal fragen was der Vorteil von AWL als Quelle ist , ist das der Funktionswert. Wie lädt man eigentlich eine Quelle in die CPU oder PLC-Sim.

tarzipan7 · 20 Mai 2008

Hallo

Wie sieht es denn aus mit der Debug-Info?
Wenn ein Baustein im SCl erstellt wird, bei dem auf einen DB > ca. 512 Byte zugegriffen wird, keine Debug-Info mehr erstellt werden kann?
Ist doch völliger Schrott.

Gerüch(t)e und Wahrheit zu SCL

Lipperlandstern

Level-3

Question_mark

Level-1

godi

Level-1

maxi

Level-2

maxi

Level-2

Andreas

Level-1

Perfektionist

Level-1

Anhänge

Perfektionist

Level-1

Anhänge

Larry Laffer

Super-Moderator , User des Jahres 2008-2009

zotos

User des Jahres 2007

Perfektionist

Level-1

Perfektionist

Level-1

zotos

User des Jahres 2007

Perfektionist

Level-1

Wolflesch

Level-1

tarzipan7

Level-2

Gerüch(t)e und Wahrheit zu SCL

Level-3

Level-1

Level-1

Level-2

Level-2

Level-1

Level-1

Anhänge

Level-1

Anhänge

Super-Moderator , User des Jahres 2008-2009

User des Jahres 2007

Level-1

Level-1

User des Jahres 2007

Level-1

Level-1

Level-2

Privacy & Transparency

Privacy & Transparency