Step 7 Geschwindigkeit 1500er

Zuviel Werbung?
-> Hier kostenlos registrieren
... schau Dir mal folgenden Beitrag zum Thema Taktsynchronität an:
https://support.industry.siemens.com/cs/de/de/view/109480489

Vorteil ist, dass man vom OB- Aufruf über den IRT- Takt bis hin zur Klemme absolut synchron ist.
Auch bei Zykluszeiten von z.B. 250µs und schneller hast Du einen Jitter <1µs. (das bietet z.B. nicht jeder Feldbus am Markt).
 
... schau Dir mal folgenden Beitrag zum Thema Taktsynchronität an:
https://support.industry.siemens.com/cs/de/de/view/109480489

Vorteil ist, dass man vom OB- Aufruf über den IRT- Takt bis hin zur Klemme absolut synchron ist.
Auch bei Zykluszeiten von z.B. 250µs und schneller hast Du einen Jitter <1µs. (das bietet z.B. nicht jeder Feldbus am Markt).

Das hilft aber im aktuellen Fall wenig.
Die Steuerung besteht aus einer ET200S-CPU mit zentralen Baugruppen.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin und danke für die vielen Gedanken.

Es ist kein Panel als Visu verwendet. Ein normaler Laptop mit WinCC hängt dran über den die Daten dargestellt werden. Ziehe ich das Netzwerkkabel, während die Regelung läuft, ist der Unterschied deutlich. Hängen dazu aber noch Online das PG und beobachte wird die Sache natürlich schlimmer.
 
Moin und danke für die vielen Gedanken.

Es ist kein Panel als Visu verwendet. Ein normaler Laptop mit WinCC hängt dran über den die Daten dargestellt werden. Ziehe ich das Netzwerkkabel, während die Regelung läuft, ist der Unterschied deutlich. Hängen dazu aber noch Online das PG und beobachte wird die Sache natürlich schlimmer.

Das Einlesen der Position und das Ausgeben des Sollwerts im OB35 hast du mit Peripherie-Zugriffen gelöst?
 
Kann man der Kommunikation nicht auch eine niedrigere Priorität zuweisen als die Weckalarme?

mfG René

Nein, bei S7 300 und S7 400 kann man den Einfluss der Kommunikation auf Weckalarme nur einschränken, indem man die komplette Kommunikation einschränkt (Parameter Kommunikationslast auf einen kleineren Wert einstellen).

Die 1500 CPUs haben den grundsätzlichen Vorteil, dass man die Priorität von Weckalarmen höher einstellen kann als die Priorität der Kommunikation (fix 15). Ein 2 ms - Weckalarm hat z.B. default die Priorität 17, man kann sie aber auch ändern. Darüber hinaus stellt sich auch die Frage, ob eine CPU schnell genug rechnen kann für den 2 ms Weckalarm-OB, aber der oben genannte Unterschied ist grundsätzlich und von der Geschwindigkeit der CPU unabhängig.

Hier gibt es Messwerte, mit denen man ein Gefühl für die Performance der diversen CPUs bekommen kann:
https://support.industry.siemens.com/cs/ww/de/view/21869080

Die neueste Version enthält 1500 CPUs. Ältere CPUs sind in älteren Messreihen enthalten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nein, bei S7 300 und S7 400 kann man den Einfluss der Kommunikation auf Weckalarme nur einschränken, indem man die komplette Kommunikation einschränkt (Parameter Kommunikationslast auf einen kleineren Wert einstellen).

Hmm, naja wie gesagt, in der Step 7 Classic Hilfe steht, dass ein Weckalarm auch die Kommunikation unterbricht...

Hast Du da mal was getestet bzw. andere Infos?

gruß.
 
Hmm, naja wie gesagt, in der Step 7 Classic Hilfe steht, dass ein Weckalarm auch die Kommunikation unterbricht...

Hast Du da mal was getestet bzw. andere Infos?

gruß.

Wo hast Du eigentlich Deine Infos her?

Ich habe andere Infos, die ich vorhin schon gesucht aber leider nicht gefunden habe:
https://support.industry.siemens.com/cs/ww/de/view/21626316

In einem 3xx-Gerätehandbuch von 03/2011 heißt es:
Verlängerung der maximalen Alarmreaktionszeit durch Kommunikation
Die maximale Alarmreaktionszeit verlängert sich, wenn Kommunikationsfunktionen aktiv
sind. Die Verlängerung berechnet sich gemäß folgender Formel:
tv: 200 μs + 1000 μs x n %
n = Einstellung der Zyklusbelastung durch Kommunikation
Das Ergebnis wird zur maximalen Alarmreaktionszeit addiert.

Und es folgt ein Beispiel für Prozessalarme:
Für das Beispiel ergibt sich die Prozessalarmreaktionszeit aus folgenden Zeiten:
  • Prozessalarmreaktionszeit der CPU 314C-2 PN/DP: 0,5 ms
  • Verlängerung durch Kommunikation gemäß Formel (siehe Übersicht über die Alarmreaktionszeit (Seite 200)):
    200 μs + 1000 μs x 20 % = 400 μs = 0,4 ms
  • ...


 
im Step7 - HW-Konfig - Eigenschaften der CPU - Zyklus/Taktmerker - auf die Hilfe - Zyklusbelastung durch Kommunikation

dort steht dann:

Mit dem Parameter "Zyklusbelastung durch Kommunikation" können Sie die Dauer von Kommunikationsprozessen, die immer auch die Zykluszeit verlängern, in einem gewissen Rahmen steuern. Kommunikationsprozesse können z. B. sein: Datenübertragung zu einer anderen CPU über MPI oder Laden von Bausteinen (über PG angestoßen).


Testfunktionen mit dem PG werden durch diesen Parameter kaum beeinflußt, sie können die Zykluszeit erheblich verlängern. Die für Testfunktionen zur Verfügung gestellte Zeit kann im Prozeßbetrieb begrenzt werden (nur S7-300).


Wirkungsweise des Parameters


Das Betriebssystem der CPU stellt laufend der Kommunikation den projektierten Prozentsatz der gesamten CPU-Verarbeitungsleistung zur Verfügung (Zeitscheiben-Technik). Wird diese Verarbeitungsleistung für die Kommunikation nicht benötigt, steht sie der übrigen Verarbeitung zur Verfügung.


Auswirkung auf die tatsächliche Zykluszeit


Ohne zusätzliche asynchrone Ereignisse verlängert sich die OB 1-Zykluszeit um einen Faktor, der sich nach folgender Formel berechnen läßt:


Beispiel 1 (keine zusätzlichen asynchrone Ereignisse):
Bei Einstellung der Zyklusbelastung durch Kommunikation auf 50 % kann sich eine Verdopplung der OB 1-Zykluszeit ergeben.


Gleichzeitig wird die OB 1-Zykluszeit auch noch durch asynchrone Ereignisse (z.B. Prozeßalarme oder Weckalarme) beeinflußt. Durch die Verlängerung der Zykluszeit durch den Kommunikationsanteil treten statistisch gesehen auch mehr asynchrone Ereignisse innerhalb eines OB 1-Zyklus auf. Dies verlängert der OB 1-Zyklus zusätzlich. Diese Verlängerung ist abhängig davon, wieviele Ereignisse pro OB 1-Zyklus auftreten und der Dauer der Ereignisbearbeitung.


Beispiel 2 (zusätzlichen asynchrone Ereignisse berücksichtigt):


Bei einer reinen OB 1-Ablaufzeit von 500 ms kann sich durch eine Kommunikationslast von 50 % eine tatsächliche Zykluszeit von bis zu 1000 ms ergeben (unter der Voraussetzung, daß die CPU immer genügend Kommunikationsaufträge zum Bearbeiten hat). Wenn nun parallel dazu alle 100 ms ein Weckalarm mit 20 ms Bearbeitungszeit abläuft, dann würde sich dieser ohne Kommunikationslast mit insgesamt 5*20 ms = 100 ms auf den Zyklus verlängernd auswirken, d. h. die tatsächliche Zykluszeit wäre 600 ms. Da ein Weckalarm auch die Kommunikation unterbricht, wirkt er sich bei 50% Kommunikationslast mit 10 * 20 ms auf die Zykluszeit aus, d.h. in diesem Fall beträgt die tatsächliche Zykluszeit nicht 1000 ms sondern 1200 ms.


Hinweise


· Überprüfen Sie die Auswirkungen einer Wertänderung des Parameters "Zyklusbelastung durch Kommunikation" im Anlagenbetrieb.


· Die Kommunikationslast muß beim Einstellen der minimalen Zykluszeit berücksichtigt werden, da es sonst zu Zeitfehlern kommt.


Empfehlungen


· Übernehmen Sie nach Möglichkeit den voreingestellten Wert


· Vergrößern Sie den Wert nur dann, wenn die CPU hauptsächlich zu Kommunikationszwecken eingesetzt wird und das Anwenderprogramm zeitunkritisch ist!


· In allen anderen Fällen den Wert nur verringern!


· Stellen Sie Prozeßbetrieb ein (nur bei S7-300) und begrenzen Sie die für Testfunktionen dort benötigte Zeit!

vielleicht scheint das die Theorie zu sein.

in Deinem Link: https://support.industry.siemens.com/cs/ww/de/view/21626316 haben Sie es gemessen, also eher die Praxis.

vielleicht ist aber auch beides richtig:
- bei starker Kommunikation wird zwar die Kommunikation durch den OB35 unterbrochen, aber trotzdem verlängert sich die OB35 Aufrufzeit (etwas)?

naja, wer weiss das schon ;)

@TE
- ich würde erstens schauen, ob man den Parameter "Zyklusbelöastung durch Kommunikation" reduzieren kann, vielleicht auf 10 oder 5%
- im OB35 MÜSSEN alle Zugriffe auf E/As als PEW PAW ausgeführt sein
- der OB35 darf auf keine VAriablen zugreifen, welche im OB1 (langsam) berechnet werden

Gruß.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
vielleicht ist aber auch beides richtig:
- bei starker Kommunikation wird zwar die Kommunikation durch den OB35 unterbrochen, aber trotzdem verlängert sich die OB35 Aufrufzeit (etwas)?

naja, wer weiss das schon ;)

Ne, der Satz ist leider falsch, nur die Schlussfolgerung ist korrekt: "... in diesem Fall beträgt die tatsächliche Zykluszeit nicht 1000 ms sondern 1200 ms."

Das liegt aber nicht daran, dass ein Weckalarm die Kommunikation unterbricht, sondern dass die Kommunikation jede Millisekunde für x% den Zyklus unterbricht und dass unabhängig davon der Weckalarm alle 100 ms den Zyklus unterbricht.

Was nicht beschrieben ist: die Kommunikation unterbricht auch den Weckalarm. Bei 50% Kommunikationslast würde sich die Bearbeitung des Weckalarms von 20 auf bis zu 40 ms verlängern. Das kann man auch messen, vorausgesetzt man schafft es die 50% Kommunikationslast auch wirklich zu erzeugen.
 
mal so ganz grob ne andere frage du schreibst im ersten beitrag das deine regelungsglieder mit 25 hz arbeiten wieso willst du dann überhaupt den ob35 mit 2ms abarbeiten? 25hz -> 40ms
ich vermute auch wie manche hier schon gefragt haben das du deine werte im ob35 nicht mit pew/paw liest und schreibst und somit sich erst nach dem normalen zyklus ende sich was am paw ändert und dieser sich schnell ändern kann je nachdem wieviel kommuniziert wird wie hier auch schon oft geschrieben

grüßel
 
Hi und nochmal Danke für euere Gedanken. Tatsächlich wird der PAW und der PEW in einem FC bearbeitet, der im OB1 aufgerufen wird. LEider bin ich nicht an der Anlage und kann das versuchen. Klingt aber einleuchtend.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Was erzteufele und die anderen meinen ist, dass im OB35 die E/A aus PEW/PAW gehandelt werden müssen.
Ansonsten erhälst du im schnellen OB35 Task nur Prozesswerte mit der Aktualität des langsameren Task ( OB1 )
 
Zurück
Oben