Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 2 von 3 ErsteErste 123 LetzteLetzte
Ergebnis 11 bis 20 von 27

Thema: AWL, KOP oder FUP

  1. #11
    Registriert seit
    24.04.2013
    Beiträge
    306
    Danke
    21
    Erhielt 150 Danke für 86 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hi

    und man sollte die Performanceunterschiede der Sprachen nicht ganz außer acht lassen.

    Bei der 400 geht alles über AWL. Bei linearen Programmen (wer hat das schon) ist die Laufzeit / Zykluszeit proportional der MC7 Länge. Doppelt so viele L MW10 brauchen doppelt so lang.
    Bei der 300 geht auch alles über AWL. Selbst bei linearen Programmen schwankt die Laufzeit / Zykluszeit gegenüber der MC7 Länge. Zumindest bei der 319 gilt der Satz "doppelt so viele L MW10; T MW20; brauchen doppelt so lang" nicht! Man muss schon unterschiedliche Adressen nehmen. Unsinniger Code braucht keine Laufzeit.

    Wenn eine kleine SCL-Zeile oder ein Bausteinaufruf in hunderte AWL Befehle abgebildet wird, dann dauert das eben.

    Bei der 1200 gibt es kein AWL. Das was man mit KOP/FUP und SCL machen kann scheint viel weniger MC7Strich zu brauchen als auf der 400. Entsprechend schneller läuft es. Wobei die 1200 als "Kleinwagen" von haus aus ja nicht gerade schnell ist. Aber ich vergleiche ja die Sprachen. Bausteinaufrufe schlagen trotz aufwändiger Parameterübergabe bei weiten ncht so dramatisch zu wie bei der 400.

    Die 1500 lässt sich nicht in die Karten schauen. Aber den Codespeicherbedarf bekommt man angezeigt. Und der ist genauso wie bei der 1200. Semantisch äquivalentes KOP/FUP und SCL geben sich nix bezüglich der Laufzeit.
    AWL braucht mehr Code und läuft auch noch sehr unterschiedlich schnell. Ein von KOP nach AWL gebrachtes Programm läuft in KOP genauso schnell wie in AWL. Ein reines AWL Programm das mit AR und Anzeigewort hantiert, das ist richtig häßlich langsam.
    Solange man mit Daten in optimierten Bausteinen rechnet dann ist die 1500 deutlich schneller als mit Daten in standard Bausteinen.


    RUNTIME sei dank
    HB


    Hey Big S: Warum kann man eigentlich nicht KOP/FUP und SCL innerhalb eines Bausteins mischen? Wie Ralle schon sagt: Bitschubsen in KOP/FUP. Rechnen und Datenschubsen in SCL. Das wäre ein Traum.

  2. #12
    Registriert seit
    19.07.2010
    Beiträge
    1.267
    Danke
    203
    Erhielt 259 Danke für 229 Beiträge

    Standard

    Zitat Zitat von HelleBarde Beitrag anzeigen
    Unsinniger Code braucht keine Laufzeit.
    Ich hab schon Programme gesehen, die in einer 416 an 100ms kratzen, deiner Aussage nach aber maximal 10ms brauchen dürften.
    mfG Aventinus

  3. #13
    Registriert seit
    24.04.2013
    Beiträge
    306
    Danke
    21
    Erhielt 150 Danke für 86 Beiträge

    Standard

    Hi Aventinus

    lies noch mal was ich schrieb. Es gibt deutliche Unterschiede zwischen 400, 300 (wobei die 319 anders war als die 316), 1200 und 1500.

    bei der 400 wird jede Zeile ausgeführt. Wer 1000 mal L MW10 schreibt, der führt auch 1000 mal L MW10 aus entsprechend lang (Zykluszeit) dauert es.

    bei der 319 ist das nicht so. Wer dort 1000 mal L MW10 schreibt, der kommt viel schneller weg. Die Ausführungsgeschwindigkeit (Zykluszeit) steht nicht mehr im direkt proportionalen Verhältnis zur Codegröße. Hier scheint die 319 selbst zu optimieren. Ob das auch bei einer 314 so ist weiß ich nicht. Ich vermute mal dass das von der Firmware-Version abhängt. Habe das aber nie nachgeprüft.

    bei den 1200 wird durch TIA optimiert. Wer 1000 MOVE boxen mit immer den gleichen Variablen direkt hintereinander schreibt, der bekommt genauso viel Code wie bei einer einzigen MOVE box.

    bei der 1500 wird noch viel mehr optimiert. S. verrät aber nicht was und wie. Ich habe bei meinen Spielereien mit RUNTIME folgendes interessante beobachtet.

    Ein KOP Programm mit einem OB, einem DB, zwei FC. Der OB ruft die FC auf. DB und OB bleiben unverändert. Das Programm wird sowohl bei einer 1214 als auch bei einer 1516 verwendet. Der erste FC enthält ein paar Netzwerke, die eigentlich nix wichtiges machen. Ein bischen Addieren ein bischen subtrahieren. Ein wenig UND und ODER und ein paar Spulen. So zwanzig mittelgroße Netze. Weil ich ja Zeit messen will waren auch ein paar TON dabei. Die Instanzen dafür waren mit im DB. Eigentlich habe ich irgend was aus einem anderen Programm "geklaut", denn ich wollte wissen wie schnell der eine Baustein läuft. Dann habe ich mir im DB dafür eine Testumgebung geschaffen.
    Der zweite FC ist SCL. Der wird nur benutzt um mit RUNTIME die Laufzeit des ersten FC zu vermessen. was ja leider nur mit SCL klappt.

    Vermutung: Wenn ich die zu vermessenden Netze doppelt rein kopiere in den FC, dann sollten sich sowohl die Codegröße als auch die Laufzeit verdoppeln.
    Überraschung: Nein die Laufzeit bleibt im wesentlichen gleich. Selbst die Codegröße bleibt im wesentlichen gleich.

    OK, dann mach ich das halt noch mal. Also eine dritte Kopie und eine vierte Kopie der zwanzig Netzwerke in den FC.
    Überraschung: Die Laufzeit bleibt fast gleich. Die Codegröße bleibt fast gleich.

    Dann habe ich einen zweiten DB erzeugt, eine Kopie des ersten. Bin wieder auf die 2*20 Netz version zurück und habe in den zweiten zwanzig Netzwerke die DB-Zugriffe auf den zweiten DB gebogen -- suchen und ersetzen Jetzt wird ja in den kopierten Netzwerken auf was anderes zugegriffen.
    Vermutung: sowohl die Codegröße als auch die Laufzeit sollten sich verdoppeln.
    Im wesentlichen ja
    Aber jetzt zeigen sich Unterschiede bei 1200 und 1500. Bei der 1200 komme ich sowohl für Laufzeit als auch für Codegröße auf den Faktor 1,9. (Meine TON sind nicht verdoppelt)
    Bei der 1500 komme ich für die Laufzeit auf den Faktor 1,5 und bei der Codegröße auf den Faktor 1,8.

    Wie gesagt, das gilt für die 1200 und die 1500. Nicht für die 400.

    Was mir negativ aufgefallen ist, ist jedoch die Compilezeit. Bei den 20 Netzen kaum zu messen. Bei 10*20 Netzen dauert es Minuten -- soweit ich mich erinnere so 5. Bei 20*20 Netzen dauert es nicht 10 Minuten sondern 17 Minuten. Und bei 100*20 Netzen ist es regelmäßig wegen zu wenig Speicher durch Windows zwangsbeendet worden.

    Hingegen ein Baustein mit 400 Netzen wo sich nichts wiederholt, wird in 3 Minuten übersetzt ... hm. Der Compiler scheint verbesserungsfähig.

    'n schönen Tach auch
    HB
    Geändert von HelleBarde (11.11.2013 um 21:58 Uhr)

  4. Folgende 3 Benutzer sagen Danke zu HelleBarde für den nützlichen Beitrag:

    Ralle (12.11.2013),Rauchegger (11.11.2013),rostiger Nagel (11.11.2013)

  5. #14
    Registriert seit
    29.03.2004
    Beiträge
    5.077
    Danke
    128
    Erhielt 1.475 Danke für 1.087 Beiträge

    Standard

    Zitat Zitat von HelleBarde Beitrag anzeigen
    bei den 1200 wird durch TIA optimiert. Wer 1000 MOVE boxen mit immer den gleichen Variablen direkt hintereinander schreibt, der bekommt genauso viel Code wie bei einer einzigen MOVE box.
    Was für Speicherbereiche hast du da denn hin- und hergeschoben? Vielleicht gibt es ja mittlerweile sowas wie "dead code elimination", also Programmteile die keine Auswirkung haben werden entfernt. Das dürfte in der SPS aber eigentlich nur bei lokalen Temp-Variablen geschehen, da auf alle anderen Bereiche (statische FB Variablen, Merker, Global-DBs) auch von anderen Programmteilen wie Interrupts zugegriffen werden kann (die sind sozusagen volatile).

  6. #15
    Registriert seit
    24.04.2013
    Beiträge
    306
    Danke
    21
    Erhielt 150 Danke für 86 Beiträge

    Standard

    Hi Thomas

    sowohl als auch. Also Lokales und globales. Sonst hätte ich mir die Arbeit mit dem zweiten DB ja nicht machen müssen. Aber so weit ich mich erinnere waren das meiste Inputs, gefolgt von Temp, gefolgt von globalen DB-Zugriffen, gefolgt von Outputs.

    Ich hab mal schenll was ausprobiert. Du hast recht. 100 mal L LD10 verschwindet. 100 mal L MD10 bleibt erhalten. Also jetzt mal nur auf die Codegröße geschaut, die PLCs sind so weit weg.

    cool. Es gibt scheinbar sowas wie "dead code elimination" für 1500.

    Und Konstanten in SCL scheinen auch zu verschwinden. #a[1]:=3+4+5; #a[2]:=3+4+5; #a[3]:=3+4+5; ....
    braucht genauso viel Platz wie #a[1]:=12; #a[2]:=12; #a[3]:=12; ....


    Die werden doch nicht einen richtigen Compiler machen
    HB

  7. #16
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    11.851
    Danke
    500
    Erhielt 2.590 Danke für 1.870 Beiträge

    Standard

    @HelleBarde

    Aber 100*20 Nertwerke, das ist jetzt nicht wirklich viel und gibt mit zu denken

    Wenn man dann einen einzelnen Baustein ändert, dauerst es wieder 17 Minuten oder wird dann wenigstens nicht alles compiliert? Sollte ja so sein.
    Leider konnte ich bei mengen TIA versuchen ebenfalls feststellen, dass es keine wirklichen Regeln für das Ergebnis gibt, das aus dem Code entsteht.
    Das finde ich eigentlich recht unerfreulich für eine SPS, aber ist ja auch bei anderen neuen Systemen nicht mehr viel anders.
    Man weiß im Prinzip nicht mehr, was genau man da codiert...
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  8. Folgender Benutzer sagt Danke zu Ralle für den nützlichen Beitrag:

    ducati (14.11.2013)

  9. #17
    Registriert seit
    24.04.2013
    Beiträge
    306
    Danke
    21
    Erhielt 150 Danke für 86 Beiträge

    Standard

    Zitat Zitat von Ralle Beitrag anzeigen
    @HelleBarde

    Aber 100*20 Nertwerke, das ist jetzt nicht wirklich viel und gibt mit zu denken
    Mir auch, aber wie oben geschrieben: wenn sich nichts wiederholt, dann geht es viel schneller. Offensichtlich kostet die Suche nach dem "unnützen Code" einiges an Zeit.

    Ich finde ja toll, dass sowas wie "dead code elimination" "constant folding" und "value propagation" verwendet wird. Und wenn wir schon von anderen Systemen reden: Beckhoff verwendet beim TWIN CAT System ja einen richtigen C-compiler von Microsoft. Der macht bestimmt noch viel mehr solche Sachen (sprung vorhersagen, register renaming, ... ). Wir wissen immer weniger was die Teile tatsächlich machen. Aber solange die das richtig tun kann es uns doch egal sein. Und wenn man dann liest, was so ein Prozessor heute alles kann und hat (out of order excecution, 3 level von caches, mehrere Kerne, Hyperthreading ... ) , dann bin ich eigentlich froh, dass ich keinen Compiler mache sondern ihn verwende und meckern darf was die anderen alles schlecht machen

    Problematisch ist es wenn der Compiler so ewig braucht wie der von S und noch problematischer wird es wenn das was raus kommt nicht das ist, was in der Referenz darüber behauptet wird -- siehe SCL und dern REAL-bug.

  10. #18
    Registriert seit
    29.03.2004
    Beiträge
    5.077
    Danke
    128
    Erhielt 1.475 Danke für 1.087 Beiträge

    Standard

    Wie viele Anweisung hatte denn ein Netz? Wenn nur eine Anweisung, dann wären das ja nur 2000 Anweisungen, da kann doch keiner 17 Minuten dran rumrechnen diese Anzahl zu übersetzen. In der Zeit übersetzt man einen kompletten Linux Kernel...

    Was das Hauptproblem bei der ganzen Optimiererei ist, dass der Code nachher noch online beobachtbar bleibt.
    Was wird dir in deinem Baustein wo der Compiler die meisten Anweisungen rausgeworfen hat denn online angezeigt?
    Online-Status nur bei einer Anweisung, wird einem bei den anderen Anweisung was vorgegaukelt, oder ist dieser Baustein dann sozusagen ohne Debug-Informationen und nicht beobachtbar?
    Das alles konnte man bei Step 7 am SCL-Übersetzer noch einstellen. Beim TIA-Portal scheinen die ganzen Optionen entfallen zu sein.

    TwinCAT hat imho die Codegenerierung von Codesys übernommen, und bei Codesys ist die Codegenerierung laut Aussage eines 3S Mitarbeiters hier im Forum eine komplette Eigenentwicklung. TwinCAT 3 nutzt das MS Visual Studio nur als Rahmen. Es gibt auch von Atmel das AVR-Studio, welches als GUI ebenfall das Visual Studio verwendet, die Codegenerierung übernimmt aber der (AVR)-GCC.

  11. #19
    Registriert seit
    24.04.2013
    Beiträge
    306
    Danke
    21
    Erhielt 150 Danke für 86 Beiträge

    Standard

    Hi Thomas

    die zwanzig Netzwerke haben so in etwa abgerundet 800 Bytes Code erzeugt. Plus die TON und ein Compare vorne und hinten. Macht dann 900 Bytes. Pro Kopie kommen aber nur rund aufgerundet 100 bytes dazu. Also sind circa 700 Bytes als unnütz betrachtet worden.

    Doch, doch, leider kostet das Finden der 100 unnützen Kopieen 17 Minuten.


    Mir hat vor zwei Jahren einer von Beckhof erzählt, dass der 3S Compiler verwendet wird um aus KOP/FUP/SCL und AWL C zu machen. Das ist bestimmt eine Eigenentwicklung. Und jetzt kämme es drauf an was du für ein Zielsystem hast. Wenn das ein Mehrkern Celeron ist, dann wird das C wird vom Microsoft Compiler in x86 verwandelt. Bei der TwinCat ist da ja noch ein gewaltiges Laufzeitsystem dazuzubinden, bevor aus einem PC104 System eine Steuerung wird.

    Wenn du ein Zielsystem auf ARM-Basis hast, dann sei es der GCC.

    Aber der Beckhof-Mann kam damals schon ziemlich ins schwimmen und schwitzen. Ich wußte schon da nicht, was ist davon Marketing Lüge und wo steckt der wahre Kern des Pudels.


    Gibt es außer 3S, S und KirchnerSoft überhaupt einen Hersteller für IEC 61131-3 Sprachen? Mir fallen nur die drei ein, obwohl es zig Steuerungshersteller gibt. Aber die verwenden alle 3S. Halt, da ist ja noch VIPA, die haben auch eine IDE.

    'n schön' Tach auch
    HB

  12. #20
    Registriert seit
    09.08.2006
    Beiträge
    3.141
    Danke
    762
    Erhielt 557 Danke für 465 Beiträge

    Standard

    hmm, höher schneller, weiter, bunter... ich werd langsam (zu) alt...

Ähnliche Themen

  1. SCL vs. FUP/KOP/AWL
    Von flicflac im Forum Simatic
    Antworten: 5
    Letzter Beitrag: 15.09.2011, 13:48
  2. FUP, KOP, in AWL
    Von redscorpion im Forum Simatic
    Antworten: 6
    Letzter Beitrag: 29.07.2011, 21:44
  3. Übersetzen von AWL in FUP oder KOP
    Von Trabbi im Forum Simatic
    Antworten: 6
    Letzter Beitrag: 18.12.2009, 18:46
  4. Antworten: 13
    Letzter Beitrag: 03.04.2009, 09:19
  5. Antworten: 17
    Letzter Beitrag: 18.06.2007, 22:10

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •