TIA Betriebsstundenzähler und Filtersättigungsüberwachung (HILFE)

[AndreH]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo liebe Gemeinschaft!
Ich habe heute die Aufgabe bekommen, eine Programmierung zu erstellen über TIA v15.1 die einen Betriebsstundenzähler und Filtersättigungsüberwachung beinhaltet für eine Schweißrauchabsaugung "Nederman".
Mein Problem ist, dass ich einfach nicht weiterkomme und einfach feststecke.
Aufgabe:
Der Betriebsstundenzähler soll nach 1000h (Stunden) betrieb, eine gelbe Meldeleuchte (H3) für "Wartung" signalisieren. Nach der Wartung soll der Instandhalter durch ein Quittier-Taster die Meldeleuchte "resetten". Allerdings soll dieser ganz normal die Betriebsstunden weiterzählen.
Für den Filtersättigungsüberwachung soll -RK1 ins Spiel kommen. Dieser ist für das "Abschlagen/Abklopfen" der Filter zuständig. Die 6 roten LED's der Relaiskarte (-RK1) geben nacheinander (zirka. alle 20sek.) ein Signal ab. Sobald LED 6 aufblinkt, ist einmal "Abgeschlagen/Abgeklopft" und gibt ein Signal in die SPS.
Nun soll nach 1000 mal "Abschlagen/Abklopfen" die gelbe Meldeleuchte (H3) "Wartung" in Stroboskopeffekt leuchten, bis der Instandhalter mit der Quittier-Taste dies "resettet" und von vorne 1000 mal zählt.
Was ich bis jetzt habe:
Siemens S7-300 CPU 313C DI16/DO16xDC24V
E0.1 -> ist K5 (Finder Relais rechts neben K4 vom -SK1)
E0.2 -> Quittieren
E0.3 -> T1 (Ist der digitale Betriebsstundenzähler)
E0.4 -> Filtersättigung
A0.1 -> Gelbe Meldeleuchte (H3) für Wartungsintervall
Kleine Information über -SK1:
Beim Einschalten der Anlage Zieht -K1 und -K2 (Stern) an. Mit dem Zeitrelais -K1T schaltet sich die Anlage nach 8 Sekunden in Dreieck -K3 und die anderen Schütze fallen ab. -K3 fällt denn vom Zeitrelais -K5T nach 10min ab.


Ich hoffe ich konnte mit diesen Informationen etwas herleiten und hoffe hier auf Unterstützung von Programmierprofis! Für Tipps oder Verbesserungen bin ich auch gerne offen!

 

[SPS-Bitschubser]

Also zum Betriebsstunden Zähler:
1. Integrierten Betriebsstunden Zähler der SPS benutzen.
2. Alle Sekunden ein Dint hochzählen bis 3600 Sekundenzähler
und dann den Betriebsstunden Zähler hochzählen um 1, danach wieder bei 0 mit den skeundenzähler fortfahren.
Kannst hier im forum suchen da gibt's etliche Beispiele
So die Wartung geht auch leicht jedes mal wenn die quittierung der Wartung gedrückt wird den aktuellen Betriebsstunden. Wegspeichern in ein extra datenwort. Z. B. LETZTE WARTUNG. Dann akt Betriebsstunden minus letzte Wartung das größer 1000 vergleichen dann kannst die Meldung erzeugen.

Für das abklopfen kannst du ein DInt immer bei einer positiven Flanke der led6 Eingang hochzahlen. Bei quittieren kannst du den Zähler rucksetzen auf den Wert 0.

Ich hoffe du kommst damit weiter. Musterlösung hätte ich zwar schon fertig da ich sowas öfters mache, aber das wäre zu leicht für dich

 

[AndreH]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ah okay.
Mit dem Betriebsstundenzähler kam ich mit. Kann ich hier einen ODER-Baustein denn verwenden? Wäre ja blöd wenn zB. die 1000 Stunden vorbei sind, Wartung ist erfolgt und dann klopft dieser 3 mal noch ab und schon geschieht die nächste Wartungsmeldung.
Leider sagt mir "Datenwort" so gar nichts. Ich hab halt mit LOGO gelernt und fuchse mich echt schwer durch TIA.
Ich habe etwas probiert und kam jetzt so mit dem Ergebnis (siehe Datei).
Legende:
Input:
#Dreieckbetrieb (Bool Eingangssignal)
#TG (Taktgeber Bool)
Output:
Meldeleuchte
InOut:
#SEC - DINT (Sekundenzähler)
#STD - DINT (Stundenzähler)

L#0 DINT (Reset)
L#1 DINT (Betriebssekundenz)
L#2 DINT (Stundensekundenz)
Jetzt habe ich natürlich halt die 1000 Stunden -> Wartung steht an völlig vergessen zu implementieren...
Beim Abklopfen, war nur ein Fragezeichen über mein Kopf .

 

[SPS-Bitschubser]

schaut schon mal nicht schlecht aus #TG darf nur alle 1 Sekunden 1 impuls aktiv sein.
NW 2 den vergleichen statt == >= verwenden dann add mit +1 nach den vergleichen eine Abzweigung für einen move mit 0 auf den Sekundenzähler.
Hat der Bediener einen reset für beide Wartungen?

 

[AndreH]

Ah okay.
Der Bediener hat eine Quittier-Taste, womit er beide Wartungen resetten kann.

 

[SPS-Bitschubser]

Zuviel Werbung?
-> Hier kostenlos registrieren

Oke dann musst du mit den reset taster die aktuellen wartungsstunden wegspeichern. Also Ein move baustein Std akt nach std alt.
Ein datenwort ist in einen DB ein Speicher mit 16bitoder 32bit für ein doppelwort ähnlich wie in der logo mit merker.
Im Prinzip ist die 300 viel leichter als die logo zu programmieren da du viel mehr Möglichkeiten hast.
Vielleicht mal ein paar Youtube Videos hierzu ansehen. Dann versteht man die basics.

 

[AndreH]

Puh... Was ein Spaß.
Aufjedenfall vielen Dank für deine Stupser an Hilfe. Ich versuch mal was ich noch so aus meinem Kopf rausbekomme

 

[SPS-Bitschubser]

Einfach mal programmieren plc sim einschalten.
Testen schauen verbessern, weiter programmieren. Gedanken Machen, dann lernt man das programmieren, aber besser wäre es wenn du Schulungen besuchen würdest. Oder Kollegen hast der wo dir das erklärt. Erspart einen viele Fehler.

 

[Wuslon]

Zuviel Werbung?
-> Hier kostenlos registrieren

Zum Betriebsstundenzähler noch eine alternative Idee: Wenn Deine CPU keine Zeitumstellung erlebt (händisch oder Sommer/Winterzeit) und dauerhaft läuft, kann man alternativ auch die Systemzeit bei einem Reset als Referenzzeitpunkt wegspeichern und dann immer wieder die Differenz zur aktuellen Zeit berechnen.

(Wir gehen bei uns noch weiter und bestimmen in jedem Zyklus durch einen Vergleich der aktuellen Systemzeit mit der im letzten Zyklus gespeicherten Zeit die jeweilige Zykluszeit in Millisekunden, die wir dann in einen DB schreiben, auf den man systemweit zugreifen kann. Bei jedem Betriebssekundenzähler wird dann eine Time-Variable jeweils um die Zykluszeit erhöht. Überschreitet der Zähler 3600 Sekunden, wird ein Betriebsstundenzähler um 1 erhöht und der Betriebssekundenzähler zurückgesetzt.

Das Ganze machen wir allerdings in SCL, da ist so etwas deutlich einfacher zu implementieren als in FUP.)

Viele Grüße
Zini

 

[PN/DP]

Wir gehen bei uns noch weiter und bestimmen in jedem Zyklus durch einen Vergleich der aktuellen Systemzeit mit der im letzten Zyklus gespeicherten Zeit die jeweilige Zykluszeit in Millisekunden

Warum so umständlich und fehleranfällig die Zykluszeit aus der System-Uhrzeit berechnen, wenn man die Zykluszeit einfach abfragen kann? Oder in einem Weckalarm einfach nur mitzählen muß? Bei allem was sich auf die Uhrzeit bezieht, muß man überlegen was passiert bei einer Synchronisation oder sonstigen Korrektur der Uhrzeit.

Wer sowas macht, der fragt doch hoffentlich nicht auch noch zweimal im Zyklus nach der Uhrzeit? (nimmt die frühere Zeit zum rechnen und speichert die spätere Zeit zum weiterrechnen im nächsten Zyklus)

Zum Betriebsstundenzähler noch eine alternative Idee: Wenn Deine CPU keine Zeitumstellung erlebt (händisch oder Sommer/Winterzeit) und dauerhaft läuft, kann man alternativ auch die Systemzeit bei einem Reset als Referenzzeitpunkt wegspeichern und dann immer wieder die Differenz zur aktuellen Zeit berechnen.

Sowas macht aber höchstens Sinn bei Aggregaten die ununterbrochen laufen oder die Betriebsstunden einfach nur aus der vergehenden Zeit ermittelt werden, egal ob das Aggregat in Betrieb ist oder nicht. Da kann man sogar vorausschauend das Datum + Uhrzeit der nächsten Wartung angeben.

Harald

 

[Wuslon]

Warum so umständlich und fehleranfällig die Zykluszeit aus der System-Uhrzeit berechnen, wenn man die Zykluszeit einfach abfragen kann? Oder in einem Weckalarm einfach nur mitzählen muß? Bei allem was sich auf die Uhrzeit bezieht, muß man überlegen was passiert bei einer Synchronisation oder sonstigen Korrektur der Uhrzeit.

Ein Weckalarm geht zu Lasten der Bearbeitungszeit des zyklischen Programms. Wir schreiben Programme für große Anlagen mit vielen abgesetzten Unterstationen und entsprechend langen Zykluszeiten (teilweise über 1 s), da ist jede vermeidbare Zusatzlast eben vermeidbar.

Ich wüsste gerne, wie man die Zykluszeit "einfach" abfragen kann. AFAIK kann man nur die Zykluszeit des OB 1 als Variablenwert abfragen und verarbeiten. Die ist aber nicht zwingend gleich mit der Zeit, die seit dem letzten Durchlauf von OB1 vergangen ist. Bei einer gewissen Kommunikationslast für verschiedenen Bussysteme kann das Erzeugen der Prozessabbilder schon mal dauern, und soweit ich weiß, wird das in der Zykluszeit, die das System für OB1 angibt, nicht berücksichtigt.
Ich lasse mich diesbezüglich allerdings sehr gerne auf neue Pfade führen. Die Siemens-Unterlagen dazu finde ich teilweise wenig hilfreich.

Die Uhrzeitkorrektur ist in der Tat problematisch bei unserem Ansatz. Wir lösen das dadurch, dass wir a) negative Differenzen (Systemzeit wurde zurück gesetzt) und b) Ausreißer (Systemzeit wurde weit nach vorn gesetzt) nicht berücksichtigen.

Wer sowas macht, der fragt doch hoffentlich nicht auch noch zweimal im Zyklus nach der Uhrzeit?

Nein, die aktuelle Systemzeit wird zum Beginn jedes Zyklus abgefragt und für den nächsten Durchlauf abgespeichert.

Sowas macht aber höchstens Sinn bei Aggregaten die ununterbrochen laufen oder die Betriebsstunden einfach nur aus der vergehenden Zeit ermittelt werden, egal ob das Aggregat in Betrieb ist oder nicht. Da kann man sogar vorausschauend das Datum + Uhrzeit der nächsten Wartung angeben.

OK, ich habe mich missverständlich ausgedrückt. Wenn das Aggregat von Stopp nach Start wechselt bzw. die entsprechende Betriebsrückmeldung gibt, speichere die aktuelle Systemzeit. Wenn das Aggregat dann in den Stopp wechselt, bilde die Zeitdifferenz aus aktueller und gespeicherter Zeit und summiere das Ergebnis zum Betriebsstundenzähler.

Danke für die Anmerkung!

Viele Grüße
Zini

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich wüsste gerne, wie man die Zykluszeit "einfach" abfragen kann. AFAIK kann man nur die Zykluszeit des OB 1 als Variablenwert abfragen und verarbeiten. Die ist aber nicht zwingend gleich mit der Zeit, die seit dem letzten Durchlauf von OB1 vergangen ist. Bei einer gewissen Kommunikationslast für verschiedenen Bussysteme kann das Erzeugen der Prozessabbilder schon mal dauern, und soweit ich weiß, wird das in der Zykluszeit, die das System für OB1 angibt, nicht berücksichtigt.

Wo hast Du denn diese Weisheit her? Die gemeldete OB1-Zykluszeit ist die Zeitdifferenz seit vorigem OB1-Start bis zum jetzigen OB1-Start. (Nicht die Netto-Dauer des OB1-Durchlaufs.)

Ein Weckalarm geht zu Lasten der Bearbeitungszeit des zyklischen Programms. Wir schreiben Programme für große Anlagen mit vielen abgesetzten Unterstationen und entsprechend langen Zykluszeiten (teilweise über 1 s), da ist jede vermeidbare Zusatzlast eben vermeidbar.

Oha, da liegt wohl einiges ganz stark im Argen? Erzähle mal etwas deutlicher, bei was für Anlagen man dem Kunde Zykluszeiten von über 1s verkaufen kann. Das ist nach meiner Erfahrung fast nur für eine Visu oder Temperaturregelung hinnehmbar. Da schaut die Steuerung ja quasi teilnahmslos dem Prozess zu, soweit sie überhaupt etwas davon mitkriegt... Mit Bewegung haben Eure Anlagen dann sicher nichts zu tun? Was macht ein SPS-Programm eine ganze Sekunde lang?? Ist das wirklich fachmännisch programmiert? Oder untaugliche CPU ausgewählt?

Was für eine CPU ist das? Ist die mit TIA programmiert?

Die Uhrzeitkorrektur ist in der Tat problematisch bei unserem Ansatz. Wir lösen das dadurch, dass wir a) negative Differenzen (Systemzeit wurde zurück gesetzt) und b) Ausreißer (Systemzeit wurde weit nach vorn gesetzt) nicht berücksichtigen.

Das Ergebnis Eurer Zeitmessung kann also einfach administrativ festgesetzt sein und mit der tatsächlich vergangenen Zeit nichts zu tun haben... hmm... Vielleicht brauchen Eure Programme auch so lange, weil sie bei jeder Zeitverarbeitung aufwendig prüfen müssen, ob die Zeitdauer womöglich negativ oder unmöglich lang ist?

Harald

 

[DeltaMikeAir]

Oha, da liegt wohl einiges ganz stark im Argen? Erzähle mal etwas deutlicher, bei was für Anlagen man dem Kunde Zykluszeiten von über 1s verkaufen kann.

Der Gedanke kam bei mir auch schon auf. Vor allem, wenn die Anlage mit 1000ms Zykluszeit funktioniert, warum sollte dann ein Weckalarm der die Zykluszeit auf 1000,05ms erhöht ein Problem sein.

Ich kann mir auch nicht vorstellen das es hier um Bewegungssteuerung geht, eher Regelung von Temperaturen oder sowas in der Art...

 

[AndreH]

Alle nochmal zusammen.
Vielen Dank für die ganzen Tipps!
Ich habs nun mal mit dem Zähler ausprobiert und dieser funktioniert auch soweit ganz gut.
Eingestellt habe ich 1 Takt = 1Hz.
Sobald der Zähler seine 3600 Sekunden erreicht hat, zählt dieser im Netzwerk 2 bis 1000 (und höher. Dabei gedacht wenn zum Beispiel Freitag Nachmittag alle im Feierabend sind, soll dieser ganz normal weiterzählen und die Lampe soll bis zur Quittierung leuchten >=).
Im Netzwerk 3 habe ich das Abklopfen so realisiert, dass sobald mein Relais K5 ein Signal an die SPS gibt, dieser 1x klopft. Dies hab ich mit dem gleichen Prinzip einfach mal gemacht bis 1000.
Hat der Zähler 1000x abgeklopft (oder mehr wegen Feierabend/Wochenende etc.) leuchtet die Lampe im Stroboskopeffekt.

Solltet ihr noch Tipps oder gute Verbesserungen haben für mich Anfänger, höre ich mir diese gerne an

Schönen Abend!

 

[Wuslon]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wo hast Du denn diese Weisheit her? Die gemeldete OB1-Zykluszeit ist die Zeitdifferenz seit vorigem OB1-Start bis zum jetzigen OB1-Start. (Nicht die Netto-Dauer des OB1-Durchlaufs.)

Gegenfrage: Wo steht das mit der Zeitdifferenz zwischen den Starts von OB1? Also ganz genau?

Die "Weisheit" entnehme ich dem "Beispiel 2" aus diesem Siemens Step-7 Handbuch (PDF-Dokument) auf Seite 86. In selbigem Dokument weiter hinten auf Seite 670 werden zwar die OB1-Variablen mit der Zykluszeit benannt, aber eben nicht eindeutig beschrieben. Wie gesagt, ich finde die Siemens-Unterlagen wenig hilfreich.

Oha, da liegt wohl einiges ganz stark im Argen? Erzähle mal etwas deutlicher, bei was für Anlagen man dem Kunde Zykluszeiten von über 1s verkaufen kann. Das ist nach meiner Erfahrung fast nur für eine Visu oder Temperaturregelung hinnehmbar. Da schaut die Steuerung ja quasi teilnahmslos dem Prozess zu, soweit sie überhaupt etwas davon mitkriegt... Mit Bewegung haben Eure Anlagen dann sicher nichts zu tun? Was macht ein SPS-Programm eine ganze Sekunde lang?? Ist das wirklich fachmännisch programmiert? Oder untaugliche CPU ausgewählt?

Was für eine CPU ist das? Ist die mit TIA programmiert?

Da liegt ziemlich genau nix im Argen. Alles fachmännisch programmiert, mit passender CPU. Es gibt von Siemens nix schnelleres. Jedenfalls nicht zu Preisen, die wir am Markt realisieren können.

Die 1 Sekunde gab es als Maximalzeit bei großen Anlagen, in denen 50000 externe Datenpunkte aus mehreren Gewerken verarbeitet werden. Das ganze Failsyfe mit einem redundanten System. 400er-H-System und Simatic Manager, zuletzt vor ca. 5 Jahren bei Wartungen beobachtet. Bei den aktuellen R/H-Systemen und TIA bin ich nicht auf dem Laufenden, weil ich danach die Firma gewechselt habe.

Aktuell programmiere ich Anlagen in der Klimatechnik mit bis zu 5000 zu verarbeitenden Eingangswerten, einigen hundert Ausgängen und diversen, zum Teil kaskadierenden Regelkreisen, da sind 150 bis 300 ms keine Seltenheit. Mit diversen Alarm- und Warnwerten, parametrierbaren Antrieben und Reglern hat man da schon mal 25000 Variablen. Wir programmieren allerdings dabei auch nicht wirklich laufzeitoptimiert, sondern eher so ähnlich wie objektorientiert, ansonsten könnten wir die Programme nicht mehr warten. Selbst 500 ms Zyklus würden sich auf die Gesamtfunktion der Klimatechnik nicht merkbar auswirken. (Und nein, da geht es nicht nur um Temperaturregelungen, wir fahren auch schnell bewegende Kältemaschinen mit FU).

(Im oben verlinkten Siemens-Beispiel auf Seite 86 ist von 1200 ms die Rede.)

Mit Verlaub: Nur, weil etwas außerhalb Deines Erfahrungshorizonts liegt, heißt das nicht, das ich schlechte Arbeit mache.

Vielleicht brauchen Eure Programme auch so lange, weil sie bei jeder Zeitverarbeitung aufwendig prüfen müssen, ob die Zeitdauer womöglich negativ oder unmöglich lang ist?

Zwei If-Abfragen und ein Array zur Mittelwertbildung der letzten 10 Zykluszeiten fallen in SCL nicht wirklich ins Gewicht.

Akademisch betrachtet hast Du mit der administrativen Möglichkeit der Festsetzung recht. Die genannten Ausnahmefälle kommen allerdings in der Praxis bei einem sauber laufenden System vielleicht maximal fünf Mal im Jahr vor und wirken sich nur auf einen Zyklus aus, dessen Zeit minimal ungenau festgelegt wird, indem man einfach die vorherige Zykluszeit ansetzt, weil die berechnete Zeit unplausibel ist. Die daraus resultierenden Fehlweisungen in Betriebsstundenzählern halte ich für tolerierbar.

Wenn sich durch hohe Kommunikationslast die tatsächliche Zykluszeit allerdings um mehr als 10% von der reinen OB1-Zykluszeit unterscheidet, wäre die Fehlweisung nicht mehr okay, würde man nur die OB1-Zykluszeit auswerten. Ich gehe lieber den etwas aufwändigeren Weg.

Die Funktion RT_INFO steht nur auf der 1500er-Serie zur Verfügung. Und ob deren Mode 25 tatsächlich die echte Zykluszeit ausgibt, kann ich der Doku nicht entnehmen. Wahrscheinlich ist das so.

Viele Grüße
Zini

 

[PN/DP]

Gegenfrage: Wo steht das mit der Zeitdifferenz zwischen den Starts von OB1? Also ganz genau?

Hilfe zu Step7: Index > Zyklus > Organisationsbaustein für zyklische Programmbearbeitung (OB 1)
(alternativ kann man im Index auch nach "OB 1-Zykluszeit" suchen und kommt direkt zum Thema)

Zykluszeit

Die Zykluszeit ist die Zeit, die das Betriebssystem für die Bearbeitung des zyklischen Programms sowie aller diesen Zyklus unterbrechenden Programmteile (z. B. Bearbeitung anderer Organisationsbausteine) und Systemtätigkeiten (z. B. Prozessabbildaktualisierung) benötigt.

Mit eindeutigen Bildern:

Die genannten Ausnahmefälle kommen allerdings in der Praxis bei einem sauber laufenden System vielleicht maximal fünf Mal im Jahr vor und wirken sich nur auf einen Zyklus aus, dessen Zeit minimal ungenau festgelegt wird, indem man einfach die vorherige Zykluszeit ansetzt, weil die berechnete Zeit unplausibel ist.

Sag niemals "bei einer SPS kommt etwas ganz unwahrscheinlich selten vor" ... Wenn man eine Uhrzeitsynchronisation hat (und das sollte jede SPS-CPU haben, die irgendwas mit Zeitstempeln macht), dann kann (und wird) es vorkommen, daß in jeder Minute einmal die Uhr etwas vor- oder zurückgestellt wird (Standardeinstellung).


Schon komisch, daß immer solche Programmierer an den größten Anlagen programmieren, die im Detail am wenigsten Ahnung haben Naja, für große Anlagen darf man sich halt von Details nicht aufhalten lassen ...

Viele Grüße
Harald

 

[DeltaMikeAir]

Schon komisch, daß immer solche Programmierer an den größten Anlagen programmieren, die im Detail am wenigsten Ahnung haben Naja, für große Anlagen darf man sich halt von Details nicht aufhalten lassen ...

Bei Zykluszeiten von bis zu 1s werden Fehler wohl oft weggeglättet

 

[Wuslon]

Zuviel Werbung?
-> Hier kostenlos registrieren

Schon komisch, daß immer solche Programmierer an den größten Anlagen programmieren, die im Detail am wenigsten Ahnung haben Naja, für große Anlagen darf man sich halt von Details nicht aufhalten lassen ...

Schon komisch, dass man in Foren immer wieder beobachten kann, dass sich ein paar Leute mit sehr vielen Beiträgen irgendwann dazu tendieren, Benutzern mit weniger Beiträgen zu unterstellen, dass sie im Prinzip zu blöd sind, um sich im Forum äußern zu dürfen. Gerne mal garniert mit stichwortartigen Einwürfen, die weniger aktive Benutzer nicht verstehen, weil sie mit den Stichworten nix anzufangen wissen bzw. im Fachjargon des foreneigenen Ökosystems nicht so bewandert sind.

Naja, wenn man im Mittel vier Beiträge am Tag absetzt, darf man sich halt nicht auf Details der Diskussion einlassen.

Bei Zykluszeiten von bis zu 1s werden Fehler wohl oft weggeglättet

Schön, dass ich Dich erheitern konnte. Schade, dass dadurch nur Dein Beitragszähler erhöht wurde.

[Und ja, die Moderation kann mich für diese Äußerung abwatschen. Ich finde Sarkasmus nicht wirklich angenehm.]

[...]
Mit eindeutigen Bildern:
[...]

Das habe ich in der von mir zitierten Unterlage auch gefunden. Dort wird nochmal darauf hingewiesen, dass die Ausführung von OB1 durch andere Bausteine unterbrochen werden kann.

Ich suche immer noch nach einer technischen Unterlage von Siemens, aus der hervorgeht, dass z.B. OB1_PREV_CYCLE INT oder die per RT_INFO abfragbare Zeit auch tatsächlich die Zykluszeit ist, wie sie in dem von Dir beigebrachten Bild definiert ist. Ich wüsste gerne, ob die Zykluszeitangabe eine echte Kernelzeitmessung ist oder nicht vielleicht doch nur zwei Zeitstempel miteinander vergleichen werden. Bei letzterem könnte nämlich auch intern der gleiche Messfehler auftreten, den Du ansprichst.

Mag sein, dass ich den Wald vor lauter Bäumen nicht sehe.

Sag niemals "bei einer SPS kommt etwas ganz unwahrscheinlich selten vor" ... Wenn man eine Uhrzeitsynchronisation hat (und das sollte jede SPS-CPU haben, die irgendwas mit Zeitstempeln macht), dann kann (und wird) es vorkommen, daß in jeder Minute einmal die Uhr etwas vor- oder zurückgestellt wird (Standardeinstellung).

Falls Du mit Uhrzeitsynchronisation diejenige zwischen HMI und SPS meinst: Man kann durchaus geteilter Meinung sein, ob jede SPS-CPU, so was "haben sollte", nur weil man was mit Zeitstempeln macht. Im Gegenteil möchte ich behaupten, dass man das aus den von Dir genannten Gründen eben gerade nicht macht, wenn man auf der SPS mit Zeitstempeln arbeitet.

Wir machen das jedenfalls nicht und leben damit, dass die RTU der SPS zwischen zwei Wartungen durchaus mal ein paar Minuten Abweichung zum HMI hat. (Die dann per Handeingabe ausgelöste Synchronisation der SPS-Uhr mit der Uhr des PG ist bei uns einer der maximal fünf Male im Jahr, in denen die Ausnahmenbehandlung greift.)

Für den Endkunden sind Zeitstempel meines Erachtens nur auf dem HMI von Interesse, dort schwerpunktmäßig im Meldesystem und mehrheitlich aus versicherungstechnischen Gründen. Den Diagnosepuffer der SPS schaut sich keiner unserer Kunden an. Wir werden direkt angerufen, wenn die SPS rumzickt. Daher spielen Zeitdifferenzen zwischen SPS und HMI bei uns nur eine untergeordnete Rolle.

Viele Grüße
Zini

 

[DeltaMikeAir]

Schön, dass ich Dich erheitern konnte. Schade, dass dadurch nur Dein Beitragszähler erhöht wurde.

[Und ja, die Moderation kann mich für diese Äußerung abwatschen. Ich finde Sarkasmus nicht wirklich angenehm.]

Na komm. Nimm es doch nicht persönlich. Die meisten hier sind auch auf Montagen unterwegs und da herrscht manchmal
auch ein rauer Ton und muss man auch immer wieder mal etwas einstecken können ( aber auch gerne mal austeilen ).
Warum sollte dich jemand abwatschen, es ist doch ok dass du mir deine Meinung zu meinem Kommentar sagst. Du hast ja auch
Recht mit dem was du zu mir gesagt hast, insofern alles OK.

 

[PN/DP]

Ich suche immer noch nach einer technischen Unterlage von Siemens, aus der hervorgeht, dass z.B. OB1_PREV_CYCLE INT oder die per RT_INFO abfragbare Zeit auch tatsächlich die Zykluszeit ist, wie sie in dem von Dir beigebrachten Bild definiert ist. Ich wüsste gerne, ob die Zykluszeitangabe eine echte Kernelzeitmessung ist oder nicht vielleicht doch nur zwei Zeitstempel miteinander vergleichen werden.

Frage doch den Siemens Support, ob die eine bessere/eindeutigere Definition/Erklärung zu der von OB1_PREV_CYCLE und RT_INFO gemeldeten "Zykluszeit" haben. Ich gehe davon aus, daß die Zykluszeit im Kernel unabhängig von der Uhr gemessen wird, vermutlich mit dem Systemzeitgeber (Stichwort SFC64 "TIME_TCK").
Oder überprüfe das einfach selbst: addiere fortlaufend die OB1_PREV_CYCLE und vergleiche mit der vergehenden Uhrzeit. Setze die CPU währenddessen einer hohen Kommunikationsbelastung aus (z.B. Baustein beobachten + Variablen beobachten). Kannst Du da die befürchtete Abweichung von 20..50% feststellen?

Falls Du mit Uhrzeitsynchronisation diejenige zwischen HMI und SPS meinst

Nein, ich meine eine Uhrzeitsynchronisation der SPS-CPU (oder der mehreren CPU in der Anlage) mit einem NTP-Server, die bei so großen Anlagen wie bei Dir doch eigentlich obligatorisch sein sollte. Oder wird das bei Euren Anlagen eher als Risiko auf die Stabilität der Anwenderprogramme eingeschätzt?

PS: Ihr verwendet keine Meldeverfahren, wo die Zeitstempel aus der CPU kommen? Ihr bildet keine Ereignisse aus der Uhrzeit der CPU?

Harald