Verlängerung der Zykluszeit durch Bausteinaktualisierung

a34088

Level-1
Beiträge
3
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo!

Meine Umgebung: CPU-315F-2PN/DP, Firmware V3.2.3; STEP 7 V5.5.

Ich habe das Phänomen, dass sich nach einer Aktualisierung eines Großteils der Bausteine (OBs, FBs, FCs, DBs) die Zykluszeit um ca. 30% verlängert (sonst keinerlei Änderung).

Ich halte die CPU vor der Aktualisierung mittels SIMATIC Manager an (STOP) und starte sie nach der Aktualisierung wieder (RUN).

Nach einem NETZ-AUS/EIN verschwindet diese Zykluszeitverlängerung wieder und alles läuft wie vorher.

Das Ganze ist reproduzierbar. Führe ich wieder eine Aktualisierung der Bausteine durch (ohne irgendeine Änderung im Programmcode), verlängert sich die Zykluszeit.

Ob die Zykluszeitverlängerung proportional zur Anzahl der aktualisierten Bausteine ist, habe ich nicht versucht.

Hat jemand eine Ahnung, woran das liegen könnte?

Vielen Dank im Voraus!

Alex
 
Vielleicht ist es nur ein Anzeigeproblem. Mit der neusten Generation von CPU's traue ich BigS alles zu!

Wie hast Du die Zykluszeit ausgelesen? Aus dem OB1 Lokaldaten oder nur über die Software "Baugruppenzustand"?

Alternativ könntest Du die Zykluszeit mal mit demSFC64 (TIME_TCK, inkrementiert unabhängig von der Zykluszeit im 1ms-Takt) messen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
hallo !

Vermutung:

bei einem Neuladen eines oder mehrer Bausteine werden diese zur CPU in einen freien Speicherbereich übertragen, der alte Speicherbereich/Baustein in der CPU wird nur für ungültig erklärt.

Kann es sein, das bei einem Aufruf eines aktualisierten Bausteins zunächst die "alte"/vormalige Speicheradresse angesprungen wird und dort dann der Verweis auf den neuen Speicherbereich zum aktualisierten Baustein gelesen wird ?

Nach einem "Komprimieren" ist dieses Phänomen wahrscheinlich auch verschwunden, weil damit der Speicher "aufgeräumt" wurde... <TEST ?>

Gruss
 
Ich habe das Phänomen, dass sich nach einer Aktualisierung eines Großteils der Bausteine (OBs, FBs, FCs, DBs) die Zykluszeit um ca. 30% verlängert (sonst keinerlei Änderung).
Hallo Alex,

- was meinst Du mit "Aktualisierung der Bausteine"?
Erneutes Laden der Bausteine in die CPU?

- was meinst Du mit "nach" einer Aktualisierung der Bausteine?
Erhöht sich die Zykluszeit bleibend oder siehst Du nur im Baugruppenzustand, daß die längste aufgetretene Zykluszeit danach ca. 30% höher angezeigt wird als die aktuelle/letzte bzw. in Deinem Programm übliche Zykluszeit?

Nach einem NETZ-AUS/EIN verschwindet diese Zykluszeitverlängerung wieder und alles läuft wie vorher.
Falls Du die angezeigten Zykluszeiten im Baugruppenzustand meinst:
Bei jedem STOP/RUN-Übergang wird einfach nur die Statistik der Zykluszeiten gelöscht und neu begonnen.

Meine Umgebung: CPU-315F-2PN/DP, Firmware V3.2.3; STEP 7 V5.5.
Früher konnte man in den Eigenschaften der CPU auf "Prozeßbetrieb" umstellen und festlegen, wie hoch die Zykluszeiterhöhung durch PG-Aktivitäten maximal werden darf.
Hilft Dir aber nichts, denn bei S7-300 CPU ab Firmwarestand V3.0 meint Siemens, daß sowas nicht mehr benötigt wird ...

Hast Du ein Sicherheitsprogramm in der CPU?
Beeinflußt diese Zykluszeiterhöhung irgendwie Deinen Prozeß?
Um welche absolute Zykluszeit geht es bei Dir? Von 3ms zu 4ms? Das sind auch ca. 30%, kann man aber bestimmt nicht verhindern.

Eventuell hilft es bei Deiner CPU, wenn Du die Bausteine einzeln lädst statt im Block?

Harald
 
Hallo,

vielen Dank schon mal für die Antworten.

Ja, mit "Aktualisierung" meine ich erneutes Laden der Bausteine auf die CPU.

Mit Erhöhung der Zykluszeit nach der "Aktualisierung" meine ich eine dauerhafte Erhöhung der Zykluszeit, die erst nach einem NETZ AUS/EIN wieder verschwindet.

Ich lese die Zykluszeit aus den Lokaldaten des OB1 und bilde über 5 Zyklen einen Durchschnittswert, den ich mir dann anzeigen lasse.

Die Zykluszeit ändert sich dauerhaft und reproduzierbar von ca. 10/11ms auf 13/14ms.

Die Zykluszeiterhöhung beeinflusst den Prozess insofern, als ein per TCP/IP angebundener Scanner zu langsam bedient wird. Bei 10/11 ms kein Problem, bei 13/14 ms gehen einzelne Messungen verloren.

Ein Sicherheitsprogramm habe ich nicht auf der CPU.

Was das einzelne Laden von Bausteinen betrifft, habe ich den Eindruck, dass das Problem mit der Zeit ebenfalls auftritt, sobald halt eine gewisse Anzahl von Bausteinen/Ladevorgängen durchgeführt wurde.

Mein Verdacht ging in Richtung des von SoftMachine geäußerten, dass die Bausteinadressen irgendwie "umgebogen" werden und sich dadurch die Zugriffszeit darauf erhöht. Für dieses Verhalten habe ich allerdings in keinerlei Dokumentation einen Hinweis gefunden.

"Komprimieren" habe ich noch nicht versucht, werde ich aber beim nächsten Erreichen eines solchen Zustands probieren.

Alex
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mit Erhöhung der Zykluszeit nach der "Aktualisierung" meine ich eine dauerhafte Erhöhung der Zykluszeit, die erst nach einem NETZ AUS/EIN wieder verschwindet.
Passiert die Zykluszeiterhöhung nur, wenn bei dem Bausteine-Laden DB enthalten sind, oder auch, wenn es nur Programmbausteine sind (nur OB/FB/FC)?

Die Zykluszeiterhöhung beeinflusst den Prozess insofern, als ein per TCP/IP angebundener Scanner zu langsam bedient wird. Bei 10/11 ms kein Problem, bei 13/14 ms gehen einzelne Messungen verloren.
Hmm, das erscheint mir bedenklich. Ich weiß nicht, was für einen Scanner Du benutzt und ob die Meßwerte tatsächlich sooo schnell kommen müssen, doch gibt es keinen Handshake mit dem Scanner? Wie "sprichst" Du mit dem Scanner? Über die PN-Schnittstelle oder einen CP? Welche Kommunikationsbausteine benutzt Du? Manche Kommunikationsbausteine vertragen es nicht gut, wenn die aufrufenden Bausteine im RUN übertragen werden. Könntest Du den Scanner auch per PN-IO anbinden?

Ich würde zuerst die Ursache des Problems in meinem Programm suchen. Ob vielleicht die offline-DB-Aktualwerte ungünstig vorbelegt sind und deshalb das Programm massiv andere Programmzweige durchläuft als nach einem STOP/RUN-Übergang, wo das Programm eventuell über einen Anlaufmerker oder OB100 Variablen "passend" initialisiert.
Wenn FB und Instanz-DB bei dem Nachladen enthalten sind, dann unbedingt vorher eine Konsistenzprüfung machen und ggf. die IDB neu generieren lassen und mit übertragen (wenn das Programm das Initialisieren der Instanz-Variablen auf die Anfangswerte verträgt).

Wenn Siemens keine ganz große Scheixxe in der Firmware gemacht hat, dann gibt es keine aktueller-Baustein-Pointer-"Ketten" nach dem Laden von Bausteinen. Beim Laden eines Bausteins wird dieser zunächst in einen freien Bereich das Arbeitsspeichers geladen und dann im Zykluskontrollpunkt sollte die Adresse des geladenen Bausteins in die Baustein-Adressliste eingetragen und dabei die Adresse des alten vorhandenen Bausteins überschrieben werden. Dadurch kann es nicht zu Zykluszeiterhöhungen kommen. Ein "Komprimieren" sollte die Zykluszeit ebenfalls nicht beeinflussen.

Andererseits hat Siemens für die CPU 6ES7315-2FJ14-0AB0 schon Firmware-Updates wegen haarsträubenden Fehlern gemacht. Ein klein wenig traue ich Siemens auch zu, daß der Grund für Dein Problem in der Firmware liegt.

Wenn Du ziemlich sicher ausschließen kannst, daß die Zykluszeiterhöhung nicht an Deinem Programm liegt, dann ist das eigentlich ein klarer Fall für die Siemens Hotline. Ruf da mal an oder mache einen Service Request.

Wenn Du mit der CPU ein bischen testen kannst, dann lade mal ein Programm, was nichts weiter macht, als in einer Schleife Zykluszeit zu verbraten. Kannst Du dann auch Dein Problem beobachten?

(meine vielen Fragen sind als Analyse-Hinweis gedacht, die mußt Du nicht alle beantworten)

Harald
 
Hallo,

danke für die Hinweise.

Passiert die Zykluszeiterhöhung nur, wenn bei dem Bausteine-Laden DB enthalten sind, oder auch, wenn es nur Programmbausteine sind (nur OB/FB/FC)?
Kann ich nicht sagen, habe ich bisher nicht versucht. Da die Anlage schon in Betrieb ist, ist es auch nicht mehr so einfach mit solchen Versuchen.

Hmm, das erscheint mir bedenklich. Ich weiß nicht, was für einen Scanner Du benutzt und ob die Meßwerte tatsächlich sooo schnell kommen müssen, doch gibt es keinen Handshake mit dem Scanner? Wie "sprichst" Du mit dem Scanner? Über die PN-Schnittstelle oder einen CP? Welche Kommunikationsbausteine benutzt Du? Manche Kommunikationsbausteine vertragen es nicht gut, wenn die aufrufenden Bausteine im RUN übertragen werden. Könntest Du den Scanner auch per PN-IO anbinden?
Der Scanner sendet via Ethernet (TCP) alle 40 ms ein Datenpaket mit ca. 2-4 KB Daten. Angebunden ist der Scanner über die PN-Schnittstelle. Die Kommunikation erfolgt über TCON/TDISCON/TSEND/TRCV. Funktioniert bis auf die Zykluszeitverlängerung nach Neuladen bis zum nächsten NETZ-EIN/AUS soweit alles tadellos ...

Ich übertrage die Bausteine immer im STOP, um das Problem des "Nichtvertragens" der Kommunikationsbausteine bei Übertragung im RUN zu umgehen.

Ich würde zuerst die Ursache des Problems in meinem Programm suchen. Ob vielleicht die offline-DB-Aktualwerte ungünstig vorbelegt sind und deshalb das Programm massiv andere Programmzweige durchläuft als nach einem STOP/RUN-Übergang, wo das Programm eventuell über einen Anlaufmerker oder OB100 Variablen "passend" initialisiert.
Wenn FB und Instanz-DB bei dem Nachladen enthalten sind, dann unbedingt vorher eine Konsistenzprüfung machen und ggf. die IDB neu generieren lassen und mit übertragen (wenn das Programm das Initialisieren der Instanz-Variablen auf die Anfangswerte verträgt).
Habe ich eigentlich schon alles mehrfach gecheckt. Auch Konsistenzprüfung und Neuübersetzung mache ich immer.

Wenn Du ziemlich sicher ausschließen kannst, daß die Zykluszeiterhöhung nicht an Deinem Programm liegt, dann ist das eigentlich ein klarer Fall für die Siemens Hotline. Ruf da mal an oder mache einen Service Request.
Werde ich dann wohl als nächstes versuchen ...

Alex
 
Zurück
Oben