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

[PN/DP]

Wenn die SPS ausgeschaltet wird, dann verhält sich ein TON wie?
Sekunden zählen mit 4 kaskadierten Zählvariablen ist viel zu umständlich. Zähle einfach die Sekunden mit DINT oder UDINT. 21 Tage sind bekanntlich 1.814.400 Sekunden.
Nimm für Vorwarnung und Eskalationsmeldung zwei verschiedene Meldungen. Sinnvoll wäre vermutlich, ab Vorwarnung die Restzeit bis zur Eskalation in Tagen anzuzeigen.

 

[Dekuika]

Wenn die SPS ausgeschaltet wird, dann verhält sich ein TON wie?
Sekunden zählen mit 4 kaskadierten Zählvariablen ist viel zu umständlich. Zähle einfach die Sekunden mit DINT oder UDINT. 21 Tage sind bekanntlich 1.814.400 Sekunden.
Nimm für Vorwarnung und Eskalationsmeldung zwei verschiedene Meldungen. Sinnvoll wäre vermutlich, ab Vorwarnung die Restzeit bis zur Eskalation in Tagen anzuzeigen.

So mache ich das mit den Schmierintervallen bei unseren automatischen Anlagen auch. Zusätzlich poppt bei <1 eine rote Meldung ""Schmierung erforderlich" beim jeweiligen Gerät auf der Visu auf.

 

[DCDCDC]

So mache ich das mit den Schmierintervallen bei unseren automatischen Anlagen auch. Zusätzlich poppt bei <1 eine rote Meldung ""Schmierung erforderlich" beim jeweiligen Gerät auf der Visu auf.

Gibt es dafür nicht extra Dosiereinheiten welche das von selbst erledigen.. zumindest kenne ich das so.. da wird der gesamt verfahrene Hub mitgezählt und dann wird wie am Gerät eingestellt Schmiermittel dosiert.. wenn dann die Dose leer ist, gibts ne Meldung zum Tauschen

 

[SPSKILLER]

Wenn die SPS ausgeschaltet wird, dann verhält sich ein TON wie?

Wenn keine Signaländerung am 'IN' Eingang ansteht, dann zählt TON einfach beim letzten Stand weiter...

 

[Dekuika]

Es gibt Systeme, die sind Batteriebetrieben und sind z. B. nach einem Monat leer. Dann gibt es Automaten, bei uns in Bayern auch gern mit Biermotor, denen musst du sagen, wann er schmieren soll. Und es gibt vollautomatische Anlagen bei denen du alle 6 Monate Fett nachfüllen musst. Wichtig ist, dass geschmiert wird.

 

[Dekuika]

Wenn keine Signaländerung am 'IN' Eingang ansteht, dann zählt TON einfach beim letzten Stand weiter...

Nach einem Stromausfall wir der aber reinitialisiert, ein remanenter Datenbaustein nicht.

 

[SPSKILLER]

Nach einem Stromausfall wir der aber reinitialisiert, ein remanenter Datenbaustein nicht.

Deshalb habe ich ja auch schon angemerkt, dass man den Instanz-DB des Timers remanent schalten musss.

 

[Dekuika]

Deshalb habe ich ja auch schon angemerkt, dass man den Instanz-DB des Timers remanent schalten musss.

Beim Stromausfall hast du aber eine Signaländerung beim Eingang von TON.

 

[SPSKILLER]

Beim Stromausfall hast du aber eine Signaländerung beim Eingang von TON.

Wie kommst denn darauf?
Wenn dem so wäre, dann würde dein manueller Sekundenzähler ja auch reseten, oder?
Ich benutze schon jahrelang TONs, die beim Einschalten, auch nach Spannungswiederkehr, weiterlaufen, und hatte bisher noch keine Probleme.

 

[Dekuika]

Wenn ich beim TON das IN Signal unterbreche startet er doch neu oder? Der Zähler holt sich seinen Aktualwert aber aus dem remanenten Datenbaustein.
Edit: Ich kann es leider gerade nicht probieren, bin nicht in der Arbeit, COVID 19.

 

[SPSKILLER]

Wenn ich beim TON das IN Signal unterbreche startet er doch neu oder? Der Zähler holt sich seinen Aktualwert aber aus dem remanenten Datenbaustein.

Ich verstehe nicht, warum das IN Signal 'unterbrochen' werden sollte!?

 

[Dekuika]

Weil der Strom weg ist vielleicht.

 

[Windoze]

Alternativ nimmt man einen TONR. Der wird nur über einen expliziten Reset-Eingang zurückgesetzt.
Damit kann man auch ganz einfach die Zeit nur bei laufender Automatik weiterlaufen lassen.

 

[PN/DP]

Wenn keine Signaländerung am 'IN' Eingang ansteht, dann zählt TON einfach beim letzten Stand weiter...

Hmm, bei den speziellen Siemens-Timern, die in jeder CPU und jeder Remanenz-Einstellung anders unlogisch funktionieren, weiß man nie...
Ich hatte vermutet, dass der TE das an seiner realen CPU bereits schnell mal getestet hat, bevor er hier extra ein Thema aufmacht und fragt:

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

 

[SPSKILLER]

Ich benutze schon jahrelang TONs, die beim Einschalten, auch nach Spannungswiederkehr, weiterlaufen, und hatte bisher noch keine Probleme.

 

[XerXes777]

Es geht mir weniger um die Frage, ob etwas umständlich ist oder nicht.
Ob ich nun TON oder TONR verwende, beide benötigen etwa 64 Bit, da sie zwei TIME-Variablen nutzen.
Die von mir vorgeschlagene Zählvariable benötigt dagegen nur 32 Bit, also die Hälfte, was mir persönlich wichtig ist, um die Ressourcen zu schonen.

Nur mit einer UDINT, also einer 32-Bit-Ganzzahl als reiner Sekundenzähler zu arbeiten,
würde den Code allerdings etwas unübersichtlich machen.
Denn die Sekunden müssten jedes Mal wieder in Stunden oder Tage umgerechnet werden,
je nachdem, was gerade benötigt wird.
Wenn ich diese Umrechnung sowieso durchführen muss, kann ich die Zeit auch direkt in Sekunden, Minuten, Stunden und Tagen hochzählen. Dadurch habe ich im Code direkt Zugriff auf die Zeitwerte, die ich brauche, und das Ganze ist auf einen Blick verständlicher.

Ein Vergleich auf 21 Tage ist im Code viel besser zu erkennen als ein Vergleich auf 1.814.400 Sekunden.
So bleibt der Code auch ohne viele Kommentare leichter nachvollziehbar.

 

[DCDCDC]

Ein Vergleich auf 21 Tage ist im Code viel besser zu erkennen als ein Vergleich auf 1.814.400 Sekunden.

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

Anhang anzeigen 82020

Aufbau DTL:

SIOS

support.industry.siemens.com

Sofern du ntp einsetzt musst du ja nur warten bis deine Steuerung wieder das korrekte Datum hat und schon kannst du das einfach vergleichen..

 

[PN/DP]

Ob ich nun TON oder TONR verwende, beide benötigen etwa 64 Bit, da sie zwei TIME-Variablen nutzen.

und noch ein paar Bools und noch ein paar interne Variablen, was Siemens halt so braucht summiert sich auf 88 Byte Arbeitsspeicherbedarf je Timer-Instanz ...

Denn die Sekunden müssten jedes Mal wieder in Stunden oder Tage umgerechnet werden,
je nachdem, was gerade benötigt wird.
Wenn ich diese Umrechnung sowieso durchführen muss, kann ich die Zeit auch direkt in Sekunden, Minuten, Stunden und Tagen hochzählen. Dadurch habe ich im Code direkt Zugriff auf die Zeitwerte, die ich brauche, und das Ganze ist auf einen Blick verständlicher.

Sekunden in Stunden oder Tage umrechnen (und sogar die Zwischenergebnisse speichern) braucht aber viel weniger Code als 4 kaskadierte Zähler, die noch jeder auf Zähler-Endwert prüfen und ggf auf 0 setzen und Übertrag erzeugen müssen. Und zu jeder vollen Stunde ab Start macht die Zykluszeit einen kleinen Sprung, wenn alle Zähler einen Übertrag haben

Ein Vergleich auf 21 Tage ist im Code viel besser zu erkennen als ein Vergleich auf 1.814.400 Sekunden.
So bleibt der Code auch ohne viele Kommentare leichter nachvollziehbar.

Man könnte die Sekunden durch 86.400 dividieren und danach mit 21 vergleichen. Oder ist das auch zu kompliziert zum nachvollziehen?

 

[Dekuika]

Man könnte die Sekunden durch 86.400 dividieren und danach mit 21 vergleichen. Oder ist das auch zu kompliziert zum nachvollziehen?

Oder mit 86400 x 21 = 1814400 starten, runterzählen und bei 0 die Meldung auslösen.
Edit: Die Restzeit kann dann in Tagen, Stunden oder Minuten ausgegeben werden. Mache ich z.B. so.

 

[XerXes777]

Ich möchte mich nochmal bedanken für die vielen Antworten.
Wir sind noch mehrmals in Diskusion gegangen und es wird jetzt nur noch zum Produktionsbegin -ende gemeldet.
Wir werden die Maschine nicht anhalten und nicht blockieren. Wir haben uns da an die PKWs orientiert, die melden den Schraubenschlüssel (Wartung) auch jedesmal mit der Zündung. Und wenn man sich nicht darum kümmert, hat der Kunde Pech.