Jump to content

Uptime u.ä. läuft zu schnell


michaelst

Recommended Posts

Hallo,

ich habe die WARP1 (FW1.3.0) per MQTT mit einem Broker verbunden.
Mit meiner Haussteuerung (TwinCAT) lese ich dort diverse Werte zur Weiterverarbeitung und Visualisierung aus.

Unter anderem sind es die evse/state/uptime, .../time_since_state_change, evse/btton_state/button_press_time

Mit der aktuellen PLC-Zeit (sekundengenau), welche täglich mit einem externen Zeitserver synchronisiert wird,
bilde ich die Differenz und erhalte so die exakten Zeitpunkte, an dem die Box gestartet wurde,
der letzte Statuswechsel und Knopfdruck statt gefunden hat.

Da ich die Wallbox nicht neu starte, keinen Statuswechsel triggere und den Knopf nicht drücke,
sollten sich die drei berechneten Zeitpunkt auch nicht verändern (siehe Online-Werte).

PLC-Code:

tWallboxUptime := DINT_TO_TIME(Wallbox.diUptime);
tWallboxStart := tCurrentTimeDate - DINT_TO_TIME(Wallbox.diUptime);
tWallboxButtonPressed := tWallboxStart + DINT_TO_TIME(Wallbox.diButtonPressTime);
tWallboxLastStateChange := tCurrentTimeDate - DINT_TO_TIME(Wallbox.diTimeSinceStateChange);

Online-Werte:

grafik.png.e9f90b3e063153d32ca5e21f8aecbf13.png


Wir betrachten uns, als Beispiel, die Berechnung von tWallboxStart:
tCurrentTimeDate (aktuelle Zeit der PLC) und Wallbox.diUptime werden (theoretisch) gleichmäßig größer, daher ist die Differenz,
also tWallboxStart, konstant. Da die beiden Uhren (PLC und Wallbox) in der Praxis nicht synchron sind, sollte die Differenz mit der
Zeit etwas weglaufen. Das ist ja grundsätzlich auch OK.

Bei mir, ich vermute auch bei anderen, ist es aber so, dass ich eine Ungenauigkeit von ca. 6 Minuten pro Tag habe.
Das bedeutet, dass der oben zu sehende Online-Wert am nächsten Tag von 15:17 Uhr nach 15:11 Uhr zurückläuft.

Dies wiederum bedeutet, dass die Uhr der Wallbox zu schnell läuft, die Uptime, also zu groß ist.

Meine Frage ist jetzt: wo liegt die Ursache? Wie wird intern der Zeittakt erzeugt/gebildet?

Gruß, Michael

 

Link zu diesem Kommentar
Share on other sites

Moin,

Die Zeit wird mit dem Takt des Prozessors des Ladecontrollers gemessen, da läuft keine RTC, keine Netzwerkzeitsynchronisierung oder ähnliches. Der Anwendungsfall ist bisher nur Zeitintervalle im Bereich Minuten bis zu ein paar Stunden zu messen (lies: z.B. die Dauer eines Ladevorgangs). Deshalb können wir die 0,4% Drift verschmerzen.

Falls du das länger beobachtest: Lass dich nicht davon verwirren, dass der Zähler nach ~ 50 Tagen auf 0 zurückspringt. Der ist nur 32 Bit breit ;)

Wenn wir später Features wie z.B. verschiedene Ladeströme zu verschiedenen Tageszeiten nachlegen, brauchen wir dann natürlich eine bessere Zeitmessung und absolute Zeiten. Voraussichtlich werden wir dann NTP implementieren.

Edit: Ich habe einen entsprechenden Hinweis in die Dokumentation gepackt.

Link zu diesem Kommentar
Share on other sites

vor 3 Stunden schrieb rtrbt:

Wenn wir später Features wie z.B. verschiedene Ladeströme zu verschiedenen Tageszeiten nachlegen, brauchen wir dann natürlich eine bessere Zeitmessung und absolute Zeiten. Voraussichtlich werden wir dann NTP implementieren.

Edit: Ich habe einen entsprechenden Hinweis in die Dokumentation gepackt.

Interessante Features. Gibt es denn eine vage Featureliste/Roadmap was noch alles kommen soll ? Vielleicht geht es auch anderesn so, dass sie nicht anfangen wollen was zu entwickeln und dann wird es drei Tage später als Update veröffentlicht :-)

Link zu diesem Kommentar
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Reply to this topic...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...