CX 8090 - reagiert sehr langsam

[ssyn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich kehre zurück zu meinem Thema. Ich habe die Lösung gefunden. Wieso und was das bedeutet - kann nicht sagen, habe noch zu wenig Kenntnisse, obwohl Support von Beckhoff konnte mir mit diesem Problem auch nicht helfen, aber...

So, in Programm war Aufruf von diesem seltsamen FB:







Ich versuchte schon früher den Aufruf in PRG auskommentieren, aber das half nicht. Steuerung lief SEHR langsam:





Danach ich dachte, vielleicht muss ich FB auch in Deklaration-Bereich auskommentieren? Ich mache das und Ta-da !






Steuerung läuft schnell jetzt. Aber die Lösung wurde nicht nach Kenntnisse sondern nach Vermutung und Intuition gefunden, das ist doof .

Ich verstehe jetzt noch gar nicht aber folgende Sachen:
1. Wo ist in TC2 dieser seltsame FB - FB_WritePersistentData gespeichert? In Bibliothek fand ich ihn nicht. Bei Übersetzung kommt keine Fehler, so FB muss irgendwo sein.
2. Welche Sinn war in gleichzeitige Benutzung von FB_S_UPS_CX80xx und FB_WritePersistentData ?
3. Wenn in Variable Bereich steht die Deklaration von FB - wird FB in Memory immer gelandet, egal - ob steht Aufruf in PRG oder nicht?

Kann jemand bitte die Antworte geben?

 

[asci25]

Ich habe mal das Thema kurz überflogen. Soweit ich es verstanden habe, war die Visu das Problem und nicht die SPS (TwinCAT).
TwinCAT liegt unterhalb des Betriebssystems und wird vom Betriebssystem Windows nicht beeinflusst. TwinCAT kann aber sehr wohl dem Windows die Luft abdrücken, was u.a. dadurch erkennbar ist, dass die TC-Auslastung sehr hoch ist. Das war ja nie der Fall. Und man kann eine Auslastungsgrenze für das TwinCAT einstellen. Standardmäßig liegt die bei 80% der Gesamt-Prozessorleistung.

Das heißt, mit dem, was TwinCAT noch übrig lässt, muss das Windows und die Visu zurechtkommen. Wenn die TC-Auslastung bei 10% steht, hat Windows Zugriff auf 90% der Prozessorleistung. Da bringen Änderungen im SPS-Programm nichts.

So viel zu dem Verhältnis TC <--> Windows (Visu).

Ähnlich sieht es bei der Speicherverwaltung aus. Und wir kennen doch alle Windows - oder? Wenn Speicher voll - Programme langsam... Aber nicht die Steuerung (SPS). Die krallt sich alles, was die zum Leben braucht und zieht durch. Ohne Wenn und Aber.

Steuerung läuft schnell jetzt.

Dieser Satz hat unglaublich viel Missverständnis-Potential. Wer spricht hier: Ein Anwender oder ein Entwickler? Ich vermute, es spricht ein Anwender und der meint nur die Reaktionszeiten der Visu. ("Wenn Speicher voll - Programme langsam...")

Also: Das Auskommentieren des FB hat eine nicht unerhebliche Menge Speicher freigegeben, die jetzt dem Windows und der Visu zur Verfügung stehen. Die Prozessorleistung war gar nicht das Problem.

Wobei die Menge von knapp 12,8KB mich schon überrascht hat. Das ist ca. 1/4 des Gesamtspeichers. Nur für einen FB...

 

[asci25]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich will mal noch die drei Fragen beantworten...

1. Wo ist in TC2 dieser seltsame FB - FB_WritePersistentData gespeichert? In Bibliothek fand ich ihn nicht. Bei Übersetzung kommt keine Fehler, so FB muss irgendwo sein.

Der gehört zur Utilities-Bibliothek.

2. Welche Sinn war in gleichzeitige Benutzung von FB_S_UPS_CX80xx und FB_WritePersistentData ?

Der FB_S_UPS_CX80xx überwacht das Netzteil und initiiert bei Stromausfall das Schreiben der persistenten Daten. Mit dem FB_WritePersistentData kann man diese Daten manuell schreiben. Ob der gleichzeitige Einsatz Sinn macht, oder nicht, kann nur der Entwickler sagen. Vielleicht war das aber auch nur historisch gewachsen.

3. Wenn in Variable Bereich steht die Deklaration von FB - wird FB in Memory immer gelandet, egal - ob steht Aufruf in PRG oder nicht?

Sobald der Baustein in der Deklaration instanziiert wird, wird auch der Speicher allokiert / reserviert. Eine dynamische Speicherverwaltung gibt es unter TC2 noch nicht und ist auch heute im SPS-Bereich eher die absolute Ausnahme. Das ist übrigens die beste Methode Speicherlecks zu verhindern. Zumal SPS-Programme auch noch 24/7 laufen können müssen.

 

[ssyn]

Sorry guys, ja, fast 100% Problem ist in Visu. Ich prüfe es morgen, dann schreibe mehr.

 

[Guga]

Dann auch noch meinen Senf: Ich denke du läufst in die falsche Richtung in Bezug auf den Baustein.

Ein Functionblock wird vom Compiler betrachtet in dem Moment wo er instanziiert wird, vorher nicht.
Ein Functionblock besteht Speichertechnisch aus compilierten Code und dann pro Instanz gibt es Data.

Der Baustein FB_WritePersistentData ist Code und datentechnisch ein ganz schlanker Baustein, quasi nur ein Wrapper um einen ADS-Aufruf.
Im Baustein allokiert wird auch quasi keine Daten (eigene Variablen) Die Funktionalität "Write_PersistenData" wird vom Runtime-Betriebssystem durchgeführt, die Daten werden aus der SPS per ADS an den Systemport 10.000 gesendet (aus dem Gedächtnis heraus) der dann im Betriebssystem sagt "hey - schreibe eine Datei mit den Inhalt der persistenten Daten".

Signifikaten Resourcen ((ADS-Router)-Speicher und Laufzeitresourcen) werden also nur bei Ausführung benötigt.

 

[ssyn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe versprochen das Fazit schreiben, aber habe keine genaue Antworte:

So, die Steuerung arbeitete sehr langsam. Da Problem war in falsche externe Visu-Software. Anstatt "Version A" für CX8090, da wurde andere "Version B" für andere Steuerung benutzt und deswegen lief die Steuerung sehr langsam.
So, Problem hier war nicht in Beckhoff-Steuerung, sondern in externe Visu-Software.

Aber dann war sehr seltsame Situation.

Früher es war Variable ABC

ABC : REAL := 15.0;

So, wenn gibt es keine gespeicherte Retain Wert, dann ABC bei Start von Programm ist gleich 15.0 . Wenn man ändert ABC z.B. auf 2.0, dann muss Wert ABC := 2.0 bleiben.

Ich dachte, dass Problem in Arbeitsspeichermangel von Steuerung (wegen Problem mit Visu) lag.
Ich dachte - "Die Steuerung schafft einfach nicht in 1-3 Sekunden die neue, geänderte Wert von ABC als Retain speichert (wegen Arbeitsspeichermangel) oder macht Wert kaputt und deswegen nimmt die Steuerung den Wert aus Default-Wert Bereich.

Okay, ich habe Problem mit falsche Visu gelöst und außerdem Default-Wert auf 2.0 geändert.

ABC : REAL := 2.0;

Ich habe neue Boot-Version erstellt, Steuerung gestartet und danach habe Wert ABC auf 1.0 geändert. So, ich habe online geguckt - ABC := 1.0;

Aber nach neue Start von Steuerung ich sehe, dass ABC wieder gleich 15.0 ist ! Ich habe überall geprüft - Wert muss entweder 1.0 (Neuer Wert - als Retain gespeichert) oder 2.0 (Default-Wert, wenn Retain-Wert nicht gespeichert ist), aber Wert war gleich 15.0 ! Aber irgendwie alte Default Wert wurde als Retain gespeichert. Und so blieb es immer nach zwei oder drei Reboot.

Nur danach plötzlich wird dieser Wert 15.0 weg. Was und wieso es passiert - ein große Geheimnis für mich.

 

[asci25]

Wir haben die ganze Zeit über Bausteine gesprochen, die persistente Variablen schreiben und jetzt habe wir auf einmal Retain-Variablen?
Retain funktioniert anders. Ich weiß gerade nicht, ob Retain-Vars überhaupt auf einem CX8090 funktionieren. Wahrscheinlich ist bei Variable ABC 15.0 nur der Startwert.

 

[Guga]

Retain werden in TC2 genauso wie persistent in einer Datei abgebildet. Wenn eine Variable RETAIN und PERSISTENT deklariert wird hat der Wert in der Persistent-Datei die Prio. Retain - Daten werden ausschliesslich über das System beim Shutdown geschrieben. Es gibt keinen Baustein um das anzutriggern.
Letztendlich ist ein benutzergetriggert Shutdown mit dem SUps-Baustein (TcSystemCX80xx.lib) immer zu empfehlen wenn das Gerät eine 1-S USV hat.

Ich könnte jetzt die Dateinamen aufführen wo Retain bzw. Persistent gespeichert wird. Nur sind diese binär codiert und nur schwer den entsprechenden Variablen zuzuordnen.