TIA Eigener Betriebsstundenzähler

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

DINT im Sekundentakt sind so ca. 68 Jahre, nimmst du ein LINT sind es 292 Milliarden Jahre - also quasi ein fucking Erdzeitalter...

Also ist es doch das einfachste, mittels TIME_TCK den Ablauf einer Sekunden zu berechnen und diese dann in einem LINT zu inkrementieren. Davon kann man dann ableiten was man braucht oder was an ein Fremdsystem weiter gegeben werden muss.

Alternativ kann man natürlich auch RUNTIME benutzen und die Zykluszeit auf µs oder ns runden.

 

[Richard P.]

Alternativ kann man natürlich auch RUNTIME benutzen und die Zykluszeit auf µs oder ns runden.

Runden? Besser man addiert die Zykluszeiten in LReal und macht bei vollen Zeiteinheiten einen Übertrag auf ein DINT oder LINT.

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Runden? Besser man addiert die Zykluszeiten in LReal und macht bei vollen Zeiteinheiten einen Übertrag auf ein DINT oder LINT.

Summen erfassen mit Gleitpunktzahlen mache ich aus Prinzip nie.

 

[Larry Laffer]

@Richard P. : du bist anscheinend noch nie über die Tücken der Realzahlen (gilt genauso auch für LReal) gestolpert ... vielleicht solltest du dir mal anschauen wie die von der Struktur her aufgebaut ist ...

 

[Mok_1988]

Wenn es doch nicht reicht, kann ich immer noch bei jedem Überlauf des ULInt einen zweiten ULInt inkrementieren (⁠◠⁠‿⁠・⁠)⁠—⁠☆

Dazu fällt mir ein: Chuck Norris hat bis Unendlich gezählt – zweimal ;-)

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Summen erfassen mit Gleitpunktzahlen mache ich aus Prinzip nie.

hmm, wie verträgt sich das mit dem Vorschlag?

Also ist es doch das einfachste, mittels TIME_TCK den Ablauf einer Sekunden zu berechnen und diese dann in einem LINT zu inkrementieren. Davon kann man dann ableiten was man braucht oder was an ein Fremdsystem weiter gegeben werden muss.

Alternativ kann man natürlich auch RUNTIME benutzen und die Zykluszeit auf µs oder ns runden.

Das wäre eine schlechte Idee, weil man gerade dann Rundungsfehler erzeugt, die sich aufsummieren könnten.
TIME_TCK arbeitet durchgehend mit Ganzzahlen, da gibt es keine Rundungsfehler. Und das Addieren von OB1_PREV_CYCLE (Ganzzahl ms) sollte ebenso keine Rundungsfehler kumulieren. Oder Siemens trickst da irgendwas unerwartetes, um aus einer internen Zeitmess-Auflösung von Mikrosekunden (oder gar vorgeblich Nanosekunden LTIME) auf Millisekunden für OB1_PREV_CYCLE zu kommen.

Übrigens: OB1_PREV_CYCLE gibt es bei S7-1x00 nur, wenn der OB1 mit Standard-Zugriff eingestellt ist. Wenn der OB1 "optimiert" eingestellt ist, dann kann man bei S7-1500 ab V1.7 die Anweisung RT_INFO Mode 25 (Dauer des letzten Zyklus, wie in "Online & Diagnose" angezeigt) verwenden, das liefert LTIME (ns). Da weiß ich allerdings nicht, ob/wie da evtl. gerundet wird.

 

[Richard P.]

@Richard P. ... vielleicht solltest du dir mal anschauen wie die von der Struktur her aufgebaut ist ...

.. Das wäre eine schlechte Idee, weil man gerade dann Rundungsfehler erzeugt, die sich aufsummieren könnten...

Natürlich gibt es Rundungsfehler. Diese sind gegenüber 32Bit jedoch verschwindend gering. Siemens verwendet übrigens LReal als Zählerstand bei den Sentron-PAC. Und das auch noch in WS, wenn ich nicht irre.

Oder kommt es zu gar keinen Rundungsfehlern, so lange die Dezimalstellen des LReal ausreichen? Larry?

Wenn man die Genauigkeit einer 64Bit Realzahl hat, und nach einer Zeit x einen Übertrag auf Integer vornimmt, dann erreicht man eine sehr hohe Genauigkeit. Ich habe mal eben gerade, nach meinem Larry zu verdankenen Chrashkurs in Datenformaten, auf einer S7-1512SP einen Test laufen lassen. Ich habe auf verschiedene Art und Weise eine Zeitspanne von 1 Stunde gemessen. Referenz war hierbei die Uhrzeit der CPU. Die mit RUNTIME ermittelte Zeit von Start bis Stopp, wie auch die Summe der mit RUNTIME ermittelten 1.456.678 OB1-Zyklen lag, gewandelt nach TIME, bei jeweils T#1H.

Seltsamerweise habe ich, warum auch immer, mit der einfachensten PREV-CYCLE-Variante ein Problem. Dieser Zähler hängt den anderen massiv hinterher, zählt also zu wenig. Pro Minute verliert er ca. 9s.

 

[Oberchefe]

Ich habe mal einen kurzen Trace gemacht und den OB1_PREV_CYCLE mit der Differenz von einem RD_SYS_T zum vorherigen RD_SYS_T verglichen. Der OB1_PREV_CYCLE enthält offensichtlich die reine Codeabarbeitungszeit vom OB1. OB1 Unterbrechungen durch andere OBs wie z. B. MC-Servo werden scheinbar nicht mitgezählt.

 

[mgl]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dazu fällt mir ein: Chuck Norris hat bis Unendlich gezählt – zweimal ;-)

und mit allen Nachkommastellen ;-)


Wie viele vor mir, lehne ich Gleitkomma-Zahlen ebenfalls für Zähler ab. Das hat nicht nur den Rundungsfehler-Hintergrund sondern auch mit der Performance zu tun. Ganzzahloperationen sind einfach schneller. Und mit einer 1512 SPS kann man die Zykluszeit schon schnell in Regionen bringen die jenseits von Gut und Böse sind.

Wenn man die Genauigkeit einer 64Bit Realzahl hat, und nach einer Zeit x einen Übertrag auf Integer vornimmt, dann erreicht man eine sehr hohe Genauigkeit.

Man kann natürlich viel programmieren aber man beachte auch das KISS-Prinzip (Keep it stupid simple) um die ganze Geschichte wartbar und für andere Verständlich zu halten. Also kurz gesagt: Einfacher ist besser.

 

[Botimperator]

Ich habe mal einen kurzen Trace gemacht und den OB1_PREV_CYCLE mit der Differenz von einem RD_SYS_T zum vorherigen RD_SYS_T verglichen. Der OB1_PREV_CYCLE enthält offensichtlich die reine Codeabarbeitungszeit vom OB1. OB1 Unterbrechungen durch andere OBs wie z. B. MC-Servo werden scheinbar nicht mitgezählt.

Sowas hatte ich mir schon gedacht.
Mit was genau hast du getestet?

 

[Oberchefe]

1518T-4 PN/DP

 

[Richard P.]

Zuviel Werbung?
-> Hier kostenlos registrieren

... Performance ...

Nicht dein Ernst?

... Man kann natürlich viel programmieren aber man beachte auch das KISS-Prinzip (Keep it stupid simple) um die ganze Geschichte wartbar und für andere Verständlich zu halten. Also kurz gesagt: Einfacher ist besser.

In welchen Bausteinen willst du solche Konstrukte denn einsetzen? In Anlagenbausteinen oder in bibliotheksfähigen Standardbausteinen?
Was wäre für dich denn die einfachere und bessere Lösung?

 

[Richard P.]

Seltsamerweise habe ich, warum auch immer, mit der einfachensten PREV-CYCLE-Variante ein Problem. Dieser Zähler hängt den anderen massiv hinterher, zählt also zu wenig. Pro Minute verliert er ca. 9s.

Hierzu muss ich noch etwas ergänzen. Das beschriebene Problem hatte ich bei einer Zykluszeit von ca. 2ms mit einigen wenigen Zyklen bis ca. 5ms. Mit einer Mindestzykluszeit von 20ms relativiert es sich. Bei einer Laufzeit von 1h habe ich nur noch insgesamt ca. 8s Abweichung.

 

[PN/DP]

Ich habe mal einen kurzen Trace gemacht und den OB1_PREV_CYCLE mit der Differenz von einem RD_SYS_T zum vorherigen RD_SYS_T verglichen. Der OB1_PREV_CYCLE enthält offensichtlich die reine Codeabarbeitungszeit vom OB1. OB1 Unterbrechungen durch andere OBs wie z. B. MC-Servo werden scheinbar nicht mitgezählt.

Hast du zufällig auch mal verglichen mit der Zykluszeit-Angabe von RT_INFO Mode 25 ?

Wenn der OB1 "optimiert" eingestellt ist, dann kann man bei S7-1500 ab V1.7 die Anweisung RT_INFO Mode 25 (Dauer des letzten Zyklus, wie in "Online & Diagnose" angezeigt) verwenden, das liefert LTIME (ns). Da weiß ich allerdings nicht, ob/wie da evtl. gerundet wird.

Möglicherweise hat Siemens die "Legacy-Emulation" des OB1_PREV_CYCLE für S7-1200/1500 nicht ganz kompatibel umgesetzt und man müsste bei S7-1500 die Anweisung RT_INFO Mode 25 verwenden. (Oder selbst mit TIME_TCK berechnen)