Jump to content

Uptime u.ä. läuft zu schnell


michaelst
 Share

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 to comment
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 to comment
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 to comment
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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...