TIA DINT Wert monatlich abspeichern (Betriebsstunden)

[Mogli]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Tag zusammen,

wir haben hier eine Bestandsanlage bei der das SPS- Programm zu 90% schreibgeschützt ist. Einen Schaltplan der Anlage gibt es leider auch nicht und der Lieferant der Anlage kann uns nicht helfen (das ist ein Maschinenbauer, der mit einer externen Programmierfirma gearbeitet hat, die pleite ist...).

Im bestehenden Programm sind die Variablen leider "kryptisch" benannt und auch nicht kommentiert worden.

Mein Chef möchte gerne, dass wir die Betriebsstunden eines Gasbrenners monatlich erfassen und diese dann auf dem HMI anzeigen.
Im HMI gibt es bereits einen Betriebsstunden (und Minuten) - Zähler des Gasbrenners. Leider kann ich im Programm nicht nachschauen wie der gebildet wird (welcher Ausgang abgefragt wird).

Jetzt dachte ich mir, dass ich diese Werte (Typ UDint für die Stunden/ Typ INT für die Minuten), die ja sowieso schon erfasst werden auf neue Variablen "moven" kann und diesen Wert dann jeden Monat auf einen DB-Eintrag schiebe.
Wie kann man realisieren, dass diese Werte dann immer am letzten Tag eines Monats auf einen neuen DB-Eintrag verschoben werden?
Der "neue" Zähler soll dann bei jedem neuen Monat wieder bei "0" anfangen.

Das Programm ist geschrieben in TIA V15.1, die SPS ist eine 1512SP-1PN und das dazu gehörige HMI ist ein TP900 Comfort.

Vielen Dank schon Mal für eure Hilfe.

Grüße aus Luxembourg!

 

[PN/DP]

bei der das SPS- Programm zu 90% schreibgeschützt ist.

??? was ist "90% schreibgeschützt"? Schreibschutz kann man aufheben oder notfalls die schreibgeschützten Teile kopieren.
Oder meinst Du KnowHow-geschützt (Leseschutz)?

das ist ein Maschinenbauer, der mit einer externen Programmierfirma gearbeitet hat, die pleite ist...
(...)
Das Programm ist geschrieben in TIA V15.1, die SPS ist eine 1512SP-1PN und das dazu gehörige HMI ist ein TP900 Comfort.

Die sind aber schnell Pleite gegangen ...

Harald

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Leider kann ich im Programm nicht nachschauen wie der gebildet wird (welcher Ausgang abgefragt wird)

Gibts keinen E-Plan wo Du schaun kannst, welcher Ausgang benutzt wird? Besser noch wenn es einen Eingang als Rückmeldung gäbe. Was steht denn in der Variablentabelle für Eingänge und Ausgänge? Auch kein Kommentar?

Im HMI-Projekt kannst Du doch schaun, in welchem DB welche Variable für die Betriebsstunden benutzt wird.

 

[Mogli]

Hallo @PN/DP

ja die Bausteine (Bis auf 3 OBs und ein paar DB´s) sind alle "Know-How-Geschützt"


Ich bin erst seit ein paar Monaten hier in dieser Firma. Mir wurde eine Kontaktperson des Maschinenbauers genannt.
Der Mann baut die Dinger und arbeitet mit diversen Subfirmen/ Freiberuflern, die für ihn die Software schreiben.
Da gab es wohl knatsch, und niemand hat nun die Passwörter.


Hallo @ducati,

einen E-Plan haben wir auch nicht. Der wurde schon mehrmals angefragt, jedoch haben wir hier nie etwas bekommen...
Die Variablen-Tabelle ist leider ohne Kommentare und die Symbolischen Namen sind Abkürzungen, bei denen ich keinen
Bezug zum Gasbrenner erkennen kann (Anscheinend waren da auch mehr Programmier-Firmen am werke, denn im OB 1 sind Kommentare auf Französich, Flämisch und Niederländisch...)

 

[ducati]

na dann halt die DB-Adresse vom EA-Feld im HMI

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

wenn die Anlage nicht zu groß ist, könnt Ihr die SW auch von ner ordentlichen MSR-Firma neu machen lassen... besser da mal ein par Euro in die Hand nehmen als die nächsten 20 JAhre nur Ärger.

 

[Mogli]

na dann halt die DB-Adresse vom EA-Feld im HMI

Guten Morgen @ducati
Die Adresse des Udint habe ich.

Meine Frage ist eher, wie kann man erkennen, dass ein neuer Monat ist?
Ich würde den Wert, den ich ablese gerne abspeichern, sobald ein neuer Monat anfängt.

 

[Steffen_13]

Meine Frage ist eher, wie kann man erkennen, dass ein neuer Monat ist?

ich gehe davon aus, dass die CPU Zeit einigermaßen stimmt...

Auslesen der CPU Zeit/Datum mit RD_Loc_t.
Wert speichern, -> aktuellen Wert vergleichen mit alten -> Monatswechsel -> das machen was du willst.

 

[Mogli]

Zuviel Werbung?
-> Hier kostenlos registrieren

ich gehe davon aus, dass die CPU Zeit einigermaßen stimmt...

Auslesen der CPU Zeit/Datum mit RD_Loc_t.
Wert speichern, -> aktuellen Wert vergleichen mit alten -> Monatswechsel -> das machen was du willst.

Hi,

ja genau den Baustein hatte ich gesucht.
Mit dem RD_Loc_T, wird dann auch die Umschaltung Sommer-Winter/ Winter-Sommer-Zeit "automatisch" mit erkannt?
Bzw. werden auch Schaltjahre erkannt?

 

[ducati]

Mit dem RD_Loc_T, wird dann auch die Umschaltung Sommer-Winter/ Winter-Sommer-Zeit "automatisch" mit erkannt?

das kommt drauf an, welche Zeitzone in der SPS in der HW-Kofig eingestellt ist.

 

[Heinileini]

Die Umschaltung zwischen Sommer- und Winterzeit findet versetzt zu einem Tageswechsel (23:59:59 -> 00:00:00) statt. Somit ist ein MonatsWechsel, der immer nur zusammen mit einem TagesWechsel stattfindet, nicht davon berürhrt ist.

 

[hucki]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Umschaltung zwischen Sommer- und Winterzeit findet versetzt zu einem Tageswechsel (23:59:59 -> 00:00:00) statt. Somit ist ein MonatsWechsel, der immer nur zusammen mit einem TagesWechsel stattfindet, nicht davon berürhrt ist.

Der Tages-/Monatswechsel findet aber trotzdem 'ne Stunde eher oder später statt und die Produktion dieser Stunde ist dann ggf. im falschen Monat inkludiert.

Kommt halt drauf an, wieviel das ausmacht.

 

[PN/DP]

Kommt halt drauf an, wieviel das ausmacht.

Die ca. 4% an dem Umschalttag (bzw der Umschaltnacht, wo der Brenner vielleicht sowieso nicht läuft?) bzw. ca. 0,13% im Standard-Monat?
Da bekommt man schon viel größere Schwankungen alleine durch die 31/30/29/28 Tage die eine Monatsdauer schwankt, oder bedenke mal die schwankende Anzahl Arbeitstage im Monat je nach Kalender ... da machen die zweimal 1 Stunde im Jahr nun wirklich nichts aus.

Harald

 

[hucki]

Die ca. 4% an dem Umschalttag (bzw der Umschaltnacht, wo der Brenner vielleicht sowieso nicht läuft?) bzw. ca. 0,13% im Standard-Monat?
Da bekommt man schon viel größere Schwankungen alleine durch die 31/30/29/28 Tage die eine Monatsdauer schwankt, oder bedenke mal die schwankende Anzahl Arbeitstage im Monat je nach Kalender ... da fallen die zweimal 1 Stunde im Jahr nun wirklich nicht auf.

Nein, es geht ja nicht nur um die beiden Umschalttage.
Die Stundenverschiebung findet ja schließlich jeden Tag zwischen den Umschalttagen statt und nicht nur an diesen 2 Tagen im Jahr.

Wenn die Stundenproduktion immer in etwa gleich ist, spielt das sicher kaum 'ne Rolle, ob ich die 1. Stunde des eigenen Tages/Monats oder die 1. Stunde des Folgetages/-monats in meine Aufzeichnung einrechne.
Aber wie sieht das aus, wenn die Produktion großen Schwankungen unterliegt? Gerade in Corona-Zeiten mit teilweiser Kurzarbeit/Stillstand...



PS:
Aber so oder so liest ja der RD_LOC_T die Lokalzeit so aus, wie sie an der CPU eingestellt ist.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hmmm,
Kalender-bedingt:
- die Anzahl der Tage pro Februar bzw. Tage pro Jahr schwankt (SchaltJahr)
- die Anzahl der Tage pro Monat schwankt (28..31)
aber zusätzlich auch Standort-bedingt:
- die Anzahl der Feiertage
- die Anzahl der Arbeitstage
Firmen-abhängig:
- die Anzahl der "Brückentage"
bedingt durch Umstellung Winter-/Sommerzeit:
- die Länge der Tage
- der Beginn und das Ende eines Tages bezogen auf die Winterzeit, den Sonnenstand
Wahrscheinlich habe ich noch Vieles vergessen zu nennen.

Aber sind das nicht alles Themen/Probleme, die jeder Betrieb/Kunde für sich einheitlich klären sollte?
Z.B. VerbrauchsWerte für statistische Auswertungen nach Jahren oder Monaten oder KalenderWochen oder Tagen oder Schichten zu gruppieren, kann das denn Aufgabe eines Programmierers sein, hier die Details festzulegen?
Solche "Feinheiten" gehören doch eigentlich ins PflichtenHeft!? Oder sehe ich das zu "egoistisch"?
Wir Programmierer können auf Probleme bzw. Schwachstellen der einen oder anderen Regelung hinweisen, aber letztlich müssen wir doch "nur" Kunden-abhängig den Schwachfug in ein Programm umsetzen.
Das ist und bleibt ein Sch..xxThema und nach PatentLösungen kann man lange suchen ...
Die Abschaffung der Wechsel zwischen Winter- und Sommerzeit würden einiges erleichtern, aber noch lange nicht alle "Ungereimtheiten" beseitigen.

 

[PN/DP]

kann das denn Aufgabe eines Programmierers sein, hier die Details festzulegen?
Solche "Feinheiten" gehören doch eigentlich ins PflichtenHeft!?

Ja, der Umgang mit Uhrzeit macht viel mehr Probleme als sich viele Programmierer vorstellen können. Und auch nicht wirklich entscheiden können, wie damit umzugehen ist und wie man das korrekt implementiert. Solche Feinheiten muß man als erfahrener Programmierer regelmäßig den Auftraggebern aus der Nase ziehen, und trotzdem kommt dann häufig "Wir verstehen die Zahl nicht, warum kommt da so ein komischer/unerwarteter Wert raus?" oder "Warum wurde an dem Sonntag im Oktober zwischen 2:00 und 4:00 viel mehr Strom verbraucht als sonst?"

Harald

 

[Mogli]

Hallo zusammen,

schon Mal vielen lieben Dank für all eure Anmerkungen.
Ich habe mir dazu mal ein kleines Test-Programm geschrieben:

Ich lese mir die Loc-Zeit aus. Abhängig dann von dem Monat rufe ich einen FC (jeder Monat bekommt einen eigenen) auf.



Mein FC für Januar sieht dann wie folgt aus:
Die bestehende Anlage hat einen Dauerzähler (für die Betriebssunten des Gasbrenners).
Ich schiebe mir den aktuellen Zählwert des "Dauerzähler" auf eine DB-Eintrag (als offset).
Wenn der FC 1 Jahr später wieder aufgerufen wird, so nulle ich mir den Wert des Monats.
Ganz am Ende Subtrahiere ich den aktuellen Wert des Dauerzähler mit dem zuvor ermittelten Offset.
So habe ich dann am Ende des Monats den aktuellen Verbrauch.




Ich denke, dass dies funktioniert so, oder hat einer von euch noch eine Anregung, was ich verbessern muss?
Mein Chef möchte halt ganz gerne die Betriebsstunden des Gasbrenners haben, damit er dann jeden Monat die Brennerstunden und die Gasrechnung vergleichen kann.

Vielen lieben Dank schon Mal.

Grüße aus Luxembourg!

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mein Chef möchte halt ganz gerne die Betriebsstunden des Gasbrenners haben, damit er dann jeden Monat die Brennerstunden und die Gasrechnung vergleichen kann.

Na, dann gib ihm doch einfach eine Liste mit den Ständen des Betriebsstundezählers jeweils um Mitternacht bei Monatswechsel. (*)
Wenn Du gut zum Chef bist, dann berechne auch gleich die Differenz zum Zählerstand des Vormonats. Viel mehr will der Chef bestimmt gar nicht.

Eine sehr einfache Variante für den Monatswechsel-Trigger ist:
Monat des Datums ist ungleich Monat letzte Zählerstand-Speicherung und TOF nicht aktiv? Dann Zählerstand speichern (in Array oder Struct) und Monat merken. Und vorsichtshalber noch ein TOF von ca 5 Minuten starten, falls die Uhr kurz zurückgestellt wird. Bei der Lösung wird der Zählerstand gespeichert, wenn die SPS das erste Mal den Monatswechsel mitbekommt, was im Normalfall Mitternacht des Monatswechsel ist, es sei denn die SPS ist da gerade unpässlich...

Harald