TIA TON_TIME über mehrere Tage mit Remanenz speichern – Wie umsetzen?

[XerXes777]

Hallo zusammen,

ich stehe vor folgender Herausforderung und hoffe, ihr könnt mir weiterhelfen:

Ist es möglich, einen TON_TIME über mehrere Tage laufen zu lassen, ohne dass er beim Ausschalten der Maschine neu startet?
Meine Idee wäre, den aktuellen Status des TON_TIME in einem globalen DB als remanenten Wert zu speichern,
um den Fortschritt über Neustarts hinweg zu bewahren.

Hintergrund: Es gibt bestimmte Fehler, die quittiert werden dürfen, obwohl sie noch anstehen.
Nach einer Karenzzeit von 21 Tagen sollte jedoch eine Eskalation stattfinden, bei der der Fehler nicht mehr quittiert werden kann.

Ideal wäre es, den TON_TIME zu verwenden, da das einfach umzusetzen wäre.
Alternativ könnte ich das über einen 1-Sekunden-Takt und einen Integer-Wert lösen und eine Art Stoppuhr programmieren.
Allerdings scheint mir das komplizierter als notwendig.

Habt ihr eine Idee, wie ich das am besten umsetzen kann?
Oder gibt es vielleicht einen einfacheren Weg, den ich noch nicht bedacht habe?

Vielen Dank im Voraus!

 

[DCDCDC]

Fehler taucht auf > DatumUhrzeit wegspeichern > mit aktuellem DatumUhrzeit gegenrechnen und schauen ob die Tagesanzahl erreicht wurde
oder
Startdatum nehmen + 21 Tage draufrechnen und dann auf ungleich oder gleich vergleichen

Brauchst ja nur das Datum, das kannst du dir über eine Konvertierung von DTL zu Date zB ausgeben lassen



Aufbau DTL:

SIOS

support.industry.siemens.com

 

[XerXes777]

Und wie würdest du das handhaben, wenn die Maschine längere Zeit ausgeschaltet ist und die Uhrzeit danach nicht mehr korrekt ist?
Die Anlage hat leider kein HMI, um manuell nachzujustieren.
Das erscheint mir etwas zu unsicher in dieser Konstellation.

Hast du eine Idee, wie man dieses Problem umgehen könnte?

 

[ducati]

Und wie würdest du das handhaben, wenn die Maschine längere Zeit ausgeschaltet ist und die Uhrzeit danach nicht mehr korrekt ist?
Die Anlage hat leider kein HMI, um manuell nachzujustieren.
Das erscheint mir etwas zu unsicher in dieser Konstellation.

Hast du eine Idee, wie man dieses Problem umgehen könnte?

Wenn die SPS ausgeschaltet ist, läuft ein TON auch nicht...
Also wenn die SPS-Uhr oft falsch läuft und die SPS oft aus ist, dann kannst nur die Zeit zählen während die SPS läuft (Taktmerker->Flanke->Addierer->remanenteDINT). Oder ne automatische Uhrzeitsynchronisation basteln..

 

[SPSKILLER]

Wenn es ok ist, dass deine 21 Tage Einschaltverzögerung nur zählt wenn die SPS auch eingeschaltet ist, dann reicht es aus, den Instanz-DB vom Timer remanent zu setzen.
Ansonsten ist es so wie ducati schon sagt... Der Timer wird Ausschaltzeiten nicht berücksichtigen.

 

[escride1]

Und wie würdest du das handhaben, wenn die Maschine längere Zeit ausgeschaltet ist und die Uhrzeit danach nicht mehr korrekt ist?

Sollte eine CPU mit RTC handhaben können.

 

[Heinileini]

Ist es möglich, einen TON_TIME über mehrere Tage laufen zu lassen, ohne dass er beim Ausschalten der Maschine neu startet?

Das Problem dürfte eher sein, dass die Zeit beim Einschalten der Maschine nicht neu gestartet werden soll.

Hintergrund: Es gibt bestimmte Fehler, die quittiert werden dürfen, obwohl sie noch anstehen.
Nach einer Karenzzeit von 21 Tagen sollte jedoch eine Eskalation stattfinden, bei der der Fehler nicht mehr quittiert werden kann.

??? Nach einer KarenzZeit von 21 Tagen soll eine Meldung NICHT mehr quittiert werden können ???
Könnte denn eine Meldung, die nicht quittiert werden darf, erneut auftreten und dann doch quittiert werden dürfen?
Oder soll die Meldung etwa auf ewige Zeiten unquittierbar bleiben? Eine sinnvolle Anwendung und Handhabung kann ich mir nicht so recht vorstellen. Genügt es nicht, einen solchen "Vorfall" zu protokollieren?

Ideal wäre es, den TON_TIME zu verwenden, da das einfach umzusetzen wäre.

Im Prinzip ja, ABER Du benötigst für jede Meldung mit dieser Eigenschaft einen separaten Timer ... oder habe ich das falsch verstanden?

Alternativ könnte ich das über einen 1-Sekunden-Takt und einen Integer-Wert lösen und eine Art Stoppuhr programmieren.
Allerdings scheint mir das komplizierter als notwendig.

Das erscheint mir eigentlich eher einfacher. Aber funktionsfähig Zeiten damit überwachen kann man genausowenig, wie mit Timern während die PLC nicht läuft.
Auch hier gilt, Du benötigst für jede Meldung mit dieser Eigenschaft eine separate ZählVariable.

Habt ihr eine Idee, wie ich das am besten umsetzen kann?

Die Idee mit der Uhrzeit (Beitrag #2) finde ich gar nicht übel.
Solange die PLC nicht läuft, passiert zwar gar nichts, aber sobald sie wieder läuft, kann man doch immerhinn darauf hoffen, dass die Uhrzeit in der PLC irgendwann - wodurch auch immer *) - wieder eingerenkt wird. Dann wird doch das, was erledigt werden soll, noch nachgeholt, wenn auch möglicherweise zu spät (?).
Man müsste "lediglich" dafür sorgen, dass, bis die Zeit neu gestellt ist, keine Informationen gelöscht werden, die man noch braucht.
Ferner müsste man eine "ErsatzZeit" laufen lassen, so dass man für neu auftretende Meldungen dieses Typs eine behelfsmässige ZählMöglichkeit hat, bis die Uhrzeit aktualisiert wird.

*) Daran wirst Du sicherlich noch arbeiten müssen, egal wie, wann, wodurch Du das Stellen bewerkstelligen wirst.

 

[PN/DP]

Hintergrund: Es gibt bestimmte Fehler, die quittiert werden dürfen, obwohl sie noch anstehen.
Nach einer Karenzzeit von 21 Tagen sollte jedoch eine Eskalation stattfinden, bei der der Fehler nicht mehr quittiert werden kann.

Vielleicht solltest du nochmal genau nachdenken und definieren was eigentlich erreicht werden soll.
"Fehler quittieren" heißt nach meinem Verständnis nicht, den Fehler ignorieren und trotzdem unbekümmert weiterarbeiten, sondern quittieren, dass die Fehlermeldung gesehen wurde. Ob die Anlage trotz noch immer anstehendem Fehler weiterlaufen darf, steht auf einem anderen Blatt.

Die "21 Tage" sind doch bestimmt nur eine "willkürliche" Festlegung und müssen nicht genau eingehalten werden? Kann der Kunde einfach die Uhr zurückstellen oder eine Batterie entfernen und damit die Eskalation umgehen/verhinden? Hat er einen Anreiz, so etwas zu tun? Was ist der Grund für die 21 Tage? Vielleicht eine Bezahl-Erzwingungs-Funktion?

 

[XerXes777]

Vielen Dank für die vielen Antworten und Anregungen!

Ihr habt mich überzeugt, dass die TON_TIME oder ein Sekunden-Zähler nur zählt,
wenn die SPS im RUN-Modus ist. Daran hatte ich gestern Abend gar nicht mehr gedacht.

Es spricht also mehr dafür, das Datum zu speichern.

Für den Fall, dass die SPS länger als 20 Tage ausgeschaltet ist und Datum und Uhrzeit verliert,
sollte das Datum dann auf den Initialwert zurückgesetzt werden. Das wäre vermutlich 1990, oder?
Ich würde das so abfangen, dass es in diesem Fall keine Karenzzeit mehr gibt.

Ich verstehe die Fragen zur Sinnhaftigkeit gut. Bei einer anstehenden Meldung wird ein erneutes Starten der Anlage verhindert.
Somit kann der Kunde mit der Maschine nicht mehr produzieren.

Hier ein Beispiel zur Veranschaulichung:
In der Anlage gibt es Bauteile, die regelmäßig durch eine Zentralschmierung gewartet werden müssen.
Sobald die Schmierstoffkartusche leer ist, soll es eine erste Meldung als Vorwarnung geben.
Nach 21 Tagen – und dieser Zeitraum ist nicht willkürlich gewählt – muss eine neue Kartusche eingesetzt werden.
Geschieht das nicht, kommt die Meldung erneut, kann dann nicht mehr quittiert werden,
und die Maschine lässt sich nicht mehr starten.
Dieses Beispiel steht stellvertretend für mehrere ähnliche Szenarien in der Anlage.

 

[Onkel Dagobert]

Dann generiere doch ganz einfach zwei Meldungen. Die erste stellt lediglich eine Meldung dar und kommt sofort mit dem Ereignis. Die zweite kommt verzögert und schaltet die Maschine ab. Das hat doch mit dem Quittieren garnichts zu tun. Das gespeicherte und remanente Meldebit wird doch so wie so nur zurückgesetzt, wenn das Meldeereignis beseitigt ist und wenn quittiert wurde? Zumindest sollte es so sein!

In deinem genannten Beispiel ist es wahrscheinlich auch vertretbar, dass die Zeit nicht weiter läuft während die Maschine abgeschaltet ist.

 

[PN/DP]

Wenn der Zeitraum 21 Kalendertage ab einem Trigger sein soll, egal ob die Anlage eingeschaltet ist und Schmierstoff braucht oder nicht, dann braucht die Zeit nicht mitgezählt werden, sondern der Eskalations-Zeitpunkt kann sofort aus dem Datum beim Trigger berechnet werden. Allerdings hat diese Lösung den Nachteil, dass einfach die Uhr manipuliert/zurückgestellt werden kann und dann die Anlage viel länger ohne Schmierstoff betrieben werden kann.
Mitzählen der Zeit ala TON-Timer oder Sekundenzähler (nur während die Anlage eingeschaltet ist!), braucht man, wenn der Eingeschaltet- oder Produktiv-Zeitraum gemessen werden soll.

Ist nun die reine Anzahl Kalendertage entscheidend oder wie lange die Anlage tatsächlich ohne Schmierstoff läuft?
Kann der Trigger zurückgesetzt werden, einfach durch öffnen des Schmierstoffbehälters oder durch einsetzen einer leeren Kartusche?

Einfach eine Maschine stillsetzen, nur weil eine Zeitberechnung der Meinung ist, dass ein Schmierstoff aufgebraucht sein müsste, ist für mich keine gute Lösung. (Macht z.B. die Kfz-Branche auch nicht.) Da müsste sicher eine Vorwarnung mit Anzeige der Restzeit oder Überschreitungszeit kommen, damit die notwendige Wartung geplant werden kann. Kann nicht der Schmierstoff-Verbrauch oder die Schmierstoff-Restmenge ("Reserve") mit 2 Stufen gemessen werden? Wenn der Schmierstoff sehr essentiell für den Betrieb der Anlage ist, dann würde ich eher schon bei der Kartusche-leer-Anzeige den Start verhindern und die Vorwarnzeit "voraussichtliche Restzeit" berechnen.

 

[Heinileini]

Dann generiere doch ganz einfach zwei Meldungen. Die erste stellt lediglich eine Meldung dar und kommt sofort mit dem Ereignis. Die zweite kommt verzögert und schaltet die Maschine ab. Das hat doch mit dem Quittieren garnichts zu tun. Das gespeicherte und remanente Meldebit wird doch so wie so nur zurückgesetzt, wenn das Meldeereignis beseitigt ist und wenn quittiert wurde? Zumindest sollte es so sein!

Danke, Dagobert! Jetzt habe ich - glaube ich - verstanden, worum es hier geht und was angestrebt wird.
Na klar, statt einer "abgestuften" Meldung je eine eigene Meldung für jede der beiden Phasen bzw. Abstufungen zu spendieren, vereinfacht das Verständnis und mit Sicherheit auch die Umsetzung der Aufgabe.

In deinem genannten Beispiel ist es wahrscheinlich auch vertretbar, dass die Zeit nicht weiter läuft während die Maschine abgeschaltet ist.

Ich finde es nicht nur vertretbar, sondern äusserst passend, wenn die Frist von 20 bzw. 21 Tagen nicht weiter abläuft, während die Maschine abgeschaltet ist.
Die Zeit soll ja anscheinend nur ablaufen, wenn ich habe Kartusche leer und nichts dagegen unternehme, obwohl die Maschine weiterhin in Betrieb bleibt.

 

[CL550]

Macht z.B. die Kfz-Branche auch nicht.

Also mein Auto sagt mir, es würde nicht mehr starten wenn ich AdBlue nicht nachfülle. Ich habe das noch nicht getestet.

 

[Heinileini]

Einfach eine Maschine stillsetzen, nur weil eine Zeitberechnung der Meinung ist, dass ein Schmierstoff aufgebraucht sein müsste, ist für mich keine gute Lösung.

Als Vorwarnung ist das nicht geeignet, aber als "NotBremse", wenn man trotz rechtzeitiger Vorwarnung offensichtlich nicht reagiert hat.
Ich denke, so ist es auch gemeint.

Kann nicht der Schmierstoff-Verbrauch oder die Schmierstoff-Restmenge ("Reserve") mit 2 Stufen gemessen werden?

Könnte mir gut vorstellen, dass eine solche Messung an der relevanten Stelle der Maschine nicht möglich ist, sondern erst in einer gewissen Entfernung vom "Verbraucher". Das Volumen der Leitung müsste sich ja ermitteln lassen, so dass sich die "Reserve" berechnen lässt.
"Kartusche leer" ist sicherlich der richtige ZeitPunkt für die Meldung. Aber man möchte anscheinend "über den Daumen peilen" können, wann die Versäumnis sich nicht mehr ausbügeln lässt, die Reserve also nicht ausgereicht hat.

 

[PN/DP]

Der Verbrauch und Restmenge kann vielleicht auch grob aus den Betriebsstunden berechnet werden? Bevor das "Kartusche_leer"-Signal kommt.
"Kartusche_leer" oder "Adblue_leer" Signale würde ich nicht durch irgendwelche Zeitrechnungen verzögern wollen, besonders wenn nicht klar ist, ob die reine Standzeit oder Betriebszeit dafür benutzt werden müsste.

Das erinnert mich irgendwie an einen Maschinenbauer, der bei Konstruktionsfehlern (fehlenden Sensoren) den SPS-Progammierer fragt "Kannst du nicht noch 347ms weiterfahren?"

 

[Onkel Dagobert]

.. Einfach eine Maschine stillsetzen, nur weil eine Zeitberechnung der Meinung ist, dass ein Schmierstoff aufgebraucht sein müsste, ist für mich keine gute Lösung...

So ist es ja auch nicht. So eine automatische Schmierung arbeitet sowieso nur in zeitlichen Abständen von Stunden oder Tagen. Sie ersetzt den humanen Schmiernippelschmierer. Der Schmierstoff ist zum Zeitpunkt der ersten Meldung bereits aufgebraucht. Von da an kann die Maschine für eine gewisse Zeit weiterlaufen, in der Sie sowieso nicht geschmiert würde. Es gibt auch keine Restmenge. So kenne ich das jedenfalls.

 

[PN/DP]

Muss eine Maschine, die ausgeschaltet ist, trotzdem regelmässig geschmiert werden?

 

[Heinileini]

Der Verbrauch und Restmenge kann vielleicht auch grob aus den Betriebsstunden berechnet werden?

Ich gehe davon aus, dass genau das hier auch praktiziert wird. Z.B. das Volumen der RestMenge in der Leitung zum ZeitPunkt des LeerWerdens der Kartusche kann ziemlich genau beziffert werden. Damit kann dann per ErfahrungsWert des durchschnittlichen Verbrauchs die ReserveZeit "berechnet" werden - nicht genau, aber anscheinend "genau genug", um nach der abgelaufenen Zeit die gewünschte Reaktion zu veranlassen.
Ob der Aufwand gerechtfertigt ist, aus einer relativ vagen Annahme eine drastische Reaktion abzuleiten, mag ich nicht beurteilen.

So ist es ja auch nicht. So eine automatische Schmierung arbeitet sowieso nur in zeitlichen Abständen von Stunden oder Tagen. Sie ersetzt den humanen Schmiernippelschmierer. Der Schmierstoff ist zum Zeitpunkt der ersten Meldung bereits aufgebraucht. Von da an kann die Maschine für eine gewisse Zeit weiterlaufen, in der Sie sowieso nicht geschmiert würde.

So kenne ich es auch, dass eine "ZentralSchmierung" in bestimmten Intervallen getriggert wird.

Es gibt auch keine Restmenge. So kenne ich das jedenfalls.

Ich halte es für fraglich, ob eine vorhandene RestMenge überhaupt genutzt werden kann, wenn der Nachschub unterbrochen ist.
Wahrscheinlich ist der Transport der RestMenge nicht oder nur unzureichend möglich.

Muss eine Maschine, die ausgeschaltet ist, trotzdem regelmässig geschmiert werden?

Ich könnte es mir vorstellen. Aber wenn überhaupt, dann wahrscheinlich nach ganz anderen Regeln und "Bedürfnissen", als eine laufende Maschine. Wer soll schmieren, wenn die Maschine ausgeschaltet ist?
Diese Aspekte scheinen mir off topic zu sein. Wahrscheinlich gilt dies auch schon für die Themen RestMenge bzw. Reserve.

Wir haben nun reichlich herumspekuliert und denkbare Anfordrungen in den verschiedensten Richtungen abgeklappert.
Ich hoffe, wir haben den TE damit nicht so sehr frustiert, dass er sein Projekt jetzt am liebsten wegschmeissen möchte.

 

[XerXes777]

Die Anweisung kommt von der mechanischen Konstruktion und soll genau so umgesetzt werden.
Es läuft folgendermaßen ab: Eine Meldung kommt, wird interpretiert und kann einmal gelöscht werden.
Nach einer bestimmten Zeit (x Tage) soll sie erneut auftreten und eskalieren.
Sobald der entsprechende Meldungstyp aktiv ist, stoppt die Anlage und es ist keine Produktion mehr möglich.

Ein Beispiel für den Trigger wäre die Leer-Meldung einer Schmierpumpe.
Dieser Meldungstyp wird nur ausgelöst, wenn die Peripherie einen geeigneten Trigger hat.

Mir ist wichtig, diese Funktion möglichst stabil und ressourcensparend umzusetzen.
Dabei ist die Kombination entscheidend. Ich muss mich auch für eine Variante entscheiden:
Soll gezählt werden, wenn die Maschine an oder aus ist?
Technisch betrachtet macht es hier Sinn, nur zu zählen, wenn die Anlage im Automatikmodus ist, da all diese Meldungen mit notwendigen, lebenswichtigen Wartungsarbeiten verbunden sind.

Leider sind alle 10 internen RTMs (Realtime-Timer) bereits belegt und es wären auch generell zu wenige.
Daher plane ich, einen Sekunden-Takt zu bauen, der auf Minuten, Stunden und Tage hochzählt.
Dafür möchte ich 4x USINTs verwenden: Sekunden, Minuten, Stunden, Tage (32 Bit pro Meldung),
sowie 3 Bits für "gekommen", "quittiert" und "eskaliert", die im Remanenzspeicher liegen.

Was sagt ihr dazu? Wie würdet ihr das umsetzen?

 

[SPSKILLER]

Leider sind alle 10 internen RTMs (Realtime-Timer) bereits belegt und es wären auch generell zu wenige.
Daher plane ich, einen Sekunden-Takt zu bauen, der auf Minuten, Stunden und Tage hochzählt.
Dafür möchte ich 4x USINTs verwenden: Sekunden, Minuten, Stunden, Tage (32 Bit pro Meldung),
sowie 3 Bits für "gekommen", "quittiert" und "eskaliert", die im Remanenzspeicher liegen.

Was sagt ihr dazu? Wie würdet ihr das umsetzen?

Viel zu umständlich... Mach doch so, wie du es am Anfang vorhattest. Einfach TONs verwenden.