TIA Schlechter Programmierstiel / Hohe Zykluszeit

[mallepalle83]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich habe einen Baustein geschrieben, der die Steuerung/Koordinierung eines Antriebes übernehmen soll. Er wird über die In/Out/InOut Variablen verschaltet und soll an Multiinstanz verwendet werden.
Gleichzeitig kann er über ein passendes Faceplate (Bedienbaustein) über ein HMI bedient werden. An sich erst einmal nichts schwieriges, sollte man meinen.

Jedoch vermute ich, dass ich durch einen schlechten Programmierstiel hohe Zykluszeiten der SPS verursache.
Dieser Baustein wird in meinem aktuellen Programm ca. 34 mal verwendet. Einen ähnlichen Baustein habe ich auch noch für die Steuerung von Ventilen. Dieser wird auch noch einmal ca. 24 mal verwendet.

Die Zykluszeit der aktuell Eingesetzten S7-1515F beträgt ca. 20-30 ms und schwankt auch relativ stark. Also immer Sprünge im >5 ms Bereich.

Ich würde mich freuen, wenn einer von euch sich diesen Baustein einmal ansehen könnte und einmal im groben sagt --> Das ist richtig schlecht, mach das so!
Zum Beispiel, greife ich jetzt für die Visualisierung auf eine InOut Variable zu. Sollte man hier lieber direkt auf den Instanz-DB durch das HMI zugreifen? So macht es zumindest Siemens bei ihren Faceplatebausteinen?! Dies spart dann zumindest schon einmal das erneute umkopieren von Zuständen auf die InOut Visu Variable! Allerdings finde ich den Zugriff auf Instanzdaten nicht gerade sauber programmiert und bin der Meinung, die Instanzdaten sollten immer nur dem jeweiligen Baustein gehören!

Im Anhang noch der Baustien als TIAV16 BIBLIOTHEK

Mit freundlichen Grüßen,
Mallepalle

 

[TP-Inc]

Hi, ich hab kein V16, kannst du den Baustein als PDF drucken und hier posten? Warum vermutest du schlechten Programmierstil?

 

[mallepalle83]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi, ich hab kein V16, kannst du den Baustein als PDF drucken und hier posten? Warum vermutest du schlechten Programmierstil?

Hi, wegen der hohen und schwankenden Zykluszeit der CPU
Anbei der Baustein als PDF.

mfg

 

[de vliegende hollander]

Hast du vielleicht viel ProgramAlarm im Programm?
Die sind tötlich für zykluszeiten.

Zum Baustein:
Viel IF Else , da lässt sich auch dürch case ersetzen
erst mal nicht schlimm, aber für die übersichtlichkeit.

PT1 Zeit mit 100ms? reale OB Zeit wird nich übergeben.

Im Baustein koomt einiges an Logik zusammen, aber sehe auch keine Schleifen.

 

[rostiger Nagel]

Grundsätzlich dürfte so ein Baustein eine 1515 gar nicht kratzen,
auch wenn er öfter aufgerufen wird.

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Man müsste das gesamte Programm betrachten, nicht nur die zwei "optimierten" Bausteine. Wie sieht sieht der Rest aus, insbesondere die DBs, bzgl. optimiert/nichtoptimiert?

 

[Fluffi]

Es gibt von Siemens einen Profiler-Baustein der ausgibt wie sich einzelne Bereiche in deinem Programm auf die Zykluszeit auswirken. Vielleicht hilft dir das weiter.

 

[vollmi]

Ich seh nur kleinere Schönheitsfehler wie bedingt aufgerufene Timer. Viele if then welche man wohl leserlicher gestalten könnte, konstanten könnte man gegen symbolbehaftete konstanten ersetzen. Aber da keine rücksprünge oder Schleifen. Ggf mal um einem der Bausteine einen runtime basteln. Dann siehst du ob und wann die zykluszeiterhöhung stattfindet.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es gab kürzlich im Siemens Forum einen Thread, wo eine nicht unerhebliche Laufzeiterhöhung bei der Verwendung von UDTs an InOut festgestellt wurde. Und das alleine durch die Parameterübergabe wenn man den Tests glauben konnte:

https://support.industry.siemens.com/tf/de/de/posts/laufzeit-udt-an-inout/251770

Mangels Hardware kann ich das nicht verifizieren ob alleine die Parameterübergabe schon so viel Zeit benötigt, halte ich für nicht erklärbar.

 

[mallepalle83]

Hast du vielleicht viel ProgramAlarm im Programm?
Die sind tötlich für zykluszeiten.

Zum Baustein:
Viel IF Else , da lässt sich auch dürch case ersetzen
erst mal nicht schlimm, aber für die übersichtlichkeit.

PT1 Zeit mit 100ms? reale OB Zeit wird nich übergeben.

Im Baustein koomt einiges an Logik zusammen, aber sehe auch keine Schleifen.

ProgramAlarm verwende ich keine.

Man müsste das gesamte Programm betrachten, nicht nur die zwei "optimierten" Bausteine. Wie sieht sieht der Rest aus, insbesondere die DBs, bzgl. optimiert/nichtoptimiert?

In der Regel nur optimierte Bausteine. Ich werde heute noch einmal explizit einzelne Bausteine auskommentieren um das Verhalten der CPU besser eingrenzen zu können

Es gibt von Siemens einen Profiler-Baustein der ausgibt wie sich einzelne Bereiche in deinem Programm auf die Zykluszeit auswirken. Vielleicht hilft dir das weiter.

Besten Dank für den Hinweis, ich werde mir diesen Beitrag einmal näher ansehen und die Bibliothek einbinden

Es gab kürzlich im Siemens Forum einen Thread, wo eine nicht unerhebliche Laufzeiterhöhung bei der Verwendung von UDTs an InOut festgestellt wurde. Und das alleine durch die Parameterübergabe wenn man den Tests glauben konnte:

https://support.industry.siemens.com/tf/de/de/posts/laufzeit-udt-an-inout/251770

Mangels Hardware kann ich das nicht verifizieren ob alleine die Parameterübergabe schon so viel Zeit benötigt, halte ich für nicht erklärbar.

Hallo Thomas, dies würde das Verhalten meiner CPU wiederspiegeln. Ich verwende relativ viele InOut Variablen in Verbindung mit UDTs und habe mich hier an dem S7 Programmierleitfaden gerichtet, in dem ja steht, dass UDT Variablen an InOut nur per Referenz übergeben werden und somit die Laufzeit unabhängig von der Größe des UDT sein sollte.

@all:
was ist denn eine für euch vertretbare Zykluszeit.
Ich finde 20-30 ms schon relativ hoch!

 

[escride1]

Die Zykluszeit der aktuell Eingesetzten S7-1515F beträgt ca. 20-30 ms und schwankt auch relativ stark. Also immer Sprünge im >5 ms Bereich.

Du nutzt doch ext. Geräte mit Buskommunikation. Stell mal die Zyklusbelastung durch die Kommunikation weit runter und beobachte dann was passiert.
Ich tippe darauf das die Kommunikation mit den Geräten die Sprünge verursacht.

 

[Glon]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ob 20-30ms eine "gute" Zykluszeit ist hängt natürlich von der Anlage ab.

Ich mach viel im Anlagenbau für chemische Verfahrenstechnik und da würde ich sagen alles <100ms ist total ausreichend.

 

[mallepalle83]

Du nutzt doch ext. Geräte mit Buskommunikation. Stell mal die Zyklusbelastung durch die Kommunikation weit runter und beobachte dann was passiert.
Ich tippe darauf das die Kommunikation mit den Geräten die Sprünge verursacht.

Hallo escride,
die Zykluszeit für die Aktualisierung der Teilnehmer steht aktuell auf 16ms


@GLON
Dies ist natürlich Anlagenabhängig, da gebe ich Dir recht. Zur Not muss ich Signale die recht Zeitkritisch sind in ein anderes Prozessabbild legen und über einen Weckalarm alle 10 ms Auswerten!

 

[escride1]

Hallo escride,
die Zykluszeit für die Aktualisierung der Teilnehmer steht aktuell auf 16ms
Anhang anzeigen 52182

@GLON
Dies ist natürlich Anlagenabhängig, da gebe ich Dir recht. Zur Not muss ich Signale die recht Zeitkritisch sind in ein anderes Prozessabbild legen und über einen Weckalarm alle 10 ms Auswerten!

Das meinte ich nicht, sondern diesen Punkt:


Kommunikation die nicht zyklisch bearbeitet wird oder aber zu einer HMI/CPU gehen können hierdurch in gewissen Maße beschränkt werden.

 

[mallepalle83]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe jetzt die Kommunikationslast von 50 % auf 20 % gesenkt.
Folgendes Verhalten:
50%


20%

 

[escride1]

Ich habe jetzt die Kommunikationslast von 50 % auf 20 % gesenkt.
Folgendes Verhalten:
50%
Anhang anzeigen 52187

20%
Anhang anzeigen 52188

Wenn das länger so bleibt dann liegt es also an der Kommunikation zu einer HMI, anderen CPUs etc. die den Zyklus hochdrücken, zumindest nach aktuellem Kenntnisstand.
Um das zu ändern also die Kommunikationslast weiterhin unten lassen aber sicherstellen das keine Fehler auftreten (Diagnosepuffereinträge) oder aber Prioritäten der kritischen Bausteine ändern (glaube >15), denn Priorität über (15) wird nicht von der Kommunikation unterbrochen, hängt aber nun vom konkreten Programm ab.