Frage zu Time_of_day rechnung

misconduct

Level-1
Beiträge
140
Reaktionspunkte
24
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi,
ich habe eine Frage zum "rechnen" mit time_of_day

Die Berechnung die ich mache stimmt, und das macht mich irgendwie stutzig :confused:

also, es geht um folgendes :

Ich habe Zeit A z.B.: 11:39:41 ( feste Zeit d.h.: sie ändert sich nicht )
Und
Ich habe Zeit B z.B.: 11:40:01 ( variable Zeit da Systemzeit der CPU )

jetzt möchte ich mir eine Laufzeit errechnen indem ich die Zeiten subtrahiere

Also so : "Zeit B" - "Zeit A"
dann wird das ergebnis in eine TOD variable geschrieben und alles ist wunderbar.

Da ich nicht so viel Ahnung von Step 7 programmierung habe habe ich das ganze "händisch" gemacht, also :
"Byte Stunde von Zeit B" - "Byte Stunde von Zeit A" = "Laufzeit Stunde"
dann
"Byte Minute von Zeit B"- "Byte Minute von Zeit A" = "Laufzeit Minute"
dann
"Byte Sekunde von Zeit B" - "Byte Sekunde von Zeit A" = Laufzeit Sekunde
...



Das ganze dann noch umgerechnet da das TOD format in Millisekunden angegeben wird.

und anschließend addiere ich mir die Laufzeiten also :

Laufzeit Stunde+Laufzeit Minute + Laufzeit Sekunde = Laufzeit gesamt

Jetzt tritt der Fall ein das der "dezimalwert" der Sekunde in meinem oberen Beispiel der "alten Zeit" größer als der der "neuen Zeit" ist ( also 1 Sekunde - 41 Sekunden ), und das ergebnis ist ach negativ, warum also tritt in dem Fall kein Fehler auf?

Bin zufreiden mit dem Programm da es funktioniert, aber ich frage mich warum es funktioniert...

Wäre nett wenn mir einer helfen könnte.

Mfg
 
Hallo,
du brauchst das doch gar nicht so kompliziert zu machen ...
TOD ist vom funktionellen her die Zeit in Millisekunden, die sit 0:00 Uhr des aktuellen Tages vergangen ist. Du kannst deine TOD-Variablen direkt subtrahieren. Lediglich wenn du mit deiner Zeit-Auswertung über 0:00 Uhr kommst, dann müßtest du deine gespeicherte Zeit um 86.400.000 ms verringern (soviele hat ein Tag), damit die Differenz wieder passt ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
hi,
es geht ja nicht darum eine andere art zu finden um die laufzeit zu berechnen, aber trotzdem danke( hab ich sogar schon gemacht), es wundert mich lediglich das in dem beschriebenen fall ein negativer wert nicht zu einer verfälschung des ergebnisses führt.

mfg
 
?

... dann habe ich dein Problem wohl nicht (richtig) verstanden.
Wieso arbeitest du mit den BCD-Werten (wie bei Date_Time) wenn du es gar nicht musst ?
 
Hi,

mach die Rechnung doch mal selber, dann ist es klar. Wenn die alte Zeit größer ist wie bei der neuen Zeit ist ja weniger als eine Minute vergangen. Somit müssen die Sekunden von dieser (schon gezählten) Minute subtrahiert werden.

Gruß
Silke
 
Zuviel Werbung?
-> Hier kostenlos registrieren
mach die Rechnung doch mal selber, dann ist es klar. Wenn die alte Zeit größer ist wie bei der neuen Zeit ist ja weniger als eine Minute vergangen. Somit müssen die Sekunden von dieser (schon gezählten) Minute subtrahiert werden.

Das würde nur dann zutreffen, wenn inzwischen ein Tageswechsel stattgefunden hätte. Zu dem Punkt hatte ich mich oben aber auch schon geäußert ...

:ROFLMAO:
 
Also,
danke für die rege anteilname erstmal.
Es sind auch keine wirklichen BCD Werte sondern INT Werte, da sonst die Zeitberechnung nicht funktioniert. Soll heisen ich wandel mittels BTI BCD zu INT und rechne damit.

Und was mich an dieser Rechnung irgendwie gewundert hat ist das die T_O_D Variable keine Probleme mit einem nagativen Subtraktionsergebnis weiter arbeitet, es geht also darum warum -40000 Millisekunden genau so angenomen werden wie +19000 Millisekunden und nicht die -40000 Millisekunden von der Zeit subtrahiert sondern addiert werden ( was ja in meinem Fall auch richtig ist )

Und wie bereits erwähnt habe ich auch einen Tageswechsel berücksicht, nur diese -XXXXX Millisekunden machen mich etwas stutzig.

Mfg
 
...
negative Werte stören ihn nicht, da er (wie ich schon geschrieben habe) ein verkappter DINT ist. Ein DINT kann vom Konstrukt her genauso negativ wie positiv sein ...
Du kannst den Wert dann ja auch mit 86.400.000 korrigieren. Dann ist er wieder positiv und stimmt ...
 
Zurück
Oben