TIA Eigener Betriebsstundenzähler

[Toyoraner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe mir vor einigen Jahren einen Betriebstundenzähler gebastelt für Aggregate z.B. Motoren aber auch um z.Bsp. Laufzeiten von Prozessen zu überwachen. Dieser gibt einmal die Zeit im Timeformat aus und die reinen Stunden als DINT. Dies habe ich nach der oft empfohlen Methode des Aufsummieren der OB1-Prev-Cycletime getan, ich denke die meisten wissen was ich meine.

Nun habe ich durch einen Zufall bemerkt
das die Zeit mit der wirklich vergangenen Zeit nicht übereinstimmt.Das ganze mit Stoppuhr verifiziert und ja, mein Betriebsstundenzähler geht nach sprich läuft langsamer.Warum ist dies nicht eher so aufgefallen?!Nun, wir setzen die ET200SP CPUs ein und bis vor Kurzem waren Zykluszeiten von 10-15ms normal an unseren Anlagen.Mit den letzten Upgrades sind die CPUs deutlich schneller geworden und die Zykluszeit ist auf 1ms gesunken. Da die Zykluszeit in MS ganzzahlig aufsummiert wird und diese nie genau 1 ist sondern eher einige Microsekunden länger also so 1,023 oder so(kann man ja beobachten in Online&Diagnose) "fehlt" dort natürlich etwas in der Summe und das ist dann so viel das tatsächlich pro Minute ca. 2s fehlen.

Setzt man die Zykluszeit mal auf mindestens 10ms in der Hardwarekonfiguration wird der Fehler kleiner, ungefähr 1s in 5min. Daher ist er früher nicht direkt aufgefallen.

Ich habe mir nun einen neuen Baustein geschrieben, der intern mit der TONR-Funktion einfach die Zeit akkumuliert im LTime Format.Damit sind theoretisch über 200 Jahre möglich. Die Stunden rechne ich mir einfach durch Umwandlung und Division aus, da die Zeit im LTime quasi in Nanosekunden vorliegt.


Habt ihr das Phänomen schon bemerkt?Welche Lösungen habt ihr gefunden?Das würde mich interessieren.

 

[Larry Laffer]

Ich habe mir auch irgendwann einmal soetwas "gebastelt" - ich hatte mir jeweils beim Start des Aggregates (oder was auch immer) die Systemzeit (also TOD) gespeichert und die dann beim Stop des Aggregates von der aktuellen TOD subtrahiert. Selbstverständlich habe ich einen 0 Uhr-Übergang auch mit berücksichtigt.Das was auf alle Fälle genau ... ob dein TONR das in gleicher Weise ist vermag ich nicht einzuschätzen - ich könnte mir aber auch bei dem einen Zykluszeit-Einfluß vorstellen ...

 

[TheLevel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich benutze den Taktmerker 1Hz und zähle die Takte, alle 6 Minuten wird eine DINT um +1 erhöht und zeigt mir somit die Betriebsstunden mit einer Nachkommastelle an. Ich habe die Genauigkeit nie geprüft, aber auch keine hohe Anforderung diesbezüglich.

 

[Larry Laffer]

@TheLevel : wenn du da mit der Stopuhr dran gehst dann wirst du auf mittlere Sicht auch einen Zykluszeit-Einfluß feststellen können. Aber klar - es ist halt eine Frage wie genau es sein soll ...

 

[Botimperator]

Kenne ich durchaus.
In jedem Zyklus zu summieren schleppt dir halt bei jeder Operation die betreffenden Rundungsfehler mit.

Das mit TONR funktioniert durchaus.
Ich benutze für die Erfassung von Zeitabständen meistens TIME_TCK, womit ich Start und End-Zeitstempel ermittle & dann nur bei jedem Start/Stop oder überlauf eine Berechnung (incl. Rundungsfehler) mache.

Ältere meiner Programme verwenden auch durchaus die Lösung über das Taktmerkerbyte, ähnlich wie es @TheLevel umsetzt.
Das erfordert allerdings ein korrekt konfiguriertes Merkerbyte, was die Sache hardwareabhängig macht & Raum für Fehler eröffnet.
Wie genau die die Taktmerker tatsächlich laufen kann ich dir aber tatsächlich leider auch nicht sagen.
Genau genug für meine Zwecke ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

@TheLevel : wenn du da mit der Stopuhr dran gehst dann wirst du auf mittlere Sicht auch einen Zykluszeit-Einfluß feststellen können. Aber klar - es ist halt eine Frage wie genau es sein soll ...

Weißt du wie viel diese abweichen?
Mein Stand war, dass die Taktmerker, genau wie TIME_TCK, vom Programm unabhängig laufen. Also letzten Endes von der Genauigkeit der Echtzeituhr der SPS abhängen (wie in den Datenblättern angegeben).

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Weißt du wie viel diese abweichen?
Mein Stand war, dass die Taktmerker, genau wie TIME_TCK, vom Programm unabhängig laufen. Also letzten Endes von der Genauigkeit der Echtzeituhr der SPS abhängen (wie in den Datenblättern angegeben).

So kenne ich es auch - aber auch da kann ja, wie du es schon schreibst, wiederum die Zykluszeit der Auswertung mit hineinspielen. Es ist aber sicherlich viiiiel genauer wie das Aufaddieren einer OB1-Zykluszeit ... (selbst wenn die viel größer als 1 ms ist)

 

[PN/DP]

Nun habe ich durch einen Zufall bemerkt
das die Zeit mit der wirklich vergangenen Zeit nicht übereinstimmt.Das ganze mit Stoppuhr verifiziert und ja, mein Betriebsstundenzähler geht nach sprich läuft langsamer.

Mit genau welcher CPU und Firmware hast du das festgestellt? Wie sieht dein Code zum Aufsummieren des OB1_PREV_CYCLE aus?
Vor vielen Jahren hatte ich das mal mit einer S7-300 ausführlich getestet und festgestellt, dass die Millisekunden-Bruchteile nicht verloren gehen und kein Rundungsfehler aufsummiert wird. Was logisch ist, wenn die OB1_PREV_CYCLE als Differenz vom (fortlaufenden) Systemzeitgeber gebildet wird (siehe SFC64 TIME_TCK). Das Aufsummieren des OB1_PREV_CYCLE ist damit genauer als das Zählen des 1Hz-System-Taktmerkers, wo je Schaltspiel im Durchschnitt ca 0.5s verloren gehen.

Hier ein Beispiel für eine Zeiterfassung mit OB1_PREV_CYCLE in AWL. Im letzten Netzwerk "Info: Calculate time duration..."

 

[PN/DP]

TIA Beitrag im Thema 'Stoppuhr S7 TIA Portal'

19 März 2015

Wie genau ist das mit OB1_PREV_CYCLE ? Ich hab mal gehört das die ms nicht gerundet werden sondern abgeschnitten und zum nächsten Zyklus addiert werden.

Jepp, genau deshalb kann man die Zeiten des OB1_PREV_CYCLE addieren, ohne daß sich Rundungsfehler aufsummieren.
Das fortlaufende Addieren von OB1_PREV_CYCLE kommt auf das selbe Ergebnis wie die Differenzberechnung per SFC64 (von alten CPU abgesehen, wo der SFC64 nur 10ms Auflösung hat). Die Variante mit dem TON-Timer funktioniert ebenfalls so genau, allerdings genau 1 OB1-Zykluszeit zu kurz, was man aber leicht korrigieren kann.

Harald

• PN/DP

 

[Toyoraner]

Zuviel Werbung?
-> Hier kostenlos registrieren

6ES7510-1DK03-0AB0, Firmware kann ich nicht sagen, arbeite aber mit TIA V20 und bilde mir ein die Aktuellste zu haben on/offline.

Na ja der Code ist ja simpel, einfach die prev_cycle_time + gespeicherter Wert = neuer gespeicherter wert und dann über T-Convert DINT in Time wandeln. Den OB1 prevcycle kopiere ich natürlich im 1.NW aus dessen TEMP Bereich in einen Global-DB.

Fakt ist die Zykluszeit schwankt.Prev Cycle wird als ganzzahliger Wert zur Verfügung gestellt. Wenn er also intern nicht gerundet wird, sondern der Übertrag zum nächsten addiert wird und ich sag Mal gesponnen jeder Zyklus ist 1,1ms lang, dann ist jeder 11
. Prev_Cycle_Wert 2ms?

 

[Botimperator]

Fakt ist die Zykluszeit schwankt.Prev Cycle wird als ganzzahliger Wert zur Verfügung gestellt. Wenn er also intern nicht gerundet wird, sondern der Übertrag zum nächsten addiert wird und ich sag Mal gesponnen jeder Zyklus ist 1,1ms lang, dann ist jeder 11
. Prev_Cycle_Wert 2ms?

Soweit ich weiß wird PervCycle durch den Vergleich des Start- und End-Zeitstempels des Zyklus gebildet & ggf. aufgrund der Genauigkeit des Datenformats gerundet oder abgeschnitten (da bin ich mir tatsächlich nicht ganz sicher).
Als Zeitquelle dient die Echtzeituhr der SPS.
Die fehlenden Nachkommastellen führen dann zu deiner im Eröffnungspost erwähnten Abweichung (die müssen ja irgendwo her kommen).
Wenn die SPS den "Rest" für die Addition in folgenden Zyklen mitführen würde, hättest du die genannte Abweichung nicht.

Der Beitrag von @PN/DP bezieht sich auf eine 300er SPS. War das damals vllt noch anders?
Das Zeithandling war in den 300er ja generell nicht ganz so präzise wie in den neueren Steuerungen, weshalb eine Korrektur der ausgegebenen Zykluszeit im Hintergrund für mich jetzt nicht unplausibel klingt.
Finde leider keine Angabe von Siemens wie genau sich der Umgang mit Ungenauigkeiten verhält.
=> Meinem Analyse-Monk juckt es in den Fingern, dass er das nicht schlüssig beantworten kann ರ⁠╭⁠╮⁠ರ

 

[Cassandra]

Ich benutze den Taktmerker 1Hz und zähle die Takte, alle 6 Minuten wird eine DINT um +1 erhöht und zeigt mir somit die Betriebsstunden mit einer Nachkommastelle an. Ich habe die Genauigkeit nie geprüft, aber auch keine hohe Anforderung diesbezüglich.

Um Himmels willen – das ist ja viel zu einfach! So kann ja am Ende jeder Anfänger mitreden. Wo bleibt denn da die intellektuelle Herausforderung? Die modernen Steuerungen werden nicht einmal ansatzweise ausgereizt, und die Wahrscheinlichkeit, dass man später ein heroisches Bugfix liefern darf, geht gegen null!

 

[Richard P.]

Zuviel Werbung?
-> Hier kostenlos registrieren

Findest du? Die meisten Anfänger scheitern doch schon an der Impulsbildung.

 

[Botimperator]

Um Himmels willen – das ist ja viel zu einfach! So kann ja am Ende jeder Anfänger mitreden. Wo bleibt denn da die intellektuelle Herausforderung? Die modernen Steuerungen werden nicht einmal ansatzweise ausgereizt, und die Wahrscheinlichkeit, dass man später ein heroisches Bugfix liefern darf, geht gegen null!

Die heroischen Momente sind wichtig für die Charakterpflege (⁠◠⁠‿⁠・⁠)⁠—⁠☆

Außerdem finde ich Betriebsstundenzähler ein tolles Thema um Azubis was zum Denken zu geben.
Eigentlich einfaches Thema, dass im Grundsatz geder versteht, mit vielen, netten Fallstricken (⁠~⁠￣⁠³⁠￣⁠)⁠~
Wie einfach kann es sein?
Wie kompliziert muss es sein?
Wie gehe ich mit Ungenauigkeiten in Werten um, von denen ich eigentlich erwarte, dass sie genau sind?
Was passiert bei überläufen und wie gehe ich damit um?
Was mach ich wenn die SPS neu startet (speziell bei den Zählern die ihren Wert nicht in jedem Zyklus neu berechnen)?
Wie optimiere ich die notwendigen Rechenleistung und den Datenverbrauch?
Wie gehe ich mit Initialisierungen von DBs um, um den Verlust von Zählwerten zu verhindern?
Einfache Darstellung am HMI oder externen Standardschnittstellen?
Usw...

Ein tolles Thema um zum Denken anzuregen

 

[DeaD_EyE]

Wenn es darum geht Automatisierung zu lernen, finde ich den Ansatz mit dem 1 Hz Taktmerker pragmatisch.
Der Ansatz alle 6 Minuten einen DInt um 1 zu erhöhen, damit man eine Stelle hinter dem Komma hat, verhindert auch Probleme mit Gleitkommazahlen.

Rein theoretisch könnte man auch mit einer Genauigkeit mit 1 ns arbeiten, falls der RTC überhaupt diese Auflösung hat.
Dann könnte man aber nur ~584 Jahre erfassen.
(2**64-1) * 1e-9 / 3600 / 24 / 365

Mit Gleitkommazahlen geht es auch, aber dann hat man noch die Ungenauigkeit der Gleitkommazahlen. Besonders ungenau wird es, wenn man arithmetische Operationen mit großen und sehr kleinen Zahlen durchführt. Und den Klassiker kennt jeder:

import webbrowser


webbrowser.open(f"https://{0.2+0.1}.com")

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe in der Vergangenheit einfach den 1 Hz Taktmerker benutzt und mit jeder Flanke einen DINT-Wert um 1 erhöht. Das gehg vorzeichenrichtig bis 63 Jahre. Wenn eine Maschine mit SPS länger lebt dann gratuliere ich.
Die Anzeigen am HMI waren dann entsprechend umgerechnet.

 

[Stadtranduser]

Dann könnte man aber nur ~584 Jahre erfassen.

Das könnte bei der Gewährleistung problematisch sein .

 

[Botimperator]

Das könnte bei der Gewährleistung problematisch sein .

Deswegen mitdenken & die Stunden als ULint aufsummieren.
Wenn der Überlauf dann irgendwann tatsächlich mein persönliches Problem werden sollte bin ich bereit mein Schicksal zu akzeptieren.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Poah - ihr seid ja drauf ...
Ich glaube nicht, dass die schönen neuen S7-Module die Lebensspanne der guten alten S5 oder auch der ersten S7 auch nur ansatzweise erreichen werden. Von daher ... @Botimperator : keine Bange

 

[Botimperator]

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

 

[Lars Weiß]

Ich habe in der Vergangenheit einfach den 1 Hz Taktmerker benutzt und mit jeder Flanke einen DINT-Wert um 1 erhöht. Das gehg vorzeichenrichtig bis 63 Jahre. Wenn eine Maschine mit SPS länger lebt dann gratuliere ich.
Die Anzeigen am HMI waren dann entsprechend umgerechnet.

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.