# Optimierung Zykluszeit



## schaltanlagen (8 September 2009)

Hallo zusammen,

kann mir jemand sagen wie ich die Zykluszeit meiner SPS optimieren kann? Welche Grundsätze und Regel sollten eingehalten werden um die Zykluszeit nicht unnötig zu erhöhen.

Danke


----------



## Panzerknacker (8 September 2009)

1. Wenig Code 
2. Wenig Gleitkommaoperationen
3. Wenig Schleifen
4. FCs oder FBs nur bei Bedarf aufrufen - aber Achtung!! der Zustand vom letzten Aufruf bleibt erhalten!
5. Im Zweifel eine schnellere CPU

Gruß Matthias


----------



## jackjones (8 September 2009)

Möglichst keine "Deadlock" Schleifen programmieren ;-)

Externe Kommunikation auf mehrere Zyklen aufteilen... etc...


----------



## borromeus (8 September 2009)

Programmteile, die keine schnelle Bearbeitung benötigen nicht zyklisch aufrufen, sondern zB in einem WeckOB oder zeitgesteuert- zB ein Analogwert wird i.A. reichen alle Sekunden einzulesen, ein (normaler) Temperaturregler wird alle 5s auch keinen Verlust der Regelgüte haben.

Dies hat allerdings den Nachteil, dass die Zykluszeit nicht konstant ist.
Ich denke das hängt sehr vom jeweiligen Programm und die Anforderung an dieses ab.

Im Allgemeinen kümmer ich mich nur soweit darum, dass ich keine anderen Systeme plattmache: ZB Daten senden am Bus nur bei Änderung oder alle 10s. Normalerweise sind die SPSn ohnehin sehr schnell.
Hast Du einen konkreten Anwendungsfall, dh ein fertiges Programm?

lG
Karl


----------



## Ralle (8 September 2009)

Mal so einige Sachen:

1. Keine Schleifen oder zumindest nur kurze Schleifendurchläufe.
2. Abhängig von der CPU können bestimmte Berechnungen sehr lange dauern, z.Bsp. bei älteren 315 Berechnungen mit Realzahlen. Wenn das häufig gemacht wird, unbedingt mal die Bearbeitungszeiten der einzelnen Operationen und Befehle ansehen.
3. Stringoperationen arbeiten i.d.R. mit 255 Byte-Strings, das kann sich ebenfalls summieren. 
4. Zugriffe auf extrem verschachtelte DB-Variablen benötigen wohl auch sehr viel Zeit. Wenn möglich DB mit "flachen" Strukturen verwenden, außerdem benötigen solche DB sehr viel mehr Ladespeicher.
5. Im Notfall kann man natürlich auch eine schnellere SPS einsetzen z.Bsp die VIPA Speed7.


----------



## schaltanlagen (8 September 2009)

Danke schonmal, 

Ja habe ein fertiges Programm, sollte aber aufgrund von Datenaufzeichnung etwas schneller sein. Kann ich was erreichen wenn ich die Profibusadressen und oder die FB/FC/DB - Nr. niedrig halte?

MFG


----------



## Ralle (8 September 2009)

schaltanlagen schrieb:


> Danke schonmal,
> 
> Ja habe ein fertiges Programm, sollte aber aufgrund von Datenaufzeichnung etwas schneller sein. Kann ich was erreichen wenn ich die Profibusadressen und oder die FB/FC/DB - Nr. niedrig halte?
> 
> MFG



Nein, glaub ich nicht!


----------



## marlob (8 September 2009)

schaltanlagen schrieb:


> Danke schonmal,
> 
> Ja habe ein fertiges Programm, sollte aber aufgrund von Datenaufzeichnung etwas schneller sein. Kann ich was erreichen wenn ich die Profibusadressen und oder die FB/FC/DB - Nr. niedrig halte?
> 
> MFG


Die FC/FB/DB-Nummern bzw. die Profibusadresse haben nichts mit der Zykluszeit zu tun
wenn, dann höchstens die Anzahl derer


----------



## Panzerknacker (8 September 2009)

Ralle schrieb:


> Mal so einige Sachen:
> 4. Zugriffe auf extrem verschachtelte DB-Variablen benötigen wohl auch sehr viel Zeit. Wenn möglich DB mit "flachen" Strukturen verwenden, außerdem benötigen solche DB sehr viel mehr Ladespeicher.



Hallo Ralle,
was verstehst du unter extrem verschachtelt? Ist mir noch garnicht aufgefallen das der Zugriff darauf mehr Zeit braucht und es auch mehr Ladespeicher kostet!? Wie bekommt man denn offline die Größe für den benötigten Ladespeicher heraus? angezeigt wird ja nur der Arbeitsspeicher. Habe gerade mal zwei DBs angelegt. Einen mit 6x array[1..10] of int je eine ebene tiefer mit STRUCT verschachtelt und einen mit einem array [1..60] of int - laut SIMATIC Manager sollen die beiden gleich groß im Arbeitsspeicher sein.
Aber auch ich lasse mich natürlich gerne eines besseren belehren 

Gruß,
Matthias


----------



## marlob (8 September 2009)

Panzerknacker schrieb:


> ... Wie bekommt man denn offline die Größe für den benötigten Ladespeicher heraus? ...


Wie können Sie die Größe des Lade- und Arbeitsspeichers ermitteln?


----------



## Ralle (8 September 2009)

Panzerknacker schrieb:


> Hallo Ralle,
> was verstehst du unter extrem verschachtelt? Ist mir noch garnicht aufgefallen das der Zugriff darauf mehr Zeit braucht und es auch mehr Ladespeicher kostet!? Wie bekommt man denn offline die Größe für den benötigten Ladespeicher heraus? angezeigt wird ja nur der Arbeitsspeicher. Habe gerade mal zwei DBs angelegt. Einen mit 6x array[1..10] of int je eine ebene tiefer mit STRUCT verschachtelt und einen mit einem array [1..60] of int - laut SIMATIC Manager sollen die beiden gleich groß im Arbeitsspeicher sein.
> Aber auch ich lasse mich natürlich gerne eines besseren belehren
> 
> ...



Irgendwo in den Tiefen dieses Forums steckt die Antwort oder bei Siemens.  Ich kann mich definitiv an einen Beitrag erinnern, in dem das Besprochen wurde. Das mit dem Speicher habe ich selbst ausprobiert, das mit der Geschwindigkeit gelesen. Allerdings ist das Siemens ja so, daß die auch an den SPS arbeiten, so daß natürlich mit jeder neuen FW-Version auch da Änderungen erfolgt sein können.

Ich selbst hab mal aus einem DB die Scructs und UDT rausgenommen, damit der noch ins AG zu übertragen war und das klappte definitiv.


----------



## borromeus (8 September 2009)

schaltanlagen schrieb:


> Danke schonmal,
> 
> Ja habe ein fertiges Programm, sollte aber aufgrund von Datenaufzeichnung etwas schneller sein. Kann ich was erreichen wenn ich die Profibusadressen und oder die FB/FC/DB - Nr. niedrig halte?
> 
> MFG


 
Lass uns an Deinem Programm teilhaben!
Welche Daten werden wo aufgezeichnet?

lG
Karl


----------



## Panzerknacker (8 September 2009)

@marlob:
Danke für den Link!

@Ralle:
Okay, die verschachtelte Variante benötigt dann also 282Byte Ladespeicher
und die als einfaches Array ausgelegte Variante benötigt nur 220Byte.
ABER!
Wenn ich komplett ohne array arbeite und ganz flach nur 60 INT Werte anlege, dann benötigt der DB 322Byte im Ladespeicher.

Ich vermute mal, das es nicht an der Schachtelung liegt, sondern wie viele Zeilen in der Deklarationssicht verwendet werden (ins blaue geschossen, aber sieht für mich danach aus).


----------



## marlob (8 September 2009)

Panzerknacker schrieb:


> Hallo Ralle,
> was verstehst du unter extrem verschachtelt? Ist mir noch garnicht aufgefallen das der Zugriff darauf mehr Zeit braucht und es auch mehr Ladespeicher kostet!? Wie bekommt man denn offline die Größe für den benötigten Ladespeicher heraus? angezeigt wird ja nur der Arbeitsspeicher. Habe gerade mal zwei DBs angelegt. Einen mit 6x array[1..10] of int je eine ebene tiefer mit STRUCT verschachtelt und einen mit einem array [1..60] of int - laut SIMATIC Manager sollen die beiden gleich groß im Arbeitsspeicher sein.
> Aber auch ich lasse mich natürlich gerne eines besseren belehren
> 
> ...


Unterschiedliche Zugrifszzeiten auf DB können vorkommen
Dies

```
AUF DB5
 U DBX 0.0
 U DBX 0.1
 = DBX 0.2
```
ist schneller als dies

```
U "Datenbaustein".Wert_1  //DB5.DBX0.0
 U "Datenbaustein".Wert_2  //DB5.DBX0.1
 = "Datenbaustein".Wert_4  //DB5.DBX0.2
```
Die Grösse eines DB hängt auch davon ab, wie man ihn deklariert. 16 bool-Variablen benötigen mehr Platz als eine Word-Variable
Siehe auch Siemens-FAQ


----------



## Ralle (8 September 2009)

Panzerknacker schrieb:


> @marlob:
> Danke für den Link!
> 
> @Ralle:
> ...



Ich sprach auch nicht von Array als Verschachtelung, sondern nur von Struct und UDT. Unter extremer Verschachtelung verstehe ich Struct in Struct, udt in Struct, udt in udt usw. Aber nun wissen wir wenigstens, das Array für den Ladespeicher Platzsparender sind, als normal deklarierte Variablen, das ist ja schon Mal eine ganz gute Nachricht. Was Siemens da wohl genau im Ladespeicher veranstaltet? Denn genau der ist i.d.R. der Engpass bei den 300-er SPS.


----------



## Ralle (8 September 2009)

marlob schrieb:


> Wie können Sie die Größe des Lade- und Arbeitsspeichers ermitteln?



Aber man kann das auch für den einzelnen Datenbaustein bekommen, indem man den DB im Manager anclickt, dann rechte Maustaste und "Objekteigenschaften/Allgemein-Teil 2".


----------



## MSB (8 September 2009)

Das einzige was ich so festgestellt habe, was richtig Zykluszeit kostet:
IN/OUT Variablen am FB generell und in extremer Weise wenn es sich hier um eine UDT-Variable handelt.

Die Anderen Sachen beschränken sich imho eher auf ein paar wenige zehntel ms.

Ansonsten würde ich sagen das es nahezu unmöglich ist ein bestehendes Programm
durch irgendwelche Kleinigkeiten, ohne wenigstens problematisch Teile komplett neu zu erstellen,
signifikant schneller zu bekommen.
Die Sache mit den Reglern erscheint auch noch sinnvoll und relativ leicht umzusetzen (falls es die Applikation hergibt).

Hier hilft wohl wenns einfach sein soll wirklich nur eine entsprechend größere CPU.

Mfg
Manuel


----------



## Panzerknacker (8 September 2009)

marlob schrieb:


> Unterschiedliche Zugrifszzeiten auf DB können vorkommen
> Dies
> 
> ```
> ...



Vielen Dank - das war sehr aufschlussreich!
Habe testweise mehrere DB's angelegt und einfach nur das erste Wort benutzt - folgendes ist dabei herausgekommen:

array[1..16] of bool - braucht 100Byte Ladespeicher
array[1..1] of bool - braucht 100Byte Ladespeicher
EINE Bool-Variable braucht 86Byte Ladespeicher
EINE Byte-Variable braucht 86Byte Ladespeicher
EINE Word-Variable braucht 86Byte Ladespeicher

EINE DWord-Variable braucht 88Byte Ladespeicher
array[1..32] of bool - braucht 102Byte Ladespeicher

Das oben stehende soll nur die Differenzen aufzeigen. natürlich braucht nicht jedes Array of bool 100Byte Ladespeicher. Dort enthalten ist ja auch die Grundstruktur des DB.

Danach habe ich noch ein bißchen experimentiert und folgendes herausgefunden:
Array of bool zusätzlich 14Byte
Array of byte zusätzlich 14Byte
Array of word zusätzlich 16Byte
Array of dword zusätzlich 18Byte

jede eingefügte Zeile egal ob Bit, Byte, Word, DWord benötigt zusätzlich zum Datenbereich nochmal 2Byte im Ladespeicher


----------



## PN/DP (8 September 2009)

Egal wie extrem ein DB verschachtelt ist, das hat auf die Zugriffszeit keinerlei Auswirkung.
Im MC7-Code steht immer die direkte absolute Adresse, z.B. für 
L "DB2".Array[3].Produkt1.Rezept[2].Datensatz[4].Zutaten.Salz
steht dann direkt 
AUF DB2
L DBW986

Der Ladespeicherbedarf eines DB ist u.a. deshalb größer als der Arbeitspeicherbedarf, weil im 
Ladespeicher auch die Initialwerte der DB-Variablen drinstehen. 100 einzelne INT-Variablen haben 
100 INT-Initialwerte, ein Array [1..100] OF INT hat nur 1 INT-Initialwert.

Gruß
PN/DP


----------



## Jan (8 September 2009)

Ich habe mir mal sagen lassen, dass wenn man bei einer VIPA-CPU bei 2 ms Zykluszeit ist, dann hat man irgendwo einen schweren Programmierfehler drin.
2 ms soll bei einer VIPA schon sehr sehr viel sein.
Habe dies selbst noch nicht testen können, aber wäre ja auch noch eine Möglichkeit die CPU zu tauschen. Dann braucht man beim Programm keine Änderungen vornehmen.


----------



## Ralle (8 September 2009)

Jan schrieb:


> Ich habe mir mal sagen lassen, dass wenn man bei einer VIPA-CPU bei 2 ms Zykluszeit ist, dann hat man irgendwo einen schweren Programmierfehler drin.



Na ja, das ist etwas übertrieben, kommt ja nun wirklich auf die Größer der Anlage an. Aber stimmt schon, über 10ms hab ich die Speed7 auch noch nicht nicht gebracht, jedenfalls mit meinen normalen üblichen Steuerungsaufgaben.


----------



## com (8 September 2009)

Ralle schrieb:


> Na ja, das ist etwas übertrieben, kommt ja nun wirklich auf die Größer der Anlage an. Aber stimmt schon, über 10ms hab ich die Speed7 auch noch nicht nicht gebracht, jedenfalls mit meinen normalen üblichen Steuerungsaufgaben.



hi,

was heisst übliche Steuerungsaufgaben?

gruß
com


----------



## Ralle (8 September 2009)

PN/DP schrieb:


> Egal wie extrem ein DB verschachtelt ist, das hat auf die Zugriffszeit keinerlei Auswirkung.
> Im MC7-Code steht immer die direkte absolute Adresse, z.B. für
> L "DB2".Array[3].Produkt1.Rezept[2].Datensatz[4].Zutaten.Salz
> steht dann direkt
> ...



Da hast du sicher Recht, die Geschwindigkeitsunterschiede gabs bei qualifiziertem und nicht quaifiziertem Zugriff (siehe Beitrag von marlob), die Unterschiede im Speicher bei der Verschachtelung.


----------



## com (8 September 2009)

...ich habe mal folgenden Versuch gemacht:
2 SPS'n: S7-224 und VIPA SPEED 7 CPU313SC 2DPN

im Main/OB1 habe ich mit dem sm0.0 (immer ein) einen Zähler laufen lassen (bei beiden SPS'n nur ein einziges Netzwerk). Dh. jeden Zyklus wurde der Zählerwert einmal inkrementiert.
Die Siemens hat fast doppelt so schnell gezählt 


Gruß


----------



## Ralle (8 September 2009)

com schrieb:


> hi,
> 
> was heisst übliche Steuerungsaufgaben?
> 
> ...



Na ja, bei mir meißt Handlingsysteme inkl. irgendwelcher Mechanismen, die irgendwas zusammensetzen. Aber keine großartige Datenverarbeitung, wie SQL-Server ansprechen, Daten aufzeichnen/auswerten, riesige Datenmengen hin- und herschaufeln und solche Dinge. Auch mit extensiver Stringverarbeitung kann man eine S7-SPS an den Rand der Leistung bringen, das geht sogar recht fix.


----------



## Ralle (8 September 2009)

com schrieb:


> ...ich habe mal folgenden Versuch gemacht:
> 2 SPS'n: S7-224 und VIPA SPEED 7 CPU313SC 2DPN
> 
> im Main/OB1 habe ich mit dem sm0.0 (immer ein) einen Zähler laufen lassen (bei beiden SPS'n nur ein einziger Netzwerk). Dh. jeden Zyklus wurde der Zählerwert einmal inkrementiert.
> ...



Das sagt aber nicht viel aus. Ok, die 200-er ist eh ein ganz anderes System, aber da muß schon eine wenig mehr von der SPS erledigt werden, ehe das vergleichbar wird. Und die 200-er waren ja nicht langsam, nur ebend keine wirkliche S7, also anders zu programmieren und daher für mich nicht wirklich akzeptabel. Wenn schon, dann ein durchgehendes System.


----------



## ge_org (8 September 2009)

Wahnsinn, seit ein paar Minuten lese ich den Beitrag rauf und runter. Jetzt kommt der S7-200 Vergleich mit einer S7-300 (zwar von VIPA aber ist egal). Es ist definitiv kein Vergleich. Musste einige S7-200 übernehmen, wenn das Geld nicht knapp wäre, würde ich mir extra einen 10kg Hammer und ein Fass Bier kaufen und eine Ausstandsfeier für die S7-200 veranstalten, den Ersatz für die 200er hätte ich (UND FÜR DIE VERSCHISSENEN TD200) in der Schreibtischlade!

Zum Beitrag:
Ich habe noch nicht gelesen welche Zykluszeit der Beitragsstarter derzeit hat und wo er hin will. Auch wurde nur von Datenbausteinen geschrieben. Was tut das Ding, wie schnell?

Gerüchten zu Folge, soll eine S7-300 in AWL programmiert schneller als eine in FUP/KOP (oder sonstwas) sein (Gerüchte bewegen sich um die 30%), der exzessive Einsatz von FB für niedere Tätigkeiten die auch in FC abgewickelt werden können soll auch eine nicht unerhebliche Rolle spielen. Wie gesagt handelt es sich nur um Gerüchte!

Vielleicht gibt dieser Beitrag ja einen Aufschluss auf Auswirkungen der Programmiersprache auf S7-300 Zykluszeiten-->damit Gerüchte verstummen oder auch nicht!

Wollte das eigentlich für mich behalten, der Vergleich S7-200/S7-300 hat mich nach 15h Arbeitstag etwas vergrault.

Grüße

Georg


----------



## com (8 September 2009)

ge_org schrieb:


> Wahnsinn, seit ein paar Minuten lese ich den Beitrag rauf und runter. Jetzt kommt der S7-200 Vergleich mit einer S7-300 (zwar von VIPA aber ist egal). Es ist definitiv kein Vergleich. Musste einige S7-200 übernehmen, wenn das Geld nicht knapp wäre, würde ich mir extra einen 10kg Hammer und ein Fass Bier kaufen und eine Ausstandsfeier für die S7-200 veranstalten, den Ersatz für die 200er hätte ich (UND FÜR DIE VERSCHISSENEN TD200) in der Schreibtischlade!
> 
> Zum Beitrag:
> Ich habe noch nicht gelesen welche Zykluszeit der Beitragsstarter derzeit hat und wo er hin will. Auch wurde nur von Datenbausteinen geschrieben. Was tut das Ding, wie schnell?
> ...



schönen Feierabend, du arbeitest zuviel hehe und dann liest du noch sps-zeug hier, klar kommt man bissen durcheinander 

Es kommen auch keine Vergleiche mehr.
... natürlich ist es ein pipifax-Vergelich, aber immerhin ein Vergleich (einfach zum Spass für die SPS-sler)
Intelligenztest besteht z.b. aus 100Bereichen. Das war nur Bereich nr.1 


Gruß
com


----------

