TIA Eigener Betriebsstundenzähler

Zuviel Werbung?
-> Hier kostenlos registrieren
Toyoraner schrieb:
RT_INFO Mode 25 statt OB1 nehme ich auf S7-1200, weil es da den OB1 Prevcycle nicht gibt.
Auch dort gibt es Ungenauigkeiten.
Zum Vergrößern anklicken....
Kann man fertigem ungenau dokumentiertem Siemens Code generell nicht (mehr) trauen? Muss man wirklich alles genau testen und dann doch selber programmieren, um sicher zu sein, dass es wirklich 100% funktioniert? :rolleyes:

Betriebsstundenzähler kann man wohl am einfachsten mit Zählen des 1Hz-Systemtakts realisieren, auch wenn da je Schaltspiel durchschnittlich 0.5s zu wenig gezählt wird. Doch bei Betriebsstundenzählern von Aggregaten (mit nicht häufigen Schaltspielen) kommt es auf diese kleine Abweichung meistens nicht drauf an.

Interessehalber: Ab welcher Firmware-Version und TIA-Version gibt es RT_INFO bei S7-1200?

Wie können Sie für S7-1200/S7-1500 die Laufzeiten des gesamten Programms, von Teilprogrammen oder von bestimmten Organisationsbausteinen messen?
 
Habe heute Traces gemacht im Vergleich zu RT_INFO in Mode 1 und 25. Der OB1_PREV_CYCLE passt noch am ehesten zu Mode 1 von RT_INFO. RUNTIME scheint mir noch das realistischste Ergebnis zu liefern, vergleichbar zur selbst gebauten Differenz von RD_SYS_T. OB1_PREV_CYCLE liefert gerundete 2ms bei irgendwelchen 1.8ms von RUNTIME oder RD_SYS_T.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
mgl schrieb:
... Ich sehe das nicht als kompliziert an, wenn man das etwas in seinem Programm kommentiert...
Zum Vergrößern anklicken....
Angesichts dessen, dass man den Code eigentlich gar nicht braucht, ist er kompliziert genug.

Toyoraner schrieb:
... RT_INFO Mode 25 statt OB1 nehme ich auf S7-1200, weil es da den OB1 Prevcycle nicht gibt...
Zum Vergrößern anklicken....
Wäre eine Lösung, die auf beiden Systemen funktioniert, nicht die bessere Wahl?
Es wurden doch schon verschiedene Ansätze genannt. Zu welcher Lösung kommst du denn?

So wie du in #1 dein Problem beschrieben hast, hapert es ja eigentlich nur an der Messung einer möglichst exakten Zykluszeit.
Versuche es doch mal hiermit:
Code: 
#PREV_CYCLE := RUNTIME(#CYCLE_MEMORY);
 
Zuletzt bearbeitet:
Richard P. schrieb:
Angesichts dessen, dass man den Code eigentlich gar nicht braucht, ist er kompliziert genug.


Wäre eine Lösung, die auf beiden Systemen funktioniert, nicht die bessere Wahl?
Es wurden doch schon verschiedene Ansätze genannt. Zu welcher Lösung kommst du denn?

So wie du in #1 dein Problem beschrieben hast, hapert es ja eigentlich nur an der Messung einer möglichst exakten Zykluszeit.
Versuche es doch mal hiermit:
Code: 
#PREV_CYCLE := RUNTIME(#CYCLE_MEMORY);
Zum Vergrößern anklicken....

Meine aktuelle Lösung steht im letzten Absatz meines Eröffnungsposts.😉
 
Wenn mein Betriebsstundenzähler unter 10% Abweichung hat, würde mir das völlig reichen.
Bsp:
Nach 5000h oder 10.000 Starts ->Gleitringwartung
Bei x und y -> Schütz wechseln
Wer braucht mehr wofür?
Hier bei uns hat irgendwann mal jemand das Byte 0 für die Blinkmerker reserviert und das Ganze sekündlich in einem DInt gespeichert.
Seidem läuft das so. Probleme gab es damit nur, wenn jemand die Zählerwerte nicht richtig gesichert und dann im Tran überschrieben hat.

Botimperators Ausbildungseffekt ist allerdings nicht von der Hand zu weisen.
 
Ludewig schrieb:
Wenn mein Betriebsstundenzähler unter 10% Abweichung hat, würde mir das völlig reichen.
Bsp:
Nach 5000h oder 10.000 Starts ->Gleitringwartung
Bei x und y -> Schütz wechseln
Wer braucht mehr wofür?
Hier bei uns hat irgendwann mal jemand das Byte 0 für die Blinkmerker reserviert und das Ganze sekündlich in einem DInt gespeichert.
Seidem läuft das so. Probleme gab es damit nur, wenn jemand die Zählerwerte nicht richtig gesichert und dann im Tran überschrieben hat.

Botimperators Ausbildungseffekt ist allerdings nicht von der Hand zu weisen.
Zum Vergrößern anklicken....

Sowas haben wir bei uns als Standard- Funktion hinterlegt. Und da wollten wir einfach die genaueste Zählweise, die das System hergibt, damit uns ein Kunde da nicht mal auf den Schlips treten könnte...


1771445118351.png
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Lars Weiß schrieb:
DINT im Sekundentakt sind so ca. 68 Jahre, nimmst du ein LINT sind es 292 Milliarden Jahre - also quasi ein fucking Erdzeitalter...
Zum Vergrößern anklicken....
Du glaubst doch nicht dass dich das schützt. Die graben dich aus und verpflanzen dein Hirn in ein Gurkenglas.

Wie genau wäre es eigentlich wenn man statt des OB1 Zeitstempels einen Weckalarm OB dafür hernehmen würde? Und da die Betriebsstunden zählen würde?

Ich habe mich nie so wirklich damit beschäftigt, ich könnte die Betriebsstunden auch mit einem TON Taktgeber aufsummieren und das würde von der Genauigkeit reichen. Darum mache ich es auch mit den Taktmerkern.
 
vollmi schrieb:
Ich habe mich nie so wirklich damit beschäftigt, ich könnte die Betriebsstunden auch mit einem TON Taktgeber aufsummieren und das würde von der Genauigkeit reichen. Darum mache ich es auch mit den Taktmerkern.
Zum Vergrößern anklicken....
Und lässt dir den Schwanzvergleich entgehen, wenn es darum geht wer den um wieviele Nanosekunden pro Jahrhundert genauere Betriebsstundenzähler hat?
1771572758684.png

Den Entwurf von @Stups finde ich schonmal grundlegend nicht schlecht, hat aber durch das zyklische Aufsummieren einer Ganzzahl die Abweichung von +/- einer Nanosektunde je SPS-Zyklus.
Wird es für die meisten, denkbaren Anforderungen ausreichen? vermutlich
Geht es genauer? Ja
Guckt ihn mein innerer Monk böse an, weil er SCL-Code in einem KOP/FUP-Baustein verwendet? ziemlich sicher ja ¯\_(ツ)_/¯
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Stups schrieb:
Wie? Sprich! 😁
Zum Vergrößern anklicken....
  • Du könntest beispielweise die Zeitstempel nur aktualiseren wenn sich der Zustand deiner "läuft"-Meldung ändert.
    Damit hättest du die Ungenauigkeit deines Datenformats nur 1x je Schaltzyklus (+ Ungenauigkeit deiner Zeitquelle).
  • Du beziehst dich direkt auf die Systemzeit der SPS.
    Das ist zwar an sich recht präzise, allerdings schlägt jedes Uhrzeit-stellen direkt auf deinen Zählwert durch.
    Wenn du deine Zeit per NTP bekommst & deine Zeitquelle macht komisches Zeugs, kann das dir die komplette Erfassungsgenauigkeit zum Teufel jagen.
Stups schrieb:
Weil?
Zum Vergrößern anklicken....
  • Du kannst z.B. keine Regions verwenden um deinen Code zu strukturieren.
    Eine grundlegende Struktur ist zwar auch mit Netzwerken möglich, du kannst allerdings keine Netzwerke in Netzwerken erstellen was wiederrum die Möglichkeiten zur Navigation im Code unnötig einschränkt.
  • Aus einem FUP/KOP-Baustein kannst du keine Bausteinquelle generieren.
    Damit ist ein Einsatz eines TIA V21 Bausteins in z.B. V16 nicht so einfach möglich, auch wenn der Code prinzipiell ohne Anpassungen auch in der älteren Version laufen würde.
  • Dateibasierte Versionskontrolle mit solchen "Bastard"-Bausteinen ist...anstrengend.
    Es bläst die Export-Dateien einfach unnötig auf & macht sie schlechter lesbar, wenn man mal direkt im VCS was nachschauen will.
    Den Aufbau einer Simatic-SD-Datei in nem Texteditor nachzuvollziehen ist einfach 🍑
 
Zuletzt bearbeitet:
Botimperator schrieb:
  • Du könntest beispielweise die Zeitstempel nur aktualiseren wenn sich der Zustand deiner "läuft"-Meldung ändert.
    Damit hättest du die Ungenauigkeit deines Datenformats nur 1x je Schaltzyklus (+ Ungenauigkeit deiner Zeitquelle).
  • Du beziehst dich direkt auf die Systemzeit der SPS.
    Das ist zwar an sich recht präzise, allerdings schlägt jedes Uhrzeit-stellen direkt auf deinen Zählwert durch.
    Wenn du deine Zeit per NTP bekommst & deine Zeitquelle macht komisches Zeugs, kann das dir die komplette Erfassungsgenauigkeit zum Teufel jagen.

  • Du kannst z.B. keine Regions verwenden um deinen Code zu strukturieren.
    Eine grundlegende Struktur ist zwar auch mit Netzwerken möglich, du kannst allerdings keine Netzwerke in Netzwerken erstellen was wiederrum die Möglichkeiten zur Navigation im Code unnötig einschränkt.
  • Aus einem FUP/KOP-Baustein kannst du keine Bausteinquelle generieren.
    Damit ist ein Einsatz eines TIA V21 Bausteins in z.B. V16 nicht so einfach möglich, auch wenn der Code prinzipiell ohne Anpassungen auch in der älteren Version laufen würde.
  • Dateibasierte Versionskontrolle mit solchen "Bastard"-Bausteinen ist...anstrengend.
    Es bläst die Export-Dateien einfach unnötig auf & macht sie schlechter Lesbar wenn man mal direkt im VCS was nachschauen will.
    Den Aufbau einer Simatic-SD-Datei in nem Texteditor nachzuvollziehen ist einfach 🍑
Zum Vergrößern anklicken....

Perfekt- Danke! Schwanzvergleich gewonnen 🤗
 
Zuviel Werbung?
-> Hier kostenlos registrieren
1. Ich lasse mittlerweile in jedem Programm einen LTON mitlaufen, der nie erreicht wird. Sein .ET entspricht der Zeit seit dem letzten Neustart. Wenn Du den beim Ein-und Ausschalten auswerten würdest, sollte es mit der Genauigkeit reichen.

2. Ich kann kein Siemens-AWL, da ich früher nur mit Moeller unterwegs war. Welch ein Glücksfall, als dann in V14 SCL in KOP und AWL möglich wurde. Da konnte ich in altem Code mal eben schnell was einfügen, ohne ständig in der Hilfe die richtige Syntax nachzuschauen.
(Anmerkung zur Moeller-Sucosoft: Da konnte man KOP und FUP direkt in AWL umschalten und AWL und SCL beliebig in einem Baustein mischen!! Ich bin verwöhnt, okay.)
 
Hallo,

hier mal ein Beispiel, wie meine Umsetzung aussieht:
1771608021882.png

Funktioniert auf der 1200er und der 1500er.
T0 ist der Gesamtzähler und T1 für einen beispielhaften Motor.
Genauigkeit habe ich noch nicht gemessen, für unsere Zwecke reicht es aus.
Die Timer sind remanent; solange nicht reinitialisiert wird, behalten diese ihre Werte, sodaß nach einer Stunde Laufzeit der jeweilige Zähler um eins erhöht wird.

edit: Falsches Bild hochgeladen
 

Anhänge

  • 1771607759776.png
    1771607759776.png
    71,9 KB · Aufrufe: 19

Similar threads

A
TIA Betriebsstundenzähler und Filtersättigungsüberwachung (HILFE)
2
Antworten
20
Aufrufe
7K
Wuslon
W
G
Step 7 Zusammenspiel Weckalarm-OB und Ablauf(OB1)?
2
Antworten
24
Aufrufe
10K
PN/DP
PN/DP
J
Betriebsstundenzähler mit Persistent Retain Variablen
Antworten
3
Aufrufe
2K
wollvieh
wollvieh
P
TIA Probleme mit TONR LTIME S7-1500 CPUs mit FW2.6.0
Antworten
0
Aufrufe
2K
Peda
P
M
TIA Daten aus der CPU in eine Exceltabelle schreiben
2
Antworten
20
Aufrufe
14K
Stups
Stups
Zurück
Oben