PLC Auslastung optimieren

[Azrael666]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich nutze aktuell CoDeSys 3.5.16.40 mit einer Hardware-PLC und einer Webvisu.
Aktuell liegt meine PLC-CPU Auslastung bei ca. 40% mit einer Zykluszeit von ca. 3-5ms.

Gibt es eine Möglichkeit herauszufinden an welcher Stelle im Programmcode wieviel CPU-Leistung genutzt wird?

MFG
Azrael

 

[DeltaMikeAir]

Vielleicht oder bestimmt geht es auch einfacher aber schau dir mal folgendes an.
Ich finde es ja ganz interessant:

https://store.codesys.com/codesys-profiler.html

 

[asci25]

Zuviel Werbung?
-> Hier kostenlos registrieren

Grundsätzlich kann man auch überlegen, das Programm in mehrere unterschiedlich schnelle Tasks aufzuteilen. Dann kann man nicht so zeitrelevanten Code, der meistens um die 80-90% ausmacht, in einen langsameren Task abarbeiten lassen. Wobei ich 40% Auslastung noch nicht als kritisch ansehe.

 

[Azrael666]

@DeltaMikeAir : Den Profiler hab ich schon entdeckt gehabt. Leider gibt es den nur in der kostenpflichtigen Developer Version.

@ asci25: Das wäre natürlich eine Variante, dazu müsste ich ja aber erst mal rausfinden welcher Codeteil wieviel CPU-Leistung kostet.

 

[oliver.tonn]

Wie asci25 schon schrieb würde ich mir bei einer Auslastung von 40% noch keine Sorgen machen, meine Schmerzgrenze geht so bei 60%-65% los. Zumal Du eine sehr niedrige Zykluszeit hast oder ist mit der Angabe 3-5ms die tatsächliche Ausführungszeit gemeint und die Zykluszeit liegt beim Standard von 10ms?

 

[Azrael666]

Zuviel Werbung?
-> Hier kostenlos registrieren

@oliver : also mein Programm hat einen TASK der ist freilaufend. Die Zykluszeit des Programmes messe ich mit dem Baustein aus der OSCAT-Bibliothek. Dieser Baustein CYCLE_TIME gibt mir ne Zykluszeit von 3-5ms aus. Wenn ich online in die Taskkonfiguration schaue, dann wird mir dort eine Zykluszeit von 1200µs für diesen Task angegeben.

Die 40% sind eventuell noch nicht kritisch. Allerdings würde ich gerne schonmal den Code entsprechend optimieren um für die Zukunft gewappnet zu sein.

 

[oliver.tonn]

@oliver : also mein Programm hat einen TASK der ist freilaufend.
Die 40% sind eventuell noch nicht kritisch. Allerdings würde ich gerne schonmal den Code entsprechend optimieren um für die Zukunft gewappnet zu sein.

Hat das einen besonderen Grund, dass Du eine freilaufende Task genommen hast? Man möge mich korrigieren, falls ich falsch liege, aber im SPS-Umfeld sind doch eher zyklische Tasks üblich.
Ich behaupte mal, wenn Du das umstellst geht Deine Auslastung schon deutlich zurück.

 

[asci25]

... dazu müsste ich ja aber erst mal rausfinden welcher Codeteil wieviel CPU-Leistung kostet.

Das wäre der falsche Ansatz. Du musst festlegen, welcher Teil Deines Programm welche Zykluszeit braucht. Dinge, die nicht so schnell aktuallisiert werden müssen, kannst Du in einen wesentlich langsameren Task legen.

Nicht der Code ist der ausschlaggebende Punkt, sondern die Technologie.

Einfach gesagt:
Langsame Vorgänge --> langsamer Task (vermutlich >90%)
Schnelle Vorgänge --> schneller Task (vermutlich <10%)

 

[Azrael666]

Zuviel Werbung?
-> Hier kostenlos registrieren

@oliver : also den freilaufenden Task habe ich eigentlich genommen, damit der Task eben so schnell wie möglich abgearbeitet werden kann. Im Grunde genommen wie der OB1 in der Siemens-Welt.
Allerdings habe ich auch Netzwerkkommunikation (Datenempfang) und Modbus-Kommunikation. Deswegen wollte ich den Task nicht künstlich ausbremsen.

BTW der Visu-Task ist auch freilaufend!

@asci25: Ich habe schon eine Zyklusmessung in jedem verwendeten Baustein drin den ich in der Software nutze. Ich kann also im Grunde schon sehen wie lange welcher Baustein benötigt.

 

[asci25]

damit der Task eben so schnell wie möglich abgearbeitet werden kann

Ich habe schon eine Zyklusmessung in jedem verwendeten Baustein drin den ich in der Software nutze. Ich kann also im Grunde schon sehen wie lange welcher Baustein benötigt.

Jetzt tritt doch mal einen Schritt zur Seite. Damit Du von Deiner Leitung runterkommst.

Einfach gesagt:
Langsame Vorgänge --> langsamer Task (vermutlich >90%)
Schnelle Vorgänge --> schneller Task (vermutlich <10%)

Löse Dich mal von der Software und betrachte es von der Hardware aus.

 

[Azrael666]

@asci25: welche Leitung? Also jetzt steh ich eher auf dem Schlauch.

 

[asci25]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich bin Elektriker halt....

Spaß beiseite.

Du möchtest mit der Auslastung runter? Das geht nur, wenn Du den Code verkleinerst oder Zykluspausen ermöglichst --> fester Zyklus > benötigte Abarbeitungszeit.
Es gibt aber Vorgänge, die möchtest Du möglichst schnell abarbeiten, ich vermute wegen der Reaktionszeit.

Das beißt sich.

Einzige Lösung: Du erhöhst die Zykluszeit, dann geht die CPU-Last runter. Grob gesagt ist die CPU-Last ja nur das Verhältnis von Arbeit zu Pause. 10ms Zykluszeit und 3ms Abarbeitungszeit ergeben 30% Last. Grob gesagt.

Wenn aber ein paar Dinge zeitkritisch sind, dann must Du die identifizieren und separat in einem schnellen Task abarbeiten. Da dann die Ausführungszeit durch weniger Code sehr gering ist, kannst Du dafür auch die Zykluszeit runternehmen, ohne dass die CPU stärker belastet wird.

Alles im "OB1" zu haben ist also blöd. Das ist Dein Schlauch.

 

[Azrael666]

Verflixt, ich denke ich verstehe was du meinst. Das ist natürlich etwas kompliziert, weil wie gesagt nur ein Task und das Programm ist inzwischen dermaßen groß und verschachtelt, dass es echt verdammt viel Zeit(Geld) kosten würde, das alles auf mehrere Tasks aufzuteilen.

ich hatte vor längerer Zeit, als das Programm anfing immer größer zu werden, angefangen bestimmte Programmteile über Zeittrigger zu steuern. Das heißt bestimmte Teile die nicht so oft aktualisiert werden müssen werden nicht so oft aufgerufen. Dadurch konnte ich die Zykluszeit gut drücken. Ich vermute aber mal das hilft nicht bei der CPU-Auslastung?

 

[asci25]

Nimm es als Anfängerfehler - es ist ja nicht so problematisch. 40% Auslastung ist unkritisch. Lass es so.

Bei Deinem nächsten Projekt kannst Du jetzt mit neuem Wissen rangehen und das besser planen.

Und bei einem freilaufenden Task, kannst Du tatsächlich nichts an der CPU-Last ändern. Lediglich die Zykluszeit geht runter und der nächste Zyklus startet dadurch eher. Eine Pause gönnt sich die CPU dadurch nicht.

"Zeit-Trigger" zu verwenden ist aber auch eine unorthodoxe Lösung. Empfehlen kann ich es nicht.

 

[Azrael666]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja, das mit den Zeittriggern ist aus der Not heraus geboren, da mir zwischendurch die Zykluszeit durch die Decke gegangen ist und das war die schnellste Lösung die mir eingefallen ist.

Naja das Projekt wird sich durchaus in der Zukunft noch weiter entwickeln. Da werden sicher noch weitere Funktionen eingebaut werden müssen. Im Prinzip fing das ganze Programm mit einer kleinen Idee an und im Laufe der Zeit kamen immer mehr Ideen dazu, die drumherum gebastelt wurden.

D.h. wenn ich von der CPU-Auslastung runter möchte, dann müsste ich mehrere Tasks erzeugen, mit verschiedenen festen Zykluszeiten in denen ich dann die entsprechenden Codes unterbringe, je nachdem wie schnell der Code bearbeitet werden soll.

 

[MFreiberger]

Moin Azrael666,

ob man durch mehrere Tasks die CPU-Last runter bekommt, muss man mal sehen. Deine, aus der Not geborene, Funktion des Zeittriggerns macht ja nicht viel anders.

Ich bin jetzt nicht der CoDeSys-Mann, aber bei SIEMENS wäre es so, dass ein Aufteilen auf mehrere Tasks (bei SIEMENS OBs) die Zykluszeit nur dadurch reduzieren, dass sie nicht alle im gleichen Zyklus aufgerufen werden. Dabei haben die OBs unterschiedliche Prioritäten. Der OB1 (Main-Task) hat die geringste Priorität und wird durch alle anderen OBs unterbrochen. Aber dadurch verlängert sich die Abarbeitungszeit (nicht die Dauer!) des OB1.
Um von der CPU-Last runter zu kommen, bräuchtest Du Tasks, die sequentiell auf Zyklen aufgeteilt werden.

Zyklus 1..2..3..4..5..6..7..
Task 1..2..3..1..2..3..1..

Aber diese ganzen Spielereien machen das Programm doch dann noch unübersichtlicher? Wie wäre es mit einer potenteren CPU?

VG

MFreiberger

 

[MFreiberger]

Moin Azrael666,

oder Du baust Dir quasi selber eigene Tasks.

Beispiel: 10 Bausteine (FC), die jeweils eine eigene Task darstellen.

In der MainTask einen Zykluszähler implementieren, der von 0..9 und wieder von vorne zählt ( Wert = (Wert + 1) mod 10 )

Dann Deine 10 Tasks aufrufen.

Wert = 0 => myTask 1
Wert = 1 => myTask 2
...
Wert = 9 => myTask 10
Wert = 0 => myTask 1

Dann Dein Programm in Deine einzelnen Tasks aufteilen. Da Du es ja schon geschafft hast, Teile zeitverzögert aufzurufen, sollte diese Aufteilung ja auch machbar sein .

VG

MFreiberger

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Um von der CPU-Last runter zu kommen, bräuchtest Du Tasks, die sequentiell auf Zyklen aufgeteilt werden.

Zyklus 1..2..3..4..5..6..7..
Task 1..2..3..1..2..3..1..

Genau, Mario,
wenn man mehrere Tasks hat, die geringe Priorität haben sollen, dann am besten die Organisation der Aufrufe selbst in die Hand nehmen.
Sonst kann man nicht verhindern, dass sie - trotz aller VorsichtsMassnahmen - doch mal alle gleichzeitig bedient werden wollen.

 

[asci25]

ob man durch mehrere Tasks die CPU-Last runter bekommt, muss man mal sehen. Deine, aus der Not geborene, Funktion des Zeittriggerns macht ja nicht viel anders.

Du stehst gerade auf dem selben Schlauch.
Wenn man mit einer Siemens-Brille rumläuft, ist das auch gar nicht so verwunderlich.

Der OB1 ist freilaufend und so lange man einen freilaufenden Zyklus hat, wird die CPU mit maximaler Last fahren, egal wie groß das Programm ist. Dann würden zusätzliche Tasks für die CPU-Last nichts bringen.
Nur wenn alle Tasks fest zyklisch sind, dann geht die CPU-Last runter. Das ist eine Eigenschaft, die man in der Siemens-Welt nicht kennt. Man sieht es nur an der Zykluszeit vom OB1.

Auch Deine Empfehlung einen Task in verschiedene virtuelle Tasks aufzuteilen ist unklug. Dadurch läuft der Task unregelmäßig, je nach Programmschleifengröße. Zeitkritische Vorgänge können dann unnötigerweise verzögert werden, was zu kaum nachvollziebahren Ungenauigkeiten führt.

Einen langsamen Task durch kurze schnellere Tasks zu unterbrechen ist da die bei weitem bessere Methode.

 

[asci25]

Genau, Mario,
wenn man mehrere Tasks hat, die geringe Priorität haben sollen, dann am besten die Organisation der Aufrufe selbst in die Hand nehmen.
Sonst kann man nicht verhindern, dass sie - trotz aller VorsichtsMassnahmen - doch mal alle gleichzeitig bedient werden wollen.

Oje Leute, aus welchem Jahrundert seid Ihr denn entsprungen?

Grundlage Threadübergreifende Programmierung, Sync-Lock-Mechanismen usw. Noch nie was davon genört? Kann man grundsätzlich auch bei Siemens-CPU's anwenden. Und das ist nicht kompliziert, wenn man ein paar einfache Regeln beachtet.