Optimierung Zykluszeit

[schaltanlagen]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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

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

 

[borromeus]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

... 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]

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

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

@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]

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

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

@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).

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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

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]

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]

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.