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 ?
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...
geadelt werde, dann muss ich wohl doch meinen Senf dazugeben, obwohl das Wichtige schon gesagt wurde.Dazu hat der TIA Anwender Nr 1, Helle Barde schon einiges getestet und geschrieben
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.Diese "optimierte Datenablage" ist auch so eine Schnapsidee, dem Verantwortlichen bei Siemens sollte man dafür die Ohren langziehen.
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)
"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.
Da gebe ich dir zu 100% Recht. Das sind so die Bezeichnungen die sich bestimmt ein Marketingspezialist ausgedacht hat.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.
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.Was bei Siemens jetzt "optimiert" ist, machen die meisten Compiler und auch Imho Codesys schon immer so.
Da hat mir Wireshark bei der 1200 was anderes verraten. Alle Ebenen werden sortiert.... In der obersten Ebene wird demnach nach Größen sortiert, in Strukturen aber nicht. ...
ja, aber mit anderen Regeln als bei 300/400.... wäre auch in allen Bausteinen weiterhin eine AT-Sicht möglich gewesen. ...
sag ich dochDann 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.
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.Was für eine Endianess gibt Siemens eigentlich für die 1500er an? Ich habe dazu noch nichts gefunden.
Genau daher rühren doch die Performanceunterschiede. Ein REAL aus dem optimierten holen geht vier mal schneller als aus dem kompatiblen.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.
Hi
optimiert im Blick auf die Zugriffsgeschwindigkeit, nicht auf den Platzbedarf.
Hatte da nicht vorhin einer gesagt Speicher sei billig, "Time is money"
Habt ihr das bemerkt ?
Endlich scheint es das die CPUs für ET200SP kommt.
http://support.automation.siemens.com/WW/view/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.
blöd nur, wenn Siemens am Speicher auch spart.
Hi
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
Wann wird das eigentlich mal wieder ein Ende haben und wann werden die wirklichen Ingenieure diese BWL-er zum Teufel jagen? Deutschland hat eigentlich seine Stärke verschenkt, mit Bachelor und Master hat man sich dem niedrigeren umliegenden Gegebenheiten angepasst, statt die eigenen Errungenschaften hochzuhalten.
Aber das ist wahrscheinlich ziemlich "Old School" und in Zeiten ungehemmter Abzockerei, Profitgier und kurzsichtiger Renditemaximierung nicht mehr wirklich zeitgemäß. :neutral:
Ich hatte gehofft, mit Kaeser kommt ein "alter" Ingenieur an die richtige Position, aber so einen eingerosteten schwerfälligen alten Dampfer zu einem schnittigen Rennboot zu machen braucht wohl laaaaaaaange !!! Oder geht das überhaupt noch????
Also Joe Kaeser bringt schon neues Leben in manch eingerostete Siemens-Struktur.
Wenn man sich mit einigen aus dem Vertrieb unterhält, dann hört man tatsächlich für Siemens ungewohnte Worte wie Kundenausrichtung und Marktorientierung.
Bei Produktvorstellungen wird man jetzt zu Feedbacks und Bewertungen gebeten. Sowas ist mir zumindest neu
Es ist leicht gegen Siemens zu meckern, aber auf der anderen Seite:
Wer machts in Summe wirklich soviel besser?
Gruß
Dieter
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?