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

Seite 3 von 4 ErsteErste 1234 LetzteLetzte
Ergebnis 21 bis 30 von 35

Thema: 1500 - optimierter Bausteinzugriff - Sinn/Unsinn ?

  1. #21
    Registriert seit
    31.10.2013
    Beiträge
    36
    Danke
    3
    Erhielt 6 Danke für 6 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Draco Malfoy Beitrag anzeigen
    D.h. also wenn ein Teil des Programms so oder so auf klassische Zugriffe nicht verzichten kann, dann würdest Du empfehlen das gesamte Programm auf "nicht optimiert" umzustellen ?
    Wie ist es denn, wenn ich beispielsweise einen zeitkritischen Teil des Programms in OB30 ablege, und dort nur optimierte Zugriffe einbaue und der Rest in OB1 sitzt und dort auch FBs mit nicht optimierten Zugriffen vorkommen ?
    Bringt das was oder sollte man dann trotzdem überall "nicht optimiert" bleiben ?
    Wie oben schon geschrieben wurde, wird zusätzliche Zykluszeit produziert, wenn Daten von optimierten zu nicht optimierten Bausteinen kopiert werden müssen.
    Wenn du getrennte Programmteile hast und einen Programmteil optimiert und den anderen nicht optimiert programmierst, dann hast du in einem Programmteil schnelle und in dem anderen nicht ganz so schnelle Zugriffe. Insgesamt dürfte es schneller sein, als ein reines absolutes Programm.
    Habe ich aber nicht getestet, nur aus den Unterlagen interpretiert.

  2. #22
    Registriert seit
    22.09.2011
    Beiträge
    85
    Danke
    45
    Erhielt 20 Danke für 14 Beiträge

    Standard

    Zitat Zitat von Draco Malfoy Beitrag anzeigen
    Das tut es ja bei mir auch, die Variablen sind allesamt symbolisiert.
    Aber wenn ich eine Variable eingeben muss, dann mache ich das nach alter Gewohnheit absolut. Wenn da am Ende also steht "Verfahrdaten".HubwegeRDB.Obertisch dann könnte ich möglicherweise übersehen, daß es sich bei den Hubwegen um RDB und nicht um FDB handelt. Während DB18.DBD20 und DB18.DBD40 sich dann schon erheblich unterscheiden und auffallen...
    Wie so oft in der Programmierwelt ist auch das Ansichtssache.
    Ich bin "absolut" für die symbolische Adressierung. Allerdings sollte dies auch für einen "nicht Ortskundigen" Programmierer/Techniker schlüssig sein. Wenn ein symbolischer Name aus Kürzeln besteht, dann wird es sehr schwer bis unmöglich sich die Bedeutung zusammen zu reimen um dann eine Aussage zutreffen ob den diese Variable an der richtigen Stelle steht oder doch vertauscht ist.
    Wenn es Auffallen soll dann vielleicht so:
    für "Verfahrdaten".HubwegeRDB.Obertisch und "Verfahrdaten".HubwegeFDB.Obertisch könnte man gleich so schreiben:
    "VerfahrdatenDB18".HubwegeDBD20RDB.Obertisch für DB18.DBD20 und "VerfahrdatenDB18".HubwegeDBD40FDB.Obertisch für DB18.DBD40

    Kein Scherz - habe ich in ähnlicher Form schon gesehen. Kann man sich das Symbolische gleich sparen.

    Viele Grüße
    VLT_RealDrive

  3. #23
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard

    Hallo miteinander

    wenn ich hier //www.sps-forum.de/simatic/72602-1500-optimierter-bausteinzugriff-sinn-unsinn.html#post504460 schon
    Dazu hat der TIA Anwender Nr 1, Helle Barde schon einiges getestet und geschrieben
    geadelt werde, dann muss ich wohl doch meinen Senf dazugeben, obwohl das Wichtige schon gesagt wurde.

    Auf 1500 ist optimiert eindeutig schneller und mischen ist schlecht. Je teurer die CPU ist, desto größer ist der Effekt.

    Man hat es zwar nicht bestätigt, aber in der 1518 vermute ich einen relativ modernen Prozessor von Intel und in den kleineren einen vom MIPS. Wenn man also einen Prozessor aus der Haswell Reihe annimmt, dann hat S mit folgenden "Problemen" zu kämpfen: 3 Cache Ebenenen, 64Byte Cachelines, Lüfterlos --> 17W TDP. (Hat mir alles mein Sohn der Herr Informatikstudent verraten). Warum macht das Probleme, wenn sich doch die PC darüber freuen. Weil "wir rückständig denkenden SPSler" (Zitat Sohn) dem Compiler in die Adressierung pfuschen wollen, denn wir glauben wir wüssten es besser. Und gleich noch ein Zitat: "Kein C-Compiler lässt so einen Blödsinn zu".
    Ich habe ihm dann mittels #pragma pack(1) bewiesen dass ein C-Compiler das doch zu lässt. Und er hat mir dann bewiesen, dass deswegen genau dieses Programm um den Faktor 53 langsamer läuft. Autsch! Blöd wenn der Lauser recht hat, da geht die ganze Autorität flöten.

    Woran liegt es? Die Intels lesen am liebsten 64 Byte am Stück. Und am schnellsten kann er Lesen, wenn die Daten im Level 1 Cache, d.h. nahe am EAX (wir würden da Akku zu sagen) liegen. Je weiter weg vom EAX die Daten liegen desto länger dauert es. Über die Probleme von Mehrkernsystemen wird sich S wohl gerade Gedanken machen, wir bekommen das erst mit der 1519 Also der Level1 Zugriff dauert nur wenige Nanosekunden, der Level3 schon 100 Nanosekunden und auf das RAM raus kommen wir für ein einzelnes Byte knapp an die µs. Deswegen will Intel auch nicht ein einzelnes lesen, sondern immer einen Burst von 64 Bytes, dann werden nicht so oft Adressen über die Busse gejagt und damit kann man dann 64 Byte schneller lesen als einzelne Bytes. Jetzt teilen sich wie immer Code und Daten das RAM, und der Code wird eher linear durchlaufen, da hilft das mit den 64Byte Cachelines, während die Daten wirklich RANDOM zugegriffen werden, da hilft es nix.

    Wen man wissen will, was der Intel im PC so an Speicher hat, dann kann man COREINFO.EXE von SYSINTERNALS in der Eingabeaufforderung aufrufen. Mein PC auf dem ich das jetzt tippe hat 4 Kerne, jeder Kern hat 32KB für Code + 32KB für Daten Level 1 Cache, jeder Kern hat 256KB Level 2 Cache und alle Kerne zusammen haben einen Level3 Cache von 8MB.

    Jetzt kommen wir daher und greifen auf DB18.DBD62 zu. Wenn Siemens irgendwas vom getrennt laden der Baustein hat, dann liegt der Anfang eines DB auf einer durch 64Byte teilbaren Adresse. Der Zugriff auf DBD62 greift jetzt genau über die Grenze --> zwei Cachelines lesen. Ok greifen wir auf DB18.DBD6 zu. Es ist ein 64bit Prozessor. Der kann 8, 16, 32, 64 Bit aus dem Level1 holen, wenn diese am Stück liegen und zwar so, dass die Adresse durch die Zugriffsbreite teilbar ist. 6/4 ist 2 rest 2. Das geht nicht. Also zwei mal 16 Bit holen und zusammen schieben. Dauert drei mal so lange wie der richtig ausgerichtete Zugriff. Und dann ist Intel ja auch immer littleendian. standard ist aber bigendian. D.h. die Bytes liegen auch noch verkehrt im Speicher. Entweder hängt man nun einen BSWAP hinterher oder man holt die BYte einzeln und schiebt sie ander herum zusammen. Dann kannste auch gleich auf DBD5 zugreifen, ist dann auch schon egal.


    Ich möchte daher Thomas_v21 widersprechen
    Diese "optimierte Datenablage" ist auch so eine Schnapsidee, dem Verantwortlichen bei Siemens sollte man dafür die Ohren langziehen.
    Das ist sie nicht, das sieht alles so aus, also ob es auf die Haswells und was da auch immer nachkommt ausgelegt ist. So richtig wichtig ist es aber nur wenn ich die 1518 auch wirklich brauche, weil ich Zykluszeiten oder Interruptzeiten deutlich unter 1µs brauche. Wenn mir 100ms oder mehr reichen, dann ist optimiert nicht wichtig. Im Gegenteil für Kommunikationspuffer zusammenschrauben ist es störend.

    Was lernen wir: Wiedermal eine grüne Banane gekauft.

    "Optimiert" ist etwas, was die wenigsten von uns brauchen und die, die es brauchen, können es nicht so richtig verwenden, weil noch wichtiges fehlt. Z.B. Funktionen zum Erstellen von Kommunikationspuffern.

    'n schön' Tach auch
    HB

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

    EinsNull (06.01.2015),gravieren (04.09.2014),Günni1977 (08.09.2014),kapo666 (07.09.2014),mnuesser (05.10.2017),netmaster (04.09.2014),Pipboy (04.09.2014),Rainer Hönle (04.09.2014),Ralle (04.09.2014),RGerlach (04.09.2014),rostiger Nagel (04.09.2014),Schnitzel (06.09.2014),SPS-freak1 (03.09.2014),steuerung (04.09.2014),SvenSa (18.01.2016),VLT_RealDrive (03.09.2014),vollmi (04.09.2014)

  5. #24
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.620
    Danke
    777
    Erhielt 647 Danke für 493 Beiträge

    Standard

    Bei den Geschwindigkeiten habe ich aber trotzdem so meine fragen.
    Code:
    CPU 1511-1 PN 60ns Bitperformance 
    CPU 1513-1 PN 40ns Bitperformance (1.5 facher speed)
    CPU 1515-2 PN/DP 30ns Bitperformance (1.3 facher speed)
    CPU 1516-3 PN/DP 10ns Bitperformance (3 facher speed)
    CPU 1517-3 PN/DP 2ns Bitperformance (5 facher speed)
    CPU 1518-4 PN/DP 1ns Bitperformance (2 facher speed)
    Diese runden Geschwindigkeiten und Unterschiede zur nächst höheren Stufe deuten für mich eher auf einen per Software limitierten Speed hin.
    Denkst du nicht das ist Kalkül dass man immer noch etwas platz hätte ohne die Architektur zu ändern der Konkurenz jederzeit per Firmwareupdate wieder einen Schritt voraus zu sein.

    Ich meine die 1518-4 PN/DP übertrumpft ja selbst die schnellste 400er. Und das für weniger Geld dafür mehr PN Schnittstellen.

    mfG René

  6. #25
    Registriert seit
    29.03.2004
    Beiträge
    5.735
    Danke
    143
    Erhielt 1.686 Danke für 1.225 Beiträge

    Standard

    Zitat Zitat von HelleBarde Beitrag anzeigen
    "Optimiert" ist etwas, was die wenigsten von uns brauchen und die, die es brauchen, können es nicht so richtig verwenden, weil noch wichtiges fehlt. Z.B. Funktionen zum Erstellen von Kommunikationspuffern.
    Ich störe mich an der Bezeichnung "optimiert".
    Für mich ist "optimiert" bei einer 1200/1500 Standard, und "nicht optimiert" ist ganz einfach "S7-300/400" kompatibel.

    Was bei Siemens jetzt "optimiert" ist, machen die meisten Compiler und auch Imho Codesys schon immer so.

    Und bei dieser "optimierten" Datenablage gibt es auch noch Unterschiede zwischen der Ablage in Bausteinen (also im Wurzelknoten VAR/END_VAR) und der in Strukturen - wenn man diesem Siemens-Dokument glauben darf. In der obersten Ebene wird demnach nach Größen sortiert, in Strukturen aber nicht. Wenn man dieses zweifelhafte sortieren nach Datentypen um ein paar Bytes zu sparen (Speicher ist heute ja so teuer) nicht hätte, wäre auch in allen Bausteinen weiterhin eine AT-Sicht möglich gewesen. Ein konvertieren von Bausteinen die davon Gebrauch machen, von einer 300/400 auf eine 1500er wäre zwar nicht automatisch möglich, aber zumindest mit etwas Handarbeit behebbar.
    Dann bliebe als einziger Grund für die "nicht optimierte" Option, Kommunikation zu anderen S7-300/400 oder mit alten HMI-Systemen die das neue Protokoll nicht beherrschen zu treiben.

    Was für eine Endianess gibt Siemens eigentlich für die 1500er an? Ich habe dazu noch nichts gefunden. Falls dort wirklich ein x86-Prozessor zum Einsatz kommt, unterscheidet sich diese ja nochmal von der S7-300/400.
    Ich kann mir kaum vorstellen dass bei jedem Zugriff die Bytes gedreht werden, wenn in der Programmierumgebung weiterhin Big-Endian wie bei den alten S7 herrscht. Bei der 300 Serie gab es ja auch schon Interpretermaschinen mit Tricore, Mips, oder die alten mit C165-Prozessor die mit MC7-Code außer der Endianess erstmal nichts gemein hatten.

  7. #26
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard

    Hi Thomas

    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    Ich störe mich an der Bezeichnung "optimiert".
    Für mich ist "optimiert" bei einer 1200/1500 Standard, und "nicht optimiert" ist ganz einfach "S7-300/400" kompatibel.
    Da gebe ich dir zu 100% Recht. Das sind so die Bezeichnungen die sich bestimmt ein Marketingspezialist ausgedacht hat.

    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    Was bei Siemens jetzt "optimiert" ist, machen die meisten Compiler und auch Imho Codesys schon immer so.
    Stimmt. Die können ja auch für jedes Zielsystem einen inkompatiblen Code auswerfen. S verwendet für alle CPUs einer Familie den gleichen Zwischensprachencode.
    Haben wir ja bei der 1200 selbst untersucht

    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    ... In der obersten Ebene wird demnach nach Größen sortiert, in Strukturen aber nicht. ...
    Da hat mir Wireshark bei der 1200 was anderes verraten. Alle Ebenen werden sortiert.

    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    ... wäre auch in allen Bausteinen weiterhin eine AT-Sicht möglich gewesen. ...
    ja, aber mit anderen Regeln als bei 300/400.

    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    Dann bliebe als einziger Grund für die "nicht optimierte" Option, Kommunikation zu anderen S7-300/400 oder mit alten HMI-Systemen die das neue Protokoll nicht beherrschen zu treiben.
    sag ich doch

    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    Was für eine Endianess gibt Siemens eigentlich für die 1500er an? Ich habe dazu noch nichts gefunden.
    Mit dem Wireshark den DB auf's Byte schaut zeigt, dass die Startwerte bei der 1500 für die optimierten Bereiche little und die für die 300/400 kompatiblen big sind. Bei der 1200 ist alles big.

    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    Ich kann mir kaum vorstellen dass bei jedem Zugriff die Bytes gedreht werden, wenn in der Programmierumgebung weiterhin Big-Endian wie bei den alten S7 herrscht.
    Genau daher rühren doch die Performanceunterschiede. Ein REAL aus dem optimierten holen geht vier mal schneller als aus dem kompatiblen.

    Und zu Vollmi. Na aber sicher doch. Da sind sicherlich Softwarebremsen drin. Zwischen den CPUs einer Familie muss das Marketing doch wieder irgendeinen Unterschied generieren um uns mehr Geld aus der Tasche zu ziehen. Die Fertigung auf der anderen Seite will mit weniger Unterschieden arbeiten. Mache ich mit meinen Werkzeugmaschinen doch auch. Alle Modelle basieren auf der fast gleichen Hardware. Nur das Spitzenmodell hat wirklich bessere Motoren. Die vier langsameren werden über die Software gedrosselt.
    Bei INTEL läuft das genauso. Die stellen nur wenige Modelle her, messen dann deren Verlustleistung, schießen mit dem Laser Sicherungen raus um bestimmte Bereiche lahm zu legen. Und dann verkaufen die guten als K Modelle und die schlechten als niedrig taktende Dualcore.

    'n schön' Tach auch
    HB

    Ich hoffe ich habe jetzt niemanden desillusioniert

  8. #27
    Registriert seit
    29.03.2004
    Beiträge
    5.735
    Danke
    143
    Erhielt 1.686 Danke für 1.225 Beiträge

    Standard

    Es könnte ja mal jemand bei Siemens nachfragen, wieso ein "optimierter" Datenbaustein acht mal so viel Speicher benötigt wie ein "nicht optimierter".
    Hat man z.B. einen DB mit nur BOOLs hintereinander, ist das der Fall. Das ist das Problem wenn man solche Marketing-Bezeichnungen verwendet.

  9. #28
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard

    Hi

    optimiert im Blick auf die Zugriffsgeschwindigkeit, nicht auf den Platzbedarf.
    Hatte da nicht vorhin einer gesagt Speicher sei billig, "Time is money"

    'n schön' Tach auch
    HB

  10. #29
    Registriert seit
    13.10.2007
    Beiträge
    12.033
    Danke
    2.788
    Erhielt 3.269 Danke für 2.157 Beiträge

    Standard

    Zitat Zitat von HelleBarde Beitrag anzeigen
    Hi

    optimiert im Blick auf die Zugriffsgeschwindigkeit, nicht auf den Platzbedarf.
    Hatte da nicht vorhin einer gesagt Speicher sei billig, "Time is money"
    blöd nur, wenn Siemens am Speicher auch spart.

    Zitat Zitat von JesperMP Beitrag anzeigen
    Habt ihr das bemerkt ?
    Endlich scheint es das die CPUs für ET200SP kommt.
    http://support.automation.siemens.co...ew/de/98783871

    Was mich enttäuscht ist dass der 'grosse' CPU hat nur 200KB code-Speicher.
    Ist das wirklich genug ?
    Zum vergleich bin ich schon bei IM151-8 bei 75% von den vorhandene Speicher. (140kB von 192kB).
    Hat jemand Erfahrung mit wieviel code-Speicher für eine gewisse Code in die neue TIA CPUs verbraucht wird, in verhältniss zu die 'classic' S7 CPUs ?
    Eigentlich verstehe ich nicht warum die neue TIA CPUs so wenig Speicher haben.
    - - -
    Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.

  11. #30
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hi

    Zitat Zitat von rostiger Nagel Beitrag anzeigen
    blöd nur, wenn Siemens am Speicher auch spart.
    das ist das Geschäftsmodell.
    Und zwar nicht nur von S, (fast) alle anderen machen das auch so.

    Zu zahlst für
    den Platz
    die Geschwindigkeit
    den Komfort

    'n schön' Tach auch
    HB

Ähnliche Themen

  1. Sinn einer Verzweigung in FUP
    Von clumsi im Forum Simatic
    Antworten: 16
    Letzter Beitrag: 05.04.2013, 15:46
  2. Sinn von indirekter Bearbeitung (BI)?
    Von msg im Forum Simatic
    Antworten: 19
    Letzter Beitrag: 28.06.2011, 22:23
  3. Sinn dieser Schaltung
    Von Abdul im Forum Elektronik
    Antworten: 3
    Letzter Beitrag: 03.09.2009, 17:57
  4. HMI Bereich aufteilen? Sinn oder unsinn?
    Von Bender25 im Forum Stammtisch
    Antworten: 1
    Letzter Beitrag: 09.06.2008, 14:53

Lesezeichen

Berechtigungen

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