TIA Direkter Zugriff auf einzelne Komponenten von DT

[Wincctia]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

was mir auch schon aufgefallen ist und was meiner Meinung nach auch logisch ist, das mischen von Optmierten und nicht Optimierten Bausteinen Verbraucht sehr viel Zykluszeit besonders die Kombi FC Optimiert und DB nicht Optimiert scheint ein Zykluszeit killer zu sein hier habe ich auch schon Faktor 10 gesehen.


mfg Tia

 

[Bernard]

der Ersatz für Adresspointer jedweder Art heißt Variant und hat keinen Bezug auf irgendwelche Adressen.

Grüße Bernard

 

[LNy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es stellt sich mir die Frage ob Euer Ingenieur überhaupt ne Ahnung von dem hat was er da verlangt oder ob ihm vielleicht mal jemand erklären sollte das er keine Vorgaben macht wenn er die Auswirkungen nicht kennt.

Weil dieser Herr der Meinung ist er wäre Chef der Abteilung....

Und ja der Herr ist aus S5-Zeiten und wünscht sich nichts mehr als die alten STEP-7 Zeiten zurück. Alles was TIA betrifft und gerade der optimierte Bausteinzugriff ist seiner Ansicht nach Mist.

Moin!
Ich bin erstaunt wie lange sich dieses Thema hält.
Wenn es keine technische Notwendigkeit gibt würde ich die Konvertierung im Programm verwursten und gut ist.

Die Problemlösung (ohne Konvertierung) steht betriebswirtschaftlich in keinem Verhältnis zu den Kosten.
Die Entscheidungen sollten durch die Abteilung/Person mit der meisten Expertise getroffen werden.
Sprich es mit Deinem/eurem Vorgesetzten ab ob du wirklich die Stunden verjubeln sollst oder dein Vorschlag besser ist.

 

[Bernard]

Ablauf zwischen nicht optimierten/optimierten Bausteinen.
Daten aus einem nicht optimierten Speicherbereich werden über dem Lokaldatenstack des aufrufenden Bausteinen in den optimierten Speicherbereich gekoppelt. Das verbraucht natürlich Zeit und könnte auch zu einem Stacküberlauf führen( eher unwahrscheinlich).

Optimierte Zugriffe auf 1500 er sind Geschwindigkeitsoptimiert.

Optimierte Zugriffe auf 1200 er sind Speicheroptimiert

Grüße Bernard.

 

[escride1]

Hast Du das selber gemessen/verglichen oder ist das nur Wiedergabe der Marketing-Sprüche?

Außerdem: nur Variablenspeicher kann "optimiert" sein, nicht der Programmcode. Wenn das Programm kaum Daten verarbeitet sondern z.B. nur E/A, dann wird da auch kein nennenswerter Laufzeit-Unterschied zu messen sein.

Im Prinzip hat @JesperMP dies ja bereits beantwortet, obgleich ich nicht solche Leistungssteigerungen feststellen konnte sondern eher im Bereich 3-4 mal.
Die "Messung" wird immer durchgeführt durch aktuelle Zeit-vorherige Zeit, also Differenz.
Variablenspeicher und Programmcode sind natürlich zu unterscheiden. Nicht aber bei einem FB dessen IDB optimiert:nicht optimiert ist oder dem Zugriff des FCs auf optimierte oder nicht-optimierte Variablen. Dann wird in jedem Fall die Leistung im Falle einer 1500er verändert.

Was genau nun dort verarbeitet wird ist eher offen, bis auf den DT. Wofür man das so braucht erschließt sich mir auch nicht. Ich würde das DT-Format, wenn möglich, sogar ganz ausradieren. Ansonsten wie @LNy einfach konvertieren, dann weiß man wenigstens sofort was geschieht und muss nicht erst noch rumsuchen wozu das so gemacht wurde.

@Chris1803
Wenn Euer Herr "Chef" soviel Wert auf Speicher und Geschwindigkeit legt, werden dann auch für diesen Zyklus überflüssige Netzwerke übersprungen?

 

[Bernard]

Zuviel Werbung?
-> Hier kostenlos registrieren

Variablenspeicher und Programmcode sind natürlich zu unterscheiden. Nicht aber bei einem FB dessen IDB optimiert: nicht optimiert ist oder dem Zugriff des FCs auf optimierte oder nicht-optimierte Variablen

Auch jeder FC hat temporäre Daten, also eigenen Speicher, deshalb kann man auch hier optimiert bzw. nicht optimiert arbeiten.

Viele Grüße Bernard

 

[JesperMP]

Im Prinzip hat @JesperMP dies ja bereits beantwortet, obgleich ich nicht solche Leistungssteigerungen feststellen konnte sondern eher im Bereich 3-4 mal.

Ich habe meine alten Noten durchgeschaut und kann erwähnen:
Auf ein 1515SP (Open Controller):
Für BOOLsche Anweisungen, optimiert ist ungf. 10 Mal schneller.
Für nicht-BOOLsche Anweisungen optimiert is dieselbe geschwindigkeit oder bis zu 2 Mal schneller.
Auf ein 1512SP:
Für alle Anweisungen, optimiert ist ungf. 1.2 Mal schneller.

 

[PN/DP]

Wenn es keine technische Notwendigkeit gibt würde ich die Konvertierung im Programm verwursten und gut ist.

Ich würde mal behaupten, die TIA-Konvertier-Anweisung (DT zu DTL) ist viel langsamer als die simple "nicht optimierte" selbstgeschriebene Function.

Die Problemlösung (ohne Konvertierung) steht betriebswirtschaftlich in keinem Verhältnis zu den Kosten.

Wenn man als erfahrener SCL-Programmierer die Einzeiler-Function "aus dem Handgelenk" hintippt, dann kostet das auch nicht mehr als eine TIA-Konvertier-Anweisung zu suchen und einzubinden und zu testen.

Harald

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ablauf zwischen nicht optimierten/optimierten Bausteinen.
Daten aus einem nicht optimierten Speicherbereich werden über dem Lokaldatenstack des aufrufenden Bausteinen in den optimierten Speicherbereich gekoppelt. Das verbraucht natürlich Zeit und könnte auch zu einem Stacküberlauf führen( eher unwahrscheinlich).

Optimierte Zugriffe auf 1500 er sind Geschwindigkeitsoptimiert.

Optimierte Zugriffe auf 1200 er sind Speicheroptimiert

Ich würde am liebsten die Bezeichnung "optimiert" vermeiden, denn da wird im Grunde nichts optimiert. "Nicht optimiert" besitzt eine andere Endianess, d.h. da müssen beim Wechsel zwischen "Optimiert" und "Nicht optimiert" die Bytes getauscht werden, und wenn der verwendete Prozessor eben die Endianess bei "optimiert" besitzt, dann ist das eben schneller wenn alles schon passend vorliegt. Allerdings ist das auch nur bei Mehrbyte-Datentypen notwendig. Wie hier bei einer Struct mit nur Bytes, gibt es überhaupt keinen Unterschied: Es gibt keine Endianess bei einem Byte-Typen, 1 Byte ist bei beiden Varianten genau 1 Byte, und die Bytes liegen bei beiden Varianten in gleicher Reihenfolge im Speicher.

Also wenn man wollte, dann könnte man das auch egal ob ich das optimiert/nicht optimiert verwende zu gleich schnellem Code compilieren.

 

[Bernard]

Hier die Beschreibung des optimierten Zugriffs von Siemens.

SIOS

support.industry.siemens.com

Viele Grüße Benard

 

[Bernard]

Wenn es keine technische Notwendigkeit gibt würde ich die Konvertierung im Programm verwursten und gut ist

Super, und da das Programm schon mal aus der S5 Welt nach S7 konvertiert wurde gibt es endlich wieder Schmiermerker
und natürlich alles in AWL. Zurück zu den Wurzel alles Andere ist nur neumodischer Unsinn. Ach ich hatte ja die schönen S5-Timer und Zähler vergessen, was war 1979 doch für eine schöne Zeit.

Grüße Bernard

 

[LNy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich würde mal behaupten, die TIA-Konvertier-Anweisung (DT zu DTL) ist viel langsamer als die simple "nicht optimierte" selbstgeschriebene Function.

Wenn man als erfahrener SCL-Programmierer die Einzeiler-Function "aus dem Handgelenk" hintippt, dann kostet das auch nicht mehr als eine TIA-Konvertier-Anweisung zu suchen und einzubinden und zu testen.

Einfach mal beide Lösungen in eine 1513 gehackt und verglichen:
10000 Aufrufe von DT_TO_DTL() benötigen ca. 46 ms, die Wandlung mittels nicht optimierten FB benötigt ca. 32 ms für die 10000 Aufrufe.

Daher widerspreche ich der Aussage das die TIA Konvertierung viel langsamer ist. Zumal ein Aufruf pro Zyklus reicht und man dann nur 1,4 µs durch einen selbstgeschriebenen FB spart (bei einer 1513).

Konvertierungen tippe ich in SCL generell einfach runter, TIA hilft einem dann mit Vorschlägen.

Super, und da das Programm schon mal aus der S5 Welt nach S7 konvertiert wurde gibt es endlich wieder Schmiermerker
und natürlich alles in AWL. Zurück zu den Wurzel alles Andere ist nur neumodischer Unsinn. Ach ich hatte ja die schönen S5-Timer und Zähler vergessen, was war 1979 doch für eine schöne Zeit.

Ich bezog mich damit auf die TIA Typen-konvertierung, nicht auf den alten Sch***. Persönlich bevorzuge ich neue Mittel und Funktionen die mir das Leben vereinfachen, denn mit migrierten S7 Projekten (teilweise tatsächlich S5) werde ich oft genug gequält...

 

[PN/DP]

Einfach mal beide Lösungen in eine 1513 gehackt und verglichen:
10000 Aufrufe von DT_TO_DTL() benötigen ca. 46 ms, die Wandlung mittels nicht optimierten FB benötigt ca. 32 ms für die 10000 Aufrufe.

Daher widerspreche ich der Aussage das die TIA Konvertierung viel langsamer ist.

Danke für das Messen und Vergleichen der Laufzeit. Hattest Du da auch das Umspeichern des Wochentags nach der Konvertierung mit drin? Warum hast Du für die selbstgeschriebene Function einen FB verwendet anstatt FC?

Na gut, dann ist der Code mit kompletter Konvertierung nicht so "viel langsamer" sondern nur 43% langsamer als selbstgeschriebener optimaler Code.

Irgendwie habe ich das Gefühl, daß die TIA-Compiler für Standard-Zugriff-Code (absichtlich?) unnötig schlechten Code erzeugen, und wenn es auch nur das weglassen aller Code-Optimierungen ist, die bei Code für "optimierten" Speicher noch zusätzlich reingebastelt sind. Wenn Siemens wollte, dann könnte da bestimmt auch schnellerer Code rauskommen (wie Thomas_v2.1 schon schrieb). Es gibt oft keinen formalen Grund, daß die Compiler für optimiert/nicht optimiert unterschiedlich schnellen Code erzeugen.

Harald

 

[DeltaMikeAir]

Daher widerspreche ich der Aussage das die TIA Konvertierung viel langsamer ist.

Nicht viel, nur etwas über 40%

 

[LNy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke für das Messen und Vergleichen der Laufzeit. Hattest Du da auch das Umspeichern des Wochentags nach der Konvertierung mit drin? Warum hast Du für die selbstgeschriebene Function einen FB verwendet anstatt FC?

1. Weil ich nicht genau gelesen habe
2. Der Aufruf verbraucht die meiste Zeit

Ein FC oder FB Aufruf machen hier bei dem kleinen Testprogramm kaum einen Zeitlichen Unterschied (ca 1- 2 ms für 10000 Aufrufe).
Wenn es wirklich Zyklusoptimiert sein muss sollte man das nicht in einer Funktion auslagern sondern ausschreiben (ca 2 - 3 ms für 10000 Aufrufe).

Es bleibt natürlich die Frage, die jeder für sich beantworten sollte, ob es sich lohnt für ein paar µSekunden und ein paar Byte Speicher so "viel" Aufwand zu betreiben oder ob man einfach mal eine größere SPS einbaut.

 

[PN/DP]

2. Der Aufruf verbraucht die meiste Zeit
(...)
Wenn es wirklich Zyklusoptimiert sein muss sollte man das nicht in einer Funktion auslagern sondern ausschreiben (ca 2 - 3 ms für 10000 Aufrufe).

Speziell hier bei dieser Function wäre da aber trotzdem noch das Problem, daß der Date_and_Time in einen Speicherbereich kopiert werden muß, auf dem man AT anwenden kann darf. Ist der zusätzliche FC-Aufruf tatsächlich so zeitaufwendig gegenüber dem Kopieren der Variable von "optimiert" zu "nicht optimiert" in den FC-Input oder in anderen Speicher?

Harald

 

[LNy]

Weil es mich auch interessiert:
10k For-Schleife ohne Anweisung (nur das nötige Semikolon) = 6 ms
10k For-Schleife mit leerem FC = 14 ms
10k For-Schleife mit FC 1 bis 6 DINT Input und Output, kein Code = 21 ms
10k For-Schleife mit FC 6 DINT Input und Output, Mit 4 Zeile Code und einem leeren FB= 39 ms

Also sollte man Bausteinaufrufe / Verschachtelungen nicht zu sehr ausreizen...