Die können sich nicht allzuviel gedacht haben oder, sonst hätten sie nicht so einen Scheiß verbrochen!
*ACK*
Was ich am wenigsten leiden kann ist der Begriff "optimiert".
Das ist einfach "1500-Standard" und "300/400-schlecht-kompatibel".
PS1: Ich kann den Ratschlag nicht nachvollziehen, ich verwende das gemischt, ansonsten müßte ich ja tatsächlich so programmieren, wie die sich das gedacht haben und ganz so hirnlos will ich dann doch nicht meine SPS-Programme proggen.
Nun gut, da muss ich meine Aussage von oben ein wenig relativieren.
Ich versuche so weit wie es geht "optimierte" DBs einzusetzen und "optimierte" und "nicht optimierte" Bereiche einigermaßen zu trennen.
Dort wo ich mit "optimiert" dreimal mit der Kirche ums Kreuz programmieren muss um auf das selbe Ergebnis zu kommen, bzw. wo es nicht anders geht, dort verwende ich "nicht optimiert".
Ich böser Junge verwende auch noch AWL, wenn möglich allerdings ohne AR-Gebastel und Co.
Nur als andere Darstellungsform in Kombination mit FUP. Vielleicht kommt mal der Tag an dem ich ein SCL-Netzwerk unter ein FUP-Netzwerk setzen darf.
Über den generellen Sinn und Unsinn von "optimierten" (man bemerke die Anführungszeichen) wurde hier eh schon des häufigeren diskutiert.
Die Themen kennst du ja eh, für diejenigen die es interessiert...
http://www.sps-forum.de/simatic/726...unsinn-4.html?highlight=optimiert+performance
http://www.sps-forum.de/simatic/802...-auf-s7-300-a.html?highlight=optimiert+endian
Grundsätzlich schrecken mich aber Dinge wie...
- ständiges Byte-Grehe bei jedem Zugriff in Abhängigkeit der "Optimierung"
- Abhängkeit von der "Optimierung" des Aktualparameters ob ein FB diesen als ByVal oder ByRef bekommt.
- Bausteine die einmal einen "optimierten DB" vorschreiben
- Bausteine die einen nicht "optimierten DB" benötigen
- generell dieses ganze "mal so, mal so"
Wenn es irgendwie geht versuche ich mir nicht noch mehr Probleme mit TIA ins Haus zu holen als ich mit TIA so schon habe.
Deshalb versuche ich (soweit sinnvoll) so zu arbeiten wie BigS es sich vorstellt. Wenn auch teilweise mit Gehirnschmerzen... :sb10:
Gibt auch wesentlich weniger HickHack mit dem Support, wenn mal wieder was nicht hinhaut.
PS2: Was heißt da eingentlich Performance?
Dass das ganze Byte-Gedrehe und Bit-Ausmaskieren die CPU künstlich ausbremsen muss ist auch klar.
Die Beiträge von Hellebarde kennen wir.
Das ganz AWL-AR-Zeug ist auch ziemlich arg, das ist mir selber schon aufgefallen.
Hatte ne kleine Anlage für die hatte ich einfach unsere 300er-Standardbausteine migriert und allen in "nicht optimiert" programmiert.
Funktioniert hat's problemlos. Es war auch nur ne 1510-ET200SP, jedoch hatte auf der CPU das Programm (gefühlt) eigentlich 2x Mal laufen müssen bevor man die 10ms-Grenze durchbricht. Leider waren es bei 1x schon 16ms. Da war ich eigentlich ziemlich erschrocken.
In meinen Fall war die AR-Operationen beim Any-Pointer kopieren die größten Übeltäter.
Beim aktuellen Projekt, wo ich auf das "optimierte" geachtet hab, mit der 1512 (ca. 1,5 x 1510) hab ich schon gefühlt 2x soviel Code drauf und bin noch bei 4ms. Ist aber alles sehr sehr subjektiv, also bitte nicht drauf rumreiten...
Die Messungen und das Wissenschaftliche überlasse ich Hellebarde
.
Bin aber trotzdem der Meinung das ich die CPU, dort wo ich keinen Aufwand habe es "optimiert" zu machen, diese nicht künstlich bremsen muss.
Was wirklich schlimm ist, ist das ich mir überhaupt darüber Gedanken mache oder machen muss...
PS: Da der TE vom Umsteigen auf die 1500 spricht sollte man ihn noch auf ein paar weitere Unterschiede hinweisen.
http://www.sps-forum.de/simatic/79662-umstieg-auf-s7-1500-a-post601632.html#post601632