Performanceprobleme im Netzwerk mit PFC200

[sven_r.]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
ich programmiere momentan an einer Gebäudesteuerung inkl. Lichtsteuerung mit eCockpit auf einem PFC200 (750-8212).
Mit einer Projektgröße von rund 9MB und 20 angesteckten I/O-Modulen würde ich es als "mittelmäßig umfangreich" beschreiben.
Leider habe ich in letzter Zeit immer mehr Probleme mit der Performance bei Anwendungen, die über das Netzwerk kommunizieren.
Mein Projekt beinhaltet u.A.:

- 112x DI, 96x DO, 4x AO
- 8 Visu-Seiten mit jeweils ca. 10 Buttons
- Visu i.d.R. nur von einem Client bedient
- Leistungsmessung über 750-494 Klemme
- MODBUS-Kommunikation mit 3 Slaves
- Senden von Lichtsteuersignalen über DMX-Protokoll mit 750-652 Klemme
- Empfang und Senden von Lichtsteuersignalen im Netzwerk über UDP-Befehle (sog. "Streaming-ACN")

Grundsätzlich läuft alles, was die Hardware Ein-/Ausgänge angeht erwartungsgemäß flüssig und schnell. Dennoch bin ich mit der Performance der Netzwerkkommunikation
momentan ziemlich unzufrieden. Ein Wechsel der Visu-Seite im Browser dauert beispielsweise nach dem Klicken mindestens 1,5 Sekunden, wenn man vor dem Bildschirm steht also eine halbe Ewigkeit
Auch die Verarbeitung der UDP-Signale für die Lichtsteuerung ist verhältnismäßig träge (mehrere Sekunden bis ein Wert wirklich angekommen ist).
Alle Komponenten sind in ein Gigabit-Netzwerk eingebunden.

Ich bin ziemlich momentan am Rätseln, ob und wie ich die Reaktionszeiten der Programme, die mit dem Netzwerk interagieren, verbessern kann.
Besonders die Zykluszeit scheint hier entscheidend zu sein, allerdings habe ich hier zu wenig Ahnung, welche Werte man da wählen sollte.
Im Run beobachte ich tatsächliche durchschnittliche Zykluszeiten von 1-3ms laut eCockpit. Meine Tasks (5 Stück) sind auf Werte zwischen 10 und 30ms eingestellt. Jedoch bekomme ich einen FB sogar so "aggressiv programmiert", dass es die Steuerung zum STOP bringt, weil der KBUS-Watchdogtimer ausläuft, dann hilft nur noch ein Powercycle...

Da die SPS offensichtlich ja alles andere als ausgelastet zu sein scheint, frage ich mich, an welchen Stellschrauben ich am besten drehen kann.
Vielleicht hat hier jemand eine Idee?

Freundliche Grüße,
Sven R.

 

[sps_21]

Hallo,

Ich bin ziemlich momentan am Rätseln, ob und wie ich die Reaktionszeiten der Programme, die mit dem Netzwerk interagieren, verbessern kann.
Besonders die Zykluszeit scheint hier entscheidend zu sein, allerdings habe ich hier zu wenig Ahnung, welche Werte man da wählen sollte.
Im Run beobachte ich tatsächliche durchschnittliche Zykluszeiten von 1-3ms laut eCockpit. Meine Tasks (5 Stück) sind auf Werte zwischen 10 und 30ms eingestellt.

Da die SPS offensichtlich ja alles andere als ausgelastet zu sein scheint, frage ich mich, an welchen Stellschrauben ich am besten drehen kann.
Vielleicht hat hier jemand eine Idee?

Klingt eher nach völliger Auslastung der Maschine - auch wenn die Zykluszeit so kurz ist. Webserver und Netzwerk-Socket laufen getrennt und asynchron, profitieren nach meiner Erfahrung aber auch von weniger Auslastung, weil die Slots eben nicht fest sind.
Spontan würde ich sagen: Unwichtiges ist viel zu schnell terminiert. Leistungsmessung vllt. aller Sekunde und EA-Verkehr je nach Interaktivität, aber wohl kaum unter 50 ms.
Die Taskzyklen so ähnlich zu haben ist ... hinterfragbar. Die verdrängen sich ja dann öfter gegenseitig. Womit sich die Frage nach der korrekten Priorisierung stellt.

Interne Visu od. Webseite? Und dann bitte mal aufschreiben, was so an Tasks (samt Inhalt) läuft mit welchen Einstellungen genau (Prio, Slotting, Zeit). Dann kann man besser raten, woran es liegen könnte...

 

[sven_r.]

Zuviel Werbung?
-> Hier kostenlos registrieren

Interne Visu od. Webseite?

Die Visualisierung läuft ganz normal auf dem Webserver vom PFC. Aktualisierungsrate im Visualisierungsmanager steht auf 50ms.

was so an Tasks (samt Inhalt) läuft

Meine Taskkonfiguration sieht, stand jetzt gerade, so aus:
- Main Task/Hauptprogramm (Prio 13/20ms), in dem der Großteil der lokalen Steuerung mit vielen FBs läuft. Theoretisch auch ohne Netzwerkverbindung autark. Steuert Ausgänge an, usw. Energiemessung und sonstige Funktionen liegen auch alle hier.
- VISU-Task (Prio 13/ 50ms), VisuElems.Visu_Prg läuft hier
- MODBUS-Task (Prio 10 / 30ms), ruft ein leichtgewichtiges Programm auf, in dem die Modbusslaves angesprochen werden mit read/write
- DMX-Task (Prio 12/10ms), ruft den FB zum Ansprechen der DMX-Klemme auf und verwaltet 50 kleine FBs mit über DMX-gesteuerten Geräten
- sACN-Task (Prio 12/10ms), empfängt und sendet Lichtsteuerkommandos über UDP-Befehle. Ich habe das Gefühl, dass das Senden reibungsloser funktioniert als das Empfangen. Es gibt nur einen einzigen FB , der zum Empfangen verwendet wird und alle paar Zyklen mit anderen Parametern aufgerufen wird, um verschiedene Kommandos zu empfangen. Bei Empfang trägt eine Schleife die empfangenen 512 Kanäle in ein Array an der entsprechenden Stelle ein.


[EDIT:] Wie rum sind denn nun die Prioritäten? Höhere Zahl = Wichtiger oder genau andersrum? Ich habe gegensätzliche Aussagen dazu gefunden...

Wenn ich das Kommando kennen würde, mit dem man in der Linux-Shell die aktuelle Auslastung von CPU und Netzwerkstack abfragen kann, könnte ich die Probleme evtl weiter eingrenzen.

Das mit dem zeitlichen verschieben von Tasks ist ein guter Tipp. Bei 10ms bzw. Vielfachen davon überschneidet sich momentan ja fast alles und möchte "gleichzeitig" ausgeführt werden.

Gruß Sven

 

[dingo]

Mit Htop auf der Linux Konsole des PFC können die Zugriffe & Auslastungen angezeigt werden

 

[holgermaik]

Hallo Sven
je kleiner die Zahl je höher die Prio. Wobei 1 -3 mit einer Warnung quittiert wird. Ich würde bei 4 anfangen.
Der Visu Task ist meiner Meinung nach zu schnell. hier sind Prio 15 mit 100 oder 150ms meiner Meinung ausreichend.
Dies hat aber nichts mit deinem Problem zu tun.
Wenn gu keine weiteren Programme wie Docker oder NodeRed auf dem PFC hast ist dieser mit dem bischen Kram nicht ausgelastet.
Der Main ist mit 20ms auch recht hastig eingestellt.

Ich würde bei der Aktualisierung der K-Bus Variablen ansetzen und die Aktualisierung der Modbus Verbindung prüfen. Hier auch dem Abschluss der Kommunikation prüfen bevor ein neuer Auftrag angestoßen wird.

Liegt dein Programm im Flash oder auf der SD Karte?
Modbus als TCP/IP oder RTU?

Holger

 

[sps_21]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Visualisierung läuft ganz normal auf dem Webserver vom PFC. Aktualisierungsrate im Visualisierungsmanager steht auf 50ms.

Meine Taskkonfiguration sieht, stand jetzt gerade, so aus:
- Main Task/Hauptprogramm (Prio 13/20ms), in dem der Großteil der lokalen Steuerung mit vielen FBs läuft. Theoretisch auch ohne Netzwerkverbindung autark. Steuert Ausgänge an, usw. Energiemessung und sonstige Funktionen liegen auch alle hier.
- VISU-Task (Prio 13/ 50ms), VisuElems.Visu_Prg läuft hier
- MODBUS-Task (Prio 10 / 30ms), ruft ein leichtgewichtiges Programm auf, in dem die Modbusslaves angesprochen werden mit read/write
- DMX-Task (Prio 12/10ms), ruft den FB zum Ansprechen der DMX-Klemme auf und verwaltet 50 kleine FBs mit über DMX-gesteuerten Geräten
- sACN-Task (Prio 12/10ms), empfängt und sendet Lichtsteuerkommandos über UDP-Befehle.

Ich habe das Gefühl, dass das Senden reibungsloser funktioniert als das Empfangen. Es gibt nur einen einzigen FB , der zum Empfangen verwendet wird und alle paar Zyklen mit anderen Parametern aufgerufen wird, um verschiedene Kommandos zu empfangen. Bei Empfang trägt eine Schleife die empfangenen 512 Kanäle in ein Array an der entsprechenden Stelle ein.

Vorschlag zum Probieren:
Main: prio 15, Zeiten je nach notwendiger Reaktionszeit.
- noch besser: die Energiemessung und andere lahme Enten abgetrennt: prio 20, 1 s

Visu: prio 10
MB, DMX und sACN : prio 6, 10 ms also alle Programme in einen Task hängen (Anm. Der K-Bus ist normalerweise auch nicht schneller. Oder wurde umprogrammiert?)

Dann mal auf die Auslastung achten. Ganz allgemein habe ich nur die Vermutung, dass die Programmierung Teil des Problems ist: ist alles asynchron und mit korrektem Handshake? Achtest Du auf die Füllstände der Sende-/Empfangspuffer? DMX ist doch RS485, will man keine Probleme haben MUSS man auf die Puffer gucken. UDP-Sockets haben auch das Problem. Aber ich will niemanden zu nahe treten - reine Vermutung aus Erfahrung.

PS: Noch ein Hinweis, der aber schon persönlicher Stil ist Ich trenne meist die eigentlichen Protokoll-Handlingsbausteine vom Erstellen/Aufbau der Protokollinhalte. Der Handlingsbaustein hat eine hohe Prio und kurze Aktualisierung - die dann das Protokoll "schnell" abarbeiten. Der andere hat oft eine Menge Stringoperation die ja langsam sind, dafür dann niedriege Prio und langsamer. Der Austausch geht über globale Arrays od. so.
Theoretisch kann man natürlich alles in eins packen, weil man die Erstellung des Protokollinhalts ja immer überspringen kann, wennn man es nicht braucht. Aber..... wenn man etliche Protokolle fährt, so wie du, dann bremst man stets die anderen Bushandler aus, wenn es denn läuft. Ein Baustein - eine Prio. Daher die Trennung in schnell und gemütlich.
Ich komme aber auch von Controllern die deutlich langsamer sind als ein PFC ;-)

 

[sven_r.]

Soo. Folgende Erkenntnisse habe ich gemacht, mit htop die CPU Auslastung ausgelesen:
1. CPU ist mit der alten Programmierung fast dauerhaft im Overload. 100% werden beim SSH-Zugriff angezeigt und eCockpit bekommt auch keine stabile Verbindung.
2. CPU ist allerdings im STOP aber auch bei guten ~25% ????

Es scheint also tatsächlich an der CPU zu liegen. So, jetzt die Frage: Wie bekomme ich die Auslastung runter?
Daraufhin habe ich die Zykluszeiten und Prioritäten angepasst, ähnlich wie den hier vorgeschlagenen:

Task 1: Main (30ms/Prio 10)
Task 2: Netzwerktraffic (sACN, Modbus) 12ms/Prio 6 <- hier mit 12ms statt 10 absichtlich kein Vielfaches vom Main-Task!
Task 3: VISU 50ms/Prio 15

Den DMX-Teil habe ich zum Testen erstmal ganz rausgenommen.
Außerdem noch Zusatzinfos:
- KBus Zyklus ist auf 10ms eingestellt.
- Programm liegt im Flash-Speicher.
- Modbus läuft über TCP/IP.
- Keine weitere Software im Hintergrund neben Codesys, kein Dockercontainer usw.

Ich bin trotzdem immer noch im Bereich von 85%, wenn ich eCockpit verbinde wieder bei 100%. Ich kann es auch nicht wirklich eingrenzen. Ohne den sACN-Task, den ich bis jetzt als Hauptursache vermutet hatte, tut sich auch nicht viel weniger. Mir stellt sich gerade erstmal grundsättzlich die Frage, was denn überhaupt für viel Auslastung sorgt. Vielleicht mal anders gefragt, was sind denn "normale" CPU-Werte bei halbwegs anspruchsvollen SPS-Programmen?

Ich trenne meist die eigentlichen Protokoll-Handlingsbausteine vom Erstellen/Aufbau der Protokollinhalte.

Das habe ich teilweise schon so gemacht. sACN ist nur für den Empfang/Senden von Daten zuständig, das DMX-Programm macht Verarbeitung mit den Daten. Modbus ähnlich, nur im Modbus-Programm werden die Slaves tatsächlich angesprochen, die Vearbeitung im Main-Task beschreibt lediglich die Modbus.-Speichervariablen im Modbus-Namespace.

 

[sps_21]

Schon mal bei Ports und Services od. wie das heisst geschaut, was alles aktiv ist??
Oder ein zu großes EA-Abbild aktiviert??

Das es mit Online-Verbindung hoch geht ist normal, das System nimmt sich was es kriegt. Ob das 25 % sind, habe ich noch nie geschaut, weil keine Probleme
"Normal" gibt es aufgrund der flexiblen Taskverwaltung nicht wirklich. Gut ist, wenn es den Echtzeit-Anforderungen noch entspricht. Was du da brauchst kann ich hier nur raten... Daher stets die Empfehlung selbst in seinen Tasks eine Zeit od. Zyklusüberwachung mitlaufen zu lassen, und die auch irgendwo in der Oberfläche anzuzeigen. (Dann kannst du auch am Anschlag programmieren ;-)

Letztlich hat der PFC doch auch eine Auslastungsanzeige bzgl. Echtzeit - was sagt die eigentlich?

 

[sven_r.]

Zuviel Werbung?
-> Hier kostenlos registrieren

Schon mal bei Ports und Services od. wie das heisst geschaut, was alles aktiv ist??
Oder ein zu großes EA-Abbild aktiviert??

Das es mit Online-Verbindung hoch geht ist normal, das System nimmt sich was es kriegt. Ob das 25 % sind, habe ich noch nie geschaut, weil keine Probleme
"Normal" gibt es aufgrund der flexiblen Taskverwaltung nicht wirklich. Gut ist, wenn es den Echtzeit-Anforderungen noch entspricht. Was du da brauchst kann ich hier nur raten... Daher stets die Empfehlung selbst in seinen Tasks eine Zeit od. Zyklusüberwachung mitlaufen zu lassen, und die auch irgendwo in der Oberfläche anzuzeigen. (Dann kannst du auch am Anschlag programmieren ;-)

Letztlich hat der PFC doch auch eine Auslastungsanzeige bzgl. Echtzeit - was sagt die eigentlich?

Ports and Services hab ich, abgesehen von SSH, nicht angerührt, also nur der Standard aktiv.
Was die Echtzeit-Anforderungen angeht habe ich keine großen Ansprüche, nur halbwegs flüssig sollte es laufen - und das ist ja momentan nicht der Fall, wenn ich mehrere Sekunden warten muss, bis ein Befehl, der über das Netzwerk kommt, von der Steuerung wirklich verarbeitet wurde. Und 100% CPU dauerhaft klingt auch nicht nach nem guten Dauerzustand

Wie kontrolliere ich die Größe vom EA-Abbild und den Status der Echtzeiterfüllung?

Gruß Sven

 

[sps_21]

Und 100% CPU dauerhaft klingt auch nicht nach nem guten Dauerzustand

Wieso?
Solange Echtzeit erfüllt ist, sehe ich da kein Problem.

Viele Tasks sind einfach nicht so zeitkritisch, das wird oft überschätzt. Mach' Butter bei die Fische: Wieviele DMX-Befehle pro Minute sind realisitisch nötig? (Nicht wie schnell muss das Protokoll sien, sondern die Anwenderanforderung an die Lichtsteuerung. Da kommt sicher nicht 100 Befehle pro Minute, zumindest würde mich das wundern ;-) ) Und wie schnell wärst du jetzt - rein theoretisch?


Und was das Web angeht, der Webserver ist einfach nicht rasend schnell - zumindest meiner Erfahrung nach. Das ist ein Nebenjob des PFC.

Wie kontrolliere ich die Größe vom EA-Abbild und den Status der Echtzeiterfüllung?

Für so allg. Fragen empfehle ich dann doch mal das Handbuch zu lesen

 

[oliver.tonn]

Wieso?
Solange Echtzeit erfüllt ist, sehe ich da kein Problem.

Eine CPU sollte keine Auslastung von 100% haben, weil das mit der Echtzeit und anderen Dingen dann ganz schnell in die Hose gehen kann, da keine Luft mehr vorhanden ist.
Bei mir liegt die Schmerzgrenze bei 70%.

 

[sps_21]

Zuviel Werbung?
-> Hier kostenlos registrieren

Eine CPU sollte keine Auslastung von 100% haben, weil das mit der Echtzeit und anderen Dingen dann ganz schnell in die Hose gehen kann, da keine Luft mehr vorhanden ist.

Stimmt. Wenn quasi alles Echtzeit ist, dann sind 70 % sicher richtig.

Der häufige Irrtum ist die Annahme, dass alles schnell und hochpriorisiert sein muss (und das erlebe ich in allen Leistungsklassen). So kann ich sogar deutlich über 100 % Auslastung programmieren OHNE das zu verletzen. Echtzeit sind halt nur 1, 2 Tasks - und der Rest nicht und da liegt der Ausführungszyklus dann auch Faktor 10 über den zeitkritischen Aufgaben. Wenn mir jemand sagt, die Webvisu bei einem Wago-PLC soll so schnell wie ein Lichtschalter reagieren - obwohl vielleicht 100 Byte SSI-Daten gelesen werden müssen, dann geht das eben nicht auch noch.

Manche Dinge kann man ja auch auf Klemmenfunktionen verlagern z. B. Durchschnittsbildung, Min, Max bei Energieverbräuchen. Das muss die Steuerung dann gar nicht leisten...

 

[holgermaik]

Habe mir mal die Mühe gemacht und meinen PFC ausgelesen
(750-8216 FW17) Programm ähnliche Größe deinem
CPU Auslastung:
Linux ohne Projekt - 3%
Projekt geladen / nicht gestartet - 12%
Projekt gestartet / ohne Visu Client - 22%
Zugriff mit einem Client auf Visu - 45%

ich denke das Problem liegt weniger an der Taskeinstellung sondern eher an der Programmierung.
verwendest du Schleifen ?

 

[sven_r.]

Ich habe jetzt noch mal ein bisschen mit den Zeiten gespielt und unkritische Programme in einen 500ms Task ausgelagert.
Bin jetzt bei 81% Auslastung bei Verbindung mit einem Visu-Client - damit könnte ich wohl gerade so leben.

Reaktionszeiten der Visu fände ich "okay"; die UDP-Lichtbefehle kommen zwar alle an, aber mit einer Verzögerung von knapp 2 Sekunden - naja.

Was die Programmierung an geht: Wenn ich alles zusammenrechne, habe ich in Summe ca. 150 Instanzen von Bausteinen. Auch einige Schleifen sind drin, die größte ist das Einlesen der UDP-Daten in ein Array in der GVL (2048 x Byte) - passiert im sACN-Task.
Abgesehen davon nur ab und zu Schleifen über eine Reihe an Objektinstanzen.

 

[Tobsturbo]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
ich habe ein ähnliches Problem , die Netzwerkschnittstelle ist bei mir auch sehr ausgelastet , so dass es sein kann das Ethernet TCP/IP Datenpakete erst mehrere Sekunden später gesendet und empfangen werden.
Die Systemauslastung liegt im Moment bei 45 % laut htop
Wahrscheinlich sollte ich einen extra Task für die Netzwerkkommuniaktion anlegen.

und eventuell einen Switch vor den Wago Controller setzen

Sobald ich aber die Priorität von 15 auf 14 oder geringer einstelle ist die CPU komplett ausgelastet 90-100%.
Zu meiner Applikation :
Hardware :
PFC200 750-8212 G2 COM 1 => serielle Verbindung zum Sensor
750-652 Modbus RTU
und eine digitale I/O Karte

Grob zur Programm Übersicht :
Wago Ecockpit V1.8.0.2

Datenlogger 40 Messwerte werden Zyklisch gespeichert 1-10 Sekunden Takt - WagoApp Datalogger
2x COM-Schnittstelle zum auslesen des Modbus RTU Teilnehmers und einer zweiten seriellen Verbindung

Außerdem werden über eine Webvisu verschiedene Messwerte angezeigt und man kann verschiedene Einstellungen an Konfigurationen und Messparametern, welche in einem ini File auf dem Controller, sowie auf der SD-Karte abgelegt sind ändern, lesen und speichern.


Ethernet TCP/IP zur Bereitstellung der Messwerte an eine S7 und empfang von Steuersignalen.
Port X1 - Anwenderseite S7 Anbindung separate IP , Idee von mir macht es Sinn einen Switch vor die
Port X2 - interner IP-Kreis über einen Switch ist ein Wago-Webpanel und ein Modbus TCP Teilnehmer angeschlossen.

Im Moment läuft das ganze in einem gemeinsamen Task
Nun die Frage , sollte ich die verschiedenen Funktionen auf verschiedene Tasks aufteilen ?
Was meint ihr ?

Taskzykluszeit ist aktuell 50ms eingestellt PLC_PRG
Visu-Task Zyklus => 250ms

 

[sven_r.]

Nun die Frage , sollte ich die verschiedenen Funktionen auf verschiedene Tasks aufteilen ?
Was meint ihr ?

Hi,
vielleicht könntest du erst einmal probieren, an welcher Stelle dein Programm so viel Rechenpower benötigt?
Also mal einzelne Programmteile ausklammern bzw. mit if-Verzweigungen kurzzeitig deaktivieren und dann herausfinden, ob es an einzelnen Stellen liegt oder am Gesamtprogramm.
Normalerweise müsste der PFC mit den Aufgaben, wie du sie beschrieben hast ziemlich unterfordert sein.

 

[Jeno]

Soo. Folgende Erkenntnisse habe ich gemacht, mit htop die CPU Auslastung ausgelesen:
1. CPU ist mit der alten Programmierung fast dauerhaft im Overload. 100% werden beim SSH-Zugriff angezeigt und eCockpit bekommt auch keine stabile Verbindung.
2. CPU ist allerdings im STOP aber auch bei guten ~25% ????

Es scheint also tatsächlich an der CPU zu liegen. So, jetzt die Frage: Wie bekomme ich die Auslastung runter?
Daraufhin habe ich die Zykluszeiten und Prioritäten angepasst, ähnlich wie den hier vorgeschlagenen:

Task 1: Main (30ms/Prio 10)
Task 2: Netzwerktraffic (sACN, Modbus) 12ms/Prio 6 <- hier mit 12ms statt 10 absichtlich kein Vielfaches vom Main-Task!
Task 3: VISU 50ms/Prio 15

Den DMX-Teil habe ich zum Testen erstmal ganz rausgenommen.
Außerdem noch Zusatzinfos:
- KBus Zyklus ist auf 10ms eingestellt.
- Programm liegt im Flash-Speicher.
- Modbus läuft über TCP/IP.
- Keine weitere Software im Hintergrund neben Codesys, kein Dockercontainer usw.

Ich bin trotzdem immer noch im Bereich von 85%, wenn ich eCockpit verbinde wieder bei 100%. Ich kann es auch nicht wirklich eingrenzen. Ohne den sACN-Task, den ich bis jetzt als Hauptursache vermutet hatte, tut sich auch nicht viel weniger. Mir stellt sich gerade erstmal grundsättzlich die Frage, was denn überhaupt für viel Auslastung sorgt. Vielleicht mal anders gefragt, was sind denn "normale" CPU-Werte bei halbwegs anspruchsvollen SPS-Programmen?
Anhang anzeigen 54047



Das habe ich teilweise schon so gemacht. sACN ist nur für den Empfang/Senden von Daten zuständig, das DMX-Programm macht Verarbeitung mit den Daten. Modbus ähnlich, nur im Modbus-Programm werden die Slaves tatsächlich angesprochen, die Vearbeitung im Main-Task beschreibt lediglich die Modbus.-Speichervariablen im Modbus-Namespace.

Hi Sven,
kannst du mir die Befehle im CMD nenne, um die Leistung von der SPS zu sehen?
Danke.

 

[sven_r.]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi Sven,
kannst du mir die Befehle im CMD nenne, um die Leistung von der SPS zu sehen?
Danke.

Moin Jeno,
Wenn du im Konsolenfenster "htop" eingibst, wird der Ressourcenmonitor angezeigt. STRG+C drücken zum Beenden.

Gruß Sven

 

[Jeno]

Bitte ein bisschen genauer...

 

[oliver.tonn]

Bitte ein bisschen genauer...

Noch genauer ging es fast nicht. Du sollst das Konsolenfenster öffnen (CMD, früher DOS-Prompt), dort den Befehl htop eingeben und mit Return/Enter bestätigen, dies öffnet den Ressourcenmonitor, der wiederum mit der Tastenkombination STRG und c beendet werden kann.