escride1
Level-3
- Beiträge
- 1.262
- Reaktionspunkte
- 327
-> Hier kostenlos registrieren
Eigentlich ging es mir nur um die Schleifenabarbeitung, könnte ich aber gleich schnell umstellen und laden.
TIA SCL-Schleife erhöht kurzfristig die Zykluszeit
- Ersteller MFreiberger
- Erstellt am
-> Hier kostenlos registrieren
Howard
Level-1
- Beiträge
- 1.026
- Reaktionspunkte
- 331
Von welcher Zykluszeit spricht der Mario denn genau? Ermittelt mit RT_Info? - denn dort wird ja noch zwischen Zykluszeit (Anwenderprogramm) = Mode 25 und Zykluszeit Organisationsbaustein = Mode 1 unterschieden. Ich vermute nämlich auch eher, dass das laden und anschließende "online gehen + beobachten" den Zyklus in die höhe treibt. Deshalb würde mich auch die Antwort zu Ralfs Post #11 interessieren.
- Beiträge
- 12.376
- Reaktionspunkte
- 4.569
-> Hier kostenlos registrieren
Interessant wäre auch der Vergleich optimierte oder nicht optimierte Bausteine
- Beiträge
- 11.190
- Reaktionspunkte
- 3.819
Was passiert den bei RUN-STOP der CPU? Besteht dann auch das Problem? bzw. nach 24V Ab-Zu-Schaltung?
Gruß.
Gruß.
TWO_BITS_OR_NOT_TWO_BITS
Level-1
- Beiträge
- 44
- Reaktionspunkte
- 7
Verhält sich ein und die selbe Struktur denn immer gleich? Also wenn ich direkt auf den DB zugreife oder diese als INOUT an einen FC / FB parametriere?
- Beiträge
- 5.698
- Reaktionspunkte
- 1.628
-> Hier kostenlos registrieren
Runtime wäre mal interessant mal um das FOR zu packen und das Ergebnis OB1 erster bis nter Zyklus in einem Array abzulegen. Ich arbeite mit so vielen FOR Schleifen mit richtig viel Datenschubsen, das wär mir bestimmt irgendwann aufgefallen, vor allem bei 100% Zykluserhöhung wäre ich schon längts irgendwo in der überwachungszeit gelandet.
- Beiträge
- 8.945
- Reaktionspunkte
- 2.168
- Beiträge
- 24.323
- Reaktionspunkte
- 7.727
Meine Überzeugung: Bei "optimierten" DB macht es einen (skalierbaren) Unterschied, ob nach dem indizierten Element noch eine oder mehrere Strukturebenen kommen. Bei DB mit Standard-Zugriff kann der Compiler den Offset der Variable zur indizierten Adresse als feste Konstante berechnen, egal ob noch eine oder 5 Strukturebenen folgen. Bei "optimierten" DB kann der Compiler das nicht, es sei denn er ordnet/sortiert die nachfolgenden Strukturebenen in einer berechenbaren Reihenfolge im Speicher an oder erstellt eine Index-Tabelle für alle betroffenen Variablen. Vermutlich tut er das erst dann, wenn er feststellt, daß da ein indizierter Zugriff erfolgt, was erklären würde warum die Zykluszeiterhöhung nur temporär ist (sich wieder erholt).
Das ist halt der Nachteil des Konzepts der verstreuten (als "optimiert" bezeichneten) Datenablage.
Ich würde mal den Programmteil mit der Schleife laden aber noch nicht ausführen, wie schon von Ralle in #11 angeregt.
Wenn man so tief verschachtelt strukturiert indirekt adressieren will, dann sollte man vielleicht besser "nicht optimierten" Speicher verwenden.
Harald
Das ist halt der Nachteil des Konzepts der verstreuten (als "optimiert" bezeichneten) Datenablage.
Ich würde mal den Programmteil mit der Schleife laden aber noch nicht ausführen, wie schon von Ralle in #11 angeregt.
Wenn man so tief verschachtelt strukturiert indirekt adressieren will, dann sollte man vielleicht besser "nicht optimierten" Speicher verwenden.
Harald
- Beiträge
- 8.945
- Reaktionspunkte
- 2.168
-> Hier kostenlos registrieren
Habe die Programmierleitfaden für S7-1200/1500 durchgeschaut.
https://www.automation.siemens.com/...w-config-s7-1200/programming-guideline-de.pdf
Auf Seite 62 steht als Eigenschaften für Arrays:
edit: Vielleicht meinen sie dass die Index in Quellcode dynamisch berechnet werden kann. Nicht dass die eigentliche Hardware Addresse womit die CPU den Array zugeht zur Laufzeit berechnet wird.
https://www.automation.siemens.com/...w-config-s7-1200/programming-guideline-de.pdf
Auf Seite 62 steht als Eigenschaften für Arrays:
Da steht aber nicht dass durch diese dynamische Berechnung einen Zykluszeiterhöhung erzuegt werden kann. Und da steht nichts ob es mit optimiert/nicht optimiert zu tun hat.
edit: Vielleicht meinen sie dass die Index in Quellcode dynamisch berechnet werden kann. Nicht dass die eigentliche Hardware Addresse womit die CPU den Array zugeht zur Laufzeit berechnet wird.
Zuletzt bearbeitet:
escride1
Level-3
- Beiträge
- 1.262
- Reaktionspunkte
- 327
So, Kaffee & Kuchen sind verputzt 
.
Im Anhang zwei Bilder:
Es sind jeweils 10 Messungen mit Pausierung um jede einzelne Schleife/Abarbeitung optisch erfassen zu können.
Im ersten 10er-Block die ursprüngliche Anweisung,
im zweiten 10er-Block die vom Siemens-Programmierguide empfohlene Umgehung der IF-THEN-Abfrage wie ich oben bereits einmal gepostet habe,
im dritten Block keine Schleife, direkt 1:1 mit 300 Zeilen ^^ (Danke für Verkettungsmöglichkeiten, Excel) laut ursprünglichem Post, also IF THEN.
Die Zykluszeit selbst spielt ja eigentlich keine Rolle, sondern nur die Anweisung. Wieviele Schleifen verwendet werden ist dementsprechend wichtig.
Ich habe wieder auf allen CPUs probiert, aber nur einmal die Traces zurechtgeschnitten. Verhalten sich alle ähnlich.
.Im Anhang zwei Bilder:
Es sind jeweils 10 Messungen mit Pausierung um jede einzelne Schleife/Abarbeitung optisch erfassen zu können.
Im ersten 10er-Block die ursprüngliche Anweisung,
im zweiten 10er-Block die vom Siemens-Programmierguide empfohlene Umgehung der IF-THEN-Abfrage wie ich oben bereits einmal gepostet habe,
im dritten Block keine Schleife, direkt 1:1 mit 300 Zeilen ^^ (Danke für Verkettungsmöglichkeiten, Excel
) laut ursprünglichem Post, also IF THEN.Die Zykluszeit selbst spielt ja eigentlich keine Rolle, sondern nur die Anweisung. Wieviele Schleifen verwendet werden ist dementsprechend wichtig.
Ich habe wieder auf allen CPUs probiert, aber nur einmal die Traces zurechtgeschnitten. Verhalten sich alle ähnlich.
- Beiträge
- 6.692
- Reaktionspunkte
- 1.687
Egal, was da zur Laufzeit genau zusätzlich ausgeführt wird, IndexTabelle anlegen oder sonstwas, verstehe ich nicht, warum sich der Vorgang auf diverse Zyklen aufteilen soll.
Die Schleife wird doch schon im ersten Zyklus komplett durchlaufen und müsste für all die Elemente, für die noch keine "Abkürzung" ermittelt und hinterlegt wurde noch "zu Fuss" die Adressen ermitteln.
Laut escrides Beitrag sieht es aber für mich nicht so aus, als ob mehrere Zyklen durch das Ermitteln der Abkürzung in die Länge gezogen würden.
Falls zur Laufzeit wirklich entsprechende Tabellen angelegt werden, dann wäre ja auch die SpeicherBelegung durch solche Massnahmen nicht mehr so vorhersehbar, wie man es bei einer SPS erwartet.
Ein Auslagern von Teilen des ArbeitsSpeichers, die längere Zeit nicht genutzt wurden, zugunsten von ProgrammTeilen, die akut benötigt werden, gibt es bei SPS doch hoffentlich nicht!?
escride1
Level-3
- Beiträge
- 1.262
- Reaktionspunkte
- 327
-> Hier kostenlos registrieren
Ich habe die Messungen mehrfach ausgeführt, die Bilder sind jeweils nur ein Durchgang.
Die Messungen werden zyklisch erzeugt, daher ist jeder Messpunkt auch ein Zyklus. Dazwischen lagen jeweils 10 Zyklen als Pausierung damit man es eben optisch sehen kann.
Da unregelmäßig einige Abarbeitungen länger sind als andere macht die CPU noch irgendwas im Hintergrund. Was, weiß nur Siemens.
Aber: Da die erste Schleife nicht die ist die am längsten dauert und im Zyklus davor und danach nahezu die gleiche Zeit für die Nichtbearbeitung der Schleife anfällt, liegt es nahe, das die Daten nicht beim ersten Aufruf aufgearbeitet werden und Indexe erstellt, sondern das dieses bereits (wie ich irgendwo mal von Siemens gelesen habe) bei optimierten Zugriffen beim Übersetzen&Laden geschieht.
- Beiträge
- 24.323
- Reaktionspunkte
- 7.727
Wird die neu geladene Schleife während der Zykluszeit-Erhöhung schon ausgeführt oder erst danach? Vielleicht dauert das Einketten der neuen Bausteinversion nach dem Laden noch Sekunden? (Test: in dem neuen Programmteil einen SPS-Ausgang einschalten - wann geht der an?)
Harald
Harald
escride1
Level-3
- Beiträge
- 1.262
- Reaktionspunkte
- 327
Verstehe ich nun nicht ganz Harald,
wenn ich die Messung über die Schleife ausführe, dann wird eben nur die Schleife gemessen. Der Zyklus fließt nicht in die Messungen ein. Meine Ergebnisse von 105 Mikrosekunden Dauer erhöhen also die Zykluszeit um diese 105 Mikrosekunden. Bei der 1500er die MFreiberger hat und die ich hier auch genutzt habe wird bei mir der Zyklus dadurch beeinträchtigt, was ja auch nachvollziehbar ist.
Wenn ich das Konstrukt in den OB1 schreibe und den OB30 herausnehme, dann sieht man in der normalen Schwankung der Zykluszeit nichteinmal die Abweichung bei mir. Aber meine CPU ist eben auch leer im Gegensatz zu die vom Kollegen.
Was ich also verdeutlicht habe ist:
- Ausführungsdauer der Schleife auf einer sonst leeren CPU
- Ausführungsdauer der unterschiedlichen Aufrufmöglichkeiten auf einer sonst leeren CPU
Das bei MFreiberger die Abweichung um 20-30ms liegt ist also anhand der Messungen nicht nachvollziehbar. Auch nicht, das es nur einmal vorkommt und danach wieder eingependelt ist. Aber das haben die Kollegen ganz oben ja auch schon abgefragt: Wird irgendwo etwas zyklusintensives durch die Schleife getriggert?
Durch meine Versuche wollte ich, unter anderem auch für mich selbst, herausfinden ob eine Schleife schneller oder langsamer als die direkten Zuweisungen abgearbeitet wird. Die Schleife benötigt länger, ist aber auch kaum verwunderlich da es in C#, C++, ... ebenfalls länger dauert, da das Programm immer zum Pointer zurück springen muss und nicht im Puffer die Daten einmalig runterrattern kann. Der Puffer lädt meistens ja nur vorwärts und nicht rückwärts, wodurch eine Schleife einen Rücksprung bedeutet.
Würde ich, wie vorgeschlagen, einen Ausgang im Konstrukt setzen dann würde ich bei meinem aktuellen Zyklus von weit unter 1ms bei der CPU nichts sehen außer das er einschaltet sobald ich den Trigger für die Schleife aktiviere.
Fazit also: Bei MFreiberger macht die Schleife ein Problem, bei mir nicht, bei gleicher FW und CPU, jedoch sonst anderen Programmen.
Was ich also vorschlagen würde ist, das MFreiberger einmal einen DB erstellt mit zwei Einträgen:
runtimeresult: LREAL
memory: LREAL
und dann einmal vor der Schleife:
runtimeresult:=RUNTIME(memory);
und das gleiche nochmals hinter der Schleife platziert, im gleichen Zyklus.
Dann einen Trace erstellen der auf runtimeresult verweist mit Trigger OB1, zyklisch 1
Anschließend kann im Trace beobachtet werden wie lange diese Schleife bei ihm läuft. Sie muss ja eigentlich annähernd an die Werte kommen die ich auch habe. Er hat also ein Vergleichsergebnis.
Gleichfalls kann man natürlich auch einmal mittels RT_INFO den Zyklus vom OB1 auslesen und ebenfalls an diesem Trace zyklisch anzeigen lassen. Dann sieht man einmal, wie stark die Zykluszeit sich erhöht, und zum zweiten wie lange die Schleife gebraucht hat.
Sollte der Vergleich der Schleife stark voneinander abweichen, dann stellt sich die Frage was noch im Programm genutzt wird, z.B. OB30 mit einer Aufrufzeit knapp oberhalb des normalen Zyklus, bei Schleifeneinsetzung jedoch gerade so in die Schleife hineinfällt und hierdurch den Zyklus signifikant erhöht da mehrere Sprünge aus Programmsicht entstehen, das jedoch nur ab und zu geschieht da Aufruf Schleife zu OB ja asynchron ist.
Ich kann mir vorstellen das MFreiberger bei der Struktur die da oben ist ein nicht zu kleines Programm hat.
Übersehen tun wir ja alle mal irgendwann irgendwas.
wenn ich die Messung über die Schleife ausführe, dann wird eben nur die Schleife gemessen. Der Zyklus fließt nicht in die Messungen ein. Meine Ergebnisse von 105 Mikrosekunden Dauer erhöhen also die Zykluszeit um diese 105 Mikrosekunden. Bei der 1500er die MFreiberger hat und die ich hier auch genutzt habe wird bei mir der Zyklus dadurch beeinträchtigt, was ja auch nachvollziehbar ist.
Wenn ich das Konstrukt in den OB1 schreibe und den OB30 herausnehme, dann sieht man in der normalen Schwankung der Zykluszeit nichteinmal die Abweichung bei mir. Aber meine CPU ist eben auch leer im Gegensatz zu die vom Kollegen.
Was ich also verdeutlicht habe ist:
- Ausführungsdauer der Schleife auf einer sonst leeren CPU
- Ausführungsdauer der unterschiedlichen Aufrufmöglichkeiten auf einer sonst leeren CPU
Das bei MFreiberger die Abweichung um 20-30ms liegt ist also anhand der Messungen nicht nachvollziehbar. Auch nicht, das es nur einmal vorkommt und danach wieder eingependelt ist. Aber das haben die Kollegen ganz oben ja auch schon abgefragt: Wird irgendwo etwas zyklusintensives durch die Schleife getriggert?
Durch meine Versuche wollte ich, unter anderem auch für mich selbst, herausfinden ob eine Schleife schneller oder langsamer als die direkten Zuweisungen abgearbeitet wird. Die Schleife benötigt länger, ist aber auch kaum verwunderlich da es in C#, C++, ... ebenfalls länger dauert, da das Programm immer zum Pointer zurück springen muss und nicht im Puffer die Daten einmalig runterrattern kann. Der Puffer lädt meistens ja nur vorwärts und nicht rückwärts, wodurch eine Schleife einen Rücksprung bedeutet.
Würde ich, wie vorgeschlagen, einen Ausgang im Konstrukt setzen dann würde ich bei meinem aktuellen Zyklus von weit unter 1ms bei der CPU nichts sehen außer das er einschaltet sobald ich den Trigger für die Schleife aktiviere.
Fazit also: Bei MFreiberger macht die Schleife ein Problem, bei mir nicht, bei gleicher FW und CPU, jedoch sonst anderen Programmen.
Was ich also vorschlagen würde ist, das MFreiberger einmal einen DB erstellt mit zwei Einträgen:
runtimeresult: LREAL
memory: LREAL
und dann einmal vor der Schleife:
runtimeresult:=RUNTIME(memory);
und das gleiche nochmals hinter der Schleife platziert, im gleichen Zyklus.
Dann einen Trace erstellen der auf runtimeresult verweist mit Trigger OB1, zyklisch 1
Anschließend kann im Trace beobachtet werden wie lange diese Schleife bei ihm läuft. Sie muss ja eigentlich annähernd an die Werte kommen die ich auch habe. Er hat also ein Vergleichsergebnis.
Gleichfalls kann man natürlich auch einmal mittels RT_INFO den Zyklus vom OB1 auslesen und ebenfalls an diesem Trace zyklisch anzeigen lassen. Dann sieht man einmal, wie stark die Zykluszeit sich erhöht, und zum zweiten wie lange die Schleife gebraucht hat.
Sollte der Vergleich der Schleife stark voneinander abweichen, dann stellt sich die Frage was noch im Programm genutzt wird, z.B. OB30 mit einer Aufrufzeit knapp oberhalb des normalen Zyklus, bei Schleifeneinsetzung jedoch gerade so in die Schleife hineinfällt und hierdurch den Zyklus signifikant erhöht da mehrere Sprünge aus Programmsicht entstehen, das jedoch nur ab und zu geschieht da Aufruf Schleife zu OB ja asynchron ist.
Ich kann mir vorstellen das MFreiberger bei der Struktur die da oben ist ein nicht zu kleines Programm hat.
Übersehen tun wir ja alle mal irgendwann irgendwas.
- Beiträge
- 24.323
- Reaktionspunkte
- 7.727
-> Hier kostenlos registrieren
Meine Frage und Testhinweis beziehen sich darauf, daß die temporäre Zykluszeiterhöhung vielleicht gar nicht von der Abarbeitung der Schleife herrührt, sondern noch Teil des Ladevorgangs außerhalb des SPS-Programms ist, und wie man das testen kann. Den selben Umstand, den Du selber im Beitrag vorher erwähnt hast ...
Deine Zeitmessungen zeigen zwar schön die alte Weisheit, daß Schleifen signifikant länger dauern als lineare Programmierung, tragen aber leider wenig zur Erhellung des Problems hier bei.
Es ist übrigens nicht das erste mal, daß in der Firmware der S7-1500 "versehentlich" solche Zykluszeitbomben bei Zugriffen des PG auf die CPU eingebaut wurden.
@MFreiberger: Verbessert vielleicht die neueste Firmwareversion V2.8.1 das Problem?
Harald
OP
MFreiberger
Level-3
- Beiträge
- 3.282
- Reaktionspunkte
- 926
Moin Zusammen,
vielen Dank für die rege Diskussionsbeteiligung!
Die Zykluszeitinformation wird einfach aus den Systemvariablen den OB1 ausgelesen (OB1_PREV_CYCLE).
Das habe ich versucht. Die Zykluszeit erhöht sich nur nach dem Laden des Programms; nicht nach dem aktivieren/deaktivieren der Schleife.
Wir verwenden TIA 15.1. Da kann ich bis max. V2.6 projektieren. Die CPU selber hat die FW 2.8.1
Inzwischen habe ich festgestellt, dass ich auch nach dem Laden des Programms ohne Schleifen (auskommentiert), eine anfängliche Zykluszeiterhöhung auf ~50ms habe. Ich kann mir nicht mehr vorstellen, dass der Kollege einen Unterschied zwischen dem Programm mit Schleife zu dem Programm ohne Schleife hatte. Viel mehr denke ich, dass er die Zykluszeit zu unterschiedlichen Zeitpunkten nach dem Laden geprüft hatte.
Nach einem Stop-Start der CPU kann ich das Verhalten der Zykluszeiterhöhung nicht feststellen; nur nach dem Laden eines Programms. Zum Test habe ich einmal nur eine Änderung des Codes in Form von einer Bitzuweisung programmiert. Damit ich zwar laden kann, aber die Änderung nicht so gravierend sind. Trotzdem kommt es nach dem Laden zu einer Erhöhung der Zykluszeit.
Ein paar Testergebnisse:
- Stop-Start: keine Zykluszeiterhöhung - Ausgelesen über Onlinediagnose
- 24V OFF-ON: keine Zykluszeiterhöhung - Ausgelesen über CPU-Display
- Programmänderung laden: Zykluszeiterhöhung für ~8s - Ausgelesen über Onlinediagnose
VG
Mario
vielen Dank für die rege Diskussionsbeteiligung!
Die Zykluszeitinformation wird einfach aus den Systemvariablen den OB1 ausgelesen (OB1_PREV_CYCLE).
Das habe ich versucht. Die Zykluszeit erhöht sich nur nach dem Laden des Programms; nicht nach dem aktivieren/deaktivieren der Schleife.
Wir verwenden TIA 15.1. Da kann ich bis max. V2.6 projektieren. Die CPU selber hat die FW 2.8.1
Inzwischen habe ich festgestellt, dass ich auch nach dem Laden des Programms ohne Schleifen (auskommentiert), eine anfängliche Zykluszeiterhöhung auf ~50ms habe. Ich kann mir nicht mehr vorstellen, dass der Kollege einen Unterschied zwischen dem Programm mit Schleife zu dem Programm ohne Schleife hatte. Viel mehr denke ich, dass er die Zykluszeit zu unterschiedlichen Zeitpunkten nach dem Laden geprüft hatte.
Nach einem Stop-Start der CPU kann ich das Verhalten der Zykluszeiterhöhung nicht feststellen; nur nach dem Laden eines Programms. Zum Test habe ich einmal nur eine Änderung des Codes in Form von einer Bitzuweisung programmiert. Damit ich zwar laden kann, aber die Änderung nicht so gravierend sind. Trotzdem kommt es nach dem Laden zu einer Erhöhung der Zykluszeit.
Ein paar Testergebnisse:
- Stop-Start: keine Zykluszeiterhöhung - Ausgelesen über Onlinediagnose
- 24V OFF-ON: keine Zykluszeiterhöhung - Ausgelesen über CPU-Display
- Programmänderung laden: Zykluszeiterhöhung für ~8s - Ausgelesen über Onlinediagnose
VG
Mario
Zuletzt bearbeitet:
- Beiträge
- 24.323
- Reaktionspunkte
- 7.727
Hast Du mal in dem neu nachgeladenen Code sofort einen freien SPS-Ausgang fest auf 1 geschaltet und geschaut, ob die Ausgangs-LED schon vor/während der Zykluszeiterhöhung angeht oder eher erst danach, wenn die Zykluszeit wieder normal ist? Letzteres bedeutet, die Zykluszeiterhöhung kommt nicht aus Deinem Programm, sondern wird von der Firmware außerhalb des SPS-Programms verursacht und könnte mit erhöhtem Rechenzeitbedarf durch/nach dem Laden zu tun haben.
PS: ich meine den Code im RUN der CPU laden
Harald
PS: ich meine den Code im RUN der CPU laden
Harald
Zuletzt bearbeitet:
- Beiträge
- 24.323
- Reaktionspunkte
- 7.727
-> Hier kostenlos registrieren
Im Beitrag #3 war es noch V2.8.0 - testest Du mit mehreren CPUs?
Harald
OP
MFreiberger
Level-3
- Beiträge
- 3.282
- Reaktionspunkte
- 926
Moin Harald,
Sorry. Ich hätte nur 2.8 oder 2.8.x im Beitrag #3 schreiben sollen. Ich teste nicht mit mehreren CPUs und die FW der CPU ist die 2.8.1
VG
Mario
Sorry. Ich hätte nur 2.8 oder 2.8.x im Beitrag #3 schreiben sollen. Ich teste nicht mit mehreren CPUs und die FW der CPU ist die 2.8.1
VG
Mario
OP
MFreiberger
Level-3
- Beiträge
- 3.282
- Reaktionspunkte
- 926
Moin Harald,
Wenn ich Dich richtig verstehe, meinst Du, dass die CPU erst das Programm intern verarbeitet, bevor sie die Bearbeitung der E/As freigibt? Leider kann ich das nicht testen, da ich hier am Schreibtisch keine E/As habe.
Geladen habe ich meistens im RUN der CPU.
VG
Mario
Wenn ich Dich richtig verstehe, meinst Du, dass die CPU erst das Programm intern verarbeitet, bevor sie die Bearbeitung der E/As freigibt? Leider kann ich das nicht testen, da ich hier am Schreibtisch keine E/As habe.
Geladen habe ich meistens im RUN der CPU.
VG
Mario
