WinCC Unified Archiv als *.csv - unerwartetes Ergebnis beim Auslesen

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Umrechnung TimeStamp [ms] von Unified zu Excel

Hast du mal ein Beispiel für einen TimeStamp-Wert?

17192204964108000

Da hast du vermutlich einen Tippfehler (eine 0 zuviel) in deiner Angabe? Der korrekte Wert müsste sein: 1719220496410800
Mit 1719220496410800 funktioniert auch die Excel-Umrechnung/Anzeige.

In Excel kommt dann 17199978922064800 an und egal welche Formel ich versuche, es kommt kein darstellbarer Zeitwert raus.

Die Timestamps sind die Anzahl Millisekunden seit 1.1.1970 0:00 Uhr UTC (also Unixzeit * 1000)
1719220496410800 = 2024-06-24 09:14:56 UTC

Ich schreibe die Lokalzeit aus der CPU ins Archiv, die 17199978922064800 Variable ist als DTL konfiguriert

Tipp: aus der TIA-Hilfe:

Der Datentyp LDT (DATE_AND_LTIME) speichert Angaben zu Datum und Uhrzeit in Nanosekunden seit dem 01.01.1970 0:0

 

[schwimmer]

Da hast du vermutlich einen Tippfehler (eine 0 zuviel) in deiner Angabe? Der korrekte Wert müsste sein: 1719220496410800

Nein, kein Tippfehler. Der Wert steht so in der Excel-Datei. Habe gerade nochmal Werte ausgelesen.

17.199.979.322.026.000​

17.199.979.422.071.800​

1.719.997.952.212.870​

17.199.979.621.997.600​

17.199.979.722.036.000​

17.199.979.822.143.200​

1.719.997.992.201.750​

17.199.980.022.126.800​

17.199.980.122.109.300​

1.719.998.022.224.580​

17.199.980.322.122.000​

Hierbei ist auffällig, dass es immer wieder mal Werte gibt die sich umrechnen lassen und dann wieder Werte kommen die eine Stelle mehr haben.
Eigentlich sollte der Wert sich immer um 10 Sekunden ändern.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nein, kein Tippfehler. Der Wert steht so in der Excel-Datei. Habe gerade nochmal Werte ausgelesen.
(...)
Hierbei ist auffällig, dass es immer wieder mal Werte gibt die sich umrechnen lassen und dann wieder Werte kommen die eine Stelle mehr haben.

dann informiere mal den Siemens Support.
Bis zu einer "richtigen" Lösung könntest du als workaround den Wert noch zusätzlich durch 10 dividieren, wenn der Wert >= 10.000.000.000.000.000 ist. (also durch 10 Mio anstatt 1 Mio)

PS: irgendwo hatte ich glaub' ich gelesen, dass der Timestamp auch noch (gerundete?) Bruchteile von Mikrosekunden (oder Nanosekunden?) enthält (und womöglich LREAL ist?), vielleicht kommt daher die Konfusion und der Fehler?

 

[PN/DP]

Der Wert steht so in der Excel-Datei. Habe gerade nochmal Werte ausgelesen.

Und wenn du die csv-Datei mit einem normalen Texteditor (z.B. Notepad) öffnest anstatt Excel, was steht da drin?
Tipp: bei unerklärlichen Anzeigeproblemen mit csv-Dateien die immer mit einem Texteditor oder Hexeditor öffnen. Excel "erfindet" gerne automatische Anzeigeformate beim Öffnen von csv

 

[schwimmer]

dann informiere mal den Siemens Support.

Ich werde mal einen SR aufmachen.

PS: irgendwo hatte ich glaub' ich gelesen, dass der Timestamp auch noch (gerundete?) Bruchteile von Mikrosekunden (oder Nanosekunden?) enthält (und womöglich LREAL ist?), vielleicht kommt daher die Konfusion und der Fehler?

Ich kann nur sagen, dass mit der Formel, die SIEMENS in der Doku für den Timestamp steht, bei mir nur negative Werte rauskommen. Zudem ist das ja immer UTC und damit eigentlich auch unbrauchbar. Wenn sich jemand in einem Jahr den Bericht ansehen will, dann muss er erst den Timestamp umrechnen und dann überlegen ob er 1h oder 2h dazu addieren muss um die wirkliche Produktionszeit zu bekommen. Das macht wohl kaum ein Kunde mit.

 

[schwimmer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und wenn du die csv-Datei mit einem normalen Texteditor (z.B. Notepad) öffnest anstatt Excel, was steht da drin?

Excel	Notepad++
1719997952212870	1719997952212.877
17199979422071800	1719997942207.1816

Die unterschiedliche Länge der Zahl kommt also nicht von Excel

 

[PN/DP]

die Zahlen sehen aus wie LREAL - mit Dezimalpunkt '.'! also auch noch abhängig von den Regionaleinstellungen bzw. der Einstellung des Dezimal Separators! Excel scheint den Punkt total zu ignorieren...
Also Öffnen mit Excel per Doppelklick ist da gar nicht zu empfehlen, sondern wenn schon mit Excel, dann erst Excel öffnen und dann importieren, da kann man den Dezimalseparator angeben (glaube ich). Oder vor dem Öffnen den Dezimalseparator umstellen.

Ich werde mal einen SR aufmachen.

Da brauchst du keinen Siemens SR aufmachen. Es liegt nicht an Siemens, sondern du öffnest/liest die csv-Daten falsch.

 

[schwimmer]

die Zahlen sehen aus wie LREAL - mit Dezimalpunkt '.'! also auch noch abhängig von den Regionaleinstellungen bzw. der Einstellung des Dezimal Separators! Excel scheint den Punkt total zu ignorieren...

Regionaleinstellung gibt es ja beim Unified nicht, es ist immer englisch

Also Öffnen mit Excel per Doppelklick ist da gar nicht zu empfehlen, sondern wenn schon mit Excel, dann erst Excel öffnen und dann importieren, da kann man den Dezimalseparator angeben (glaube ich). Oder vor dem Öffnen den Dezimalseparator umstellen.

Wenn ich es so mache, dann habe ich zwar alle Werte mit 3 bzw. 4 Nachkommastellen, die Umrechnung auf´s Datum stimmt trotzdem nicht. Zumindest kommt mal ein Datum bei raus.
1719997882198,44 / 1000000 = 1719997,882/86400+25569 = 20.1.70 21:46:38 ( sollte sein 03.07.2024 07:11:22)
..... Aufzeichnung im Archiv
1719998892210,28 / 1000000 = 1719998,892/86400+25569 = 20.1.70 21:46:39 (sollte sein 03.07.2024 07:28:12)
Selbst mit dem Import und Austausch von Dezimalpunkt zu Komma ist noch irgendetwas falsch

 

[Oberchefe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nimm mal die Formel von PN/DP und teile am Anfang nur durch Tausend anstatt einer Million. Dann bekommst du bei der Zahl 1719997882198,44 das Datum 03.07.2024 mit der Uhrzeit 09:11:22 heraus.

 

[schwimmer]

Okay, dankeschön
Bin mal gespannt was mein Kunde davon hält wenn er jeden Zeitwert anders umrechnen muss. und dann noch überlegen muss ob er jetzt eine oder zwei Stunden addieren muss.
SIEMENS hat mich jetzt auf die neue Funktion "Reporting" verwiesen, doch so wie das bei einem ersten flüchtigen Durchlesen sehe, ist das auch nicht gerade einfach für die Bediener damit zu arbeiten.

 

[PN/DP]

Regionaleinstellung gibt es ja beim Unified nicht, es ist immer englisch

Ja, dein Excel verwendet aber das Komma als Dezimaltrennzeichen. Und offensichtlich den Punkt als Zifferngruppierungszeichen und ignoriert es.
Welches Zeichen verwendet das Unified als Listentrennzeichen? Semikolon oder womöglich das Komma? Zeige uns mal eine ganze Zeile aus der csv-Datei (so wie sie in Notepad angezeigt wird).
Wenn es dem Kunde "nicht möglich" ist, das Dezimaltrennzeichen für den Import umzustellen, dann könntest du auf dem Unified HMI die csv-Datei nach dem Erzeugen öffnen und die Dezimal-Punkte durch Dezimal-Komma ersetzen (und ggf. vorher Kommas durch Semikolons). Dann muss aber das Excel zwingend auf die deutschen Regionaleinstellungen eingestellt sein. Wenn jemand die csv-Datei auf einem englich eingestellten Excel öffnet, dann gibt es wieder Kuddelmuddel.
btw: jetzt sieht man, warum es falsch ist, eine csv-Datei als Excel-Datei zu bezeichnen. Excel tut zwar so, als ob es auch csv-Dateien problemlos automatisch öffnen könnte, dem ist aber nicht so.

Wenn ich es so mache, dann habe ich zwar alle Werte mit 3 bzw. 4 Nachkommastellen, die Umrechnung auf´s Datum stimmt trotzdem nicht. Zumindest kommt mal ein Datum bei raus.
1719997882198,44 / 1000000 = 1719997,882/86400+25569 = 20.1.70 21:46:38 ( sollte sein 03.07.2024 07:11:22)

Teile nur durch Tausend anstatt 1 Mio. Das sieht man doch dass die Zahl in deinem Excel vor dem Komma nun 3 (oder 4) Ziffern kürzer ist, wenn Excel das Dezimaltrennzeichen korrekt verarbeitet.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Excel wertet das anders aus.
In Excel sind die Tage Ganzzahlen und die Uhrzeit ein Bruchteil des Tages. Das müßtest du ändern.
Am Besten trägst du einfach mal ein beliebiges Datum in eine Zelle ein und änderst dann deren Darstellung - dann siehst du es ...

Edit : oops - bin wohl "ein bißchen" spät mit der Antwort ...

 

[schwimmer]

Wenn es dem Kunde "nicht möglich" ist, das Dezimaltrennzeichen für den Import umzustellen, dann könntest du auf dem Unified HMI die csv-Datei nach dem Erzeugen öffnen und die Dezimal-Punkte durch Dezimal-Komma ersetzen (und ggf. vorher Kommas durch Semikolons). Dann muss aber das Excel zwingend auf die deutschen Regionaleinstellungen eingestellt sein. Wenn jemand die csv-Datei auf einem englich eingestellten Excel öffnet, dann gibt es wieder Kuddelmuddel.

Habe es jetzt gerade so halbwegs hinbekommen mit Java den Export des Archivs als csv-File zu bewerkstelligen. Das File über ein Skript zu öffnen, Zeichen austauschen zu lassen und wieder zu schließen, da möchte ich mich im Moment noch nicht mit befassen. Dazu bedarf es dann sicherlich doch einiges mehr an Zeit, sich mit js zu befassen.
Das Semikolon ist als Trennzeichen eingestellt, dass klappt auch so weit beim Import in Excel.
Ich werde wohl die Zeiten als String ans HMI bzw. Archiv zu übergeben, dann umgehe ich den ganzen Aufwand und die Fehlerquellen beim Importieren.

 

[PN/DP]

Ich werde wohl die Zeiten als String ans HMI bzw. Archiv zu übergeben, dann umgehe ich den ganzen Aufwand und die Fehlerquellen beim Importieren.

Kann man das anpassen, dass der Zeitstempel als String oder als Zahlenwert in die csv-Datei geschrieben wird?

Schreibst du sonst keine xREAL-Werte in die csv-Datei? Weil auch die werden dann von Excel falsch angezeigt!
Schreibe zumindest für den Kunden in der Dokumentation dazu, dass das Dezimaltrennzeichen "Punkt" verwendet wird und beim Öffnen mit Excel umgestellt werden muss. Oder noch besser: schreibe den Hinweis als Kommentar in die Kopfzeilen der csv-Datei, dann sieht es der Anwender beim Öffnen der Datei.

 

[schwimmer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kann man das anpassen, dass der Zeitstempel als String oder als Zahlenwert in die csv-Datei geschrieben wird?

Nein, der Zeitstempel wird vom System beim auslesen erzeugt und der ist auch immer UTC. Ob und wie der beim auslesen beeinflusst werden kann habe ich noch nicht herausgefunden. Als UTC ist er allerdings nicht brauchbar oder nur bedingt, denn dann müsste der Wert in Excel erst in eine Zeit konvertiert werden und anhand vom Datum muss dann überlegt werden ob 1h oder 2h addiert werden müssen um zusehen wann die Werte aufgezeichnet wurden. Damit kann ich dem Kunden garantiert nicht kommen.
Ich dachte daran einen eigenen Zeitstempel als String ins Archiv zu schreiben und diesen dann auch in das csv-File zu exportieren, dann mus nichts mehr umgerechnet werden.

Oder noch besser: schreibe den Hinweis als Kommentar in die Kopfzeilen der csv-Datei, dann sieht es der Anwender beim Öffnen der Datei.

Die Idee ist nicht schlecht, mal sehen ob ich das in js hinbekomme....

 

[PN/DP]

Bin mal gespannt was mein Kunde davon hält wenn er jeden Zeitwert anders umrechnen muss. und dann noch überlegen muss ob er jetzt eine oder zwei Stunden addieren muss.

Für den Kunde könnte man die Zeitangaben in Lokalzeit in die csv-Datei schreiben. Oder in den csv-Kopfzeilen darauf hinweisen "alle Zeitangaben in UTC". Für beides muss man aber das Siemens-Snipped anpassen...

 

[schwimmer]

Für den Kunde könnte man die Zeitangaben in Lokalzeit in die csv-Datei schreiben.

Diesen Zeitstempel der zu jedem Wert aus dem Archiv ausgegeben wird, kann ich leider nicht beeinflussen, bzw. habe ich nichts gefunden wie ich den vorm Schreiben in das csv-File beeinflussen / umrechnen kann.

csvData += LoggTag.Name + delimiter + loggedTag.TimeStamp.toString() + delimiter + loggedTag.Value + delimiter + loggedTag.Quality + "\n";

Lediglich wie ich den Timestamp in einen String wandle habe ich gefunden, somit entfällt schon mal das Umrechnen in Excel.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Als UTC ist er allerdings nicht brauchbar oder nur bedingt, denn dann müsste der Wert in Excel erst in eine Zeit konvertiert werden und anhand vom Datum muss dann überlegt werden ob 1h oder 2h addiert werden müssen um zusehen wann die Werte aufgezeichnet wurden. Damit kann ich dem Kunden garantiert nicht kommen.

Die Umrechnung in Lokalzeit könnte man in Excel automatisieren, aber nicht direkt in der csv-Datei. Da müsste man eine "Loader"-Exceldatei zum einlesen der csv-Datei schreiben. Da kann man dann auch die Anpassung der Dezimalpunkte zum für Excel jeweils eingestellten Dezimaltrennzeichen miterledigen und die Umrechnung von numerischen Zeitstempeln und das Anzeigeformat der Zellen erledigen.

Mit Unified kenne ich mich nicht aus. Für csv-Exporte für den Kunde aus dem Archiv von WinCC verwende ich aber immer Lokalzeit als String. Das sieht dann nur bei der Umschaltung zu Winterzeit (Ende Oktober) komisch aus, dass da Werte 2x für den anscheinend gleichen Zeitraum drin stehen (und Ende März anscheinend 1 Stunde fehlt) - da kommt der Anwender aber meist selber drauf, dass das an der Sommerzeit liegt. Um diese Uneindeutigkeiten zu vermeiden, werden bei professionellem Logging die Zeitstempel in UTC verwendet.

 

[schwimmer]

Die Umrechnung in Lokalzeit könnte man in Excel automatisieren, aber nicht direkt in der csv-Datei. Da müsste man eine "Loader"-Exceldatei zum einlesen der csv-Datei schreiben. Da kann man dann auch die Anpassung der Dezimalpunkte zum für Excel jeweils eingestellten Dezimaltrennzeichen miterledigen und die Umrechnung von numerischen Zeitstempeln und das Anzeigeformat der Zellen erledigen.

Dazu fehlen mir die Kenntnisse in Excel, benutze es eher selten und wenn dann nur für einfach Tabellen. Der ganze Aufbau vom csv-File ist ja auch für eine weitere Bearbeitung nur bedingt geeignet. Aber da die Datensicherung nichts kosten soll und eigentlich nur dazu dient, mal Prozesswerte zu kontrollieren wenn Tage oder Wochen später Rückfragen kommen, sollte es wohl reichen wenn die Dateien manuell importiert und angepasst werden müssen.

Für csv-Exporte für den Kunde aus dem Archiv von WinCC verwende ich aber immer Lokalzeit.

Habe ich bisher auch immer so gemacht, nur kann ich diesen Archiv-TimeStamp nicht beeinflussen. Deshalb ja der Gedanke mit einem eigenen Zeitstempel als String. Die Aufzeichnungen beim Kunden, wann etwas produziert wurde sind ja auch Lokalzeit und nicht UTC. Der Bezug sollte ja auch ohne umrechnen vorhanden sein.

 

[PN/DP]

Diesen Zeitstempel der zu jedem Wert aus dem Archiv ausgegeben wird, kann ich leider nicht beeinflussen, bzw. habe ich nichts gefunden wie ich den vorm Schreiben in das csv-File beeinflussen / umrechnen kann.

csvData += LoggTag.Name + delimiter + loggedTag.TimeStamp.toString() + delimiter + loggedTag.Value + delimiter + loggedTag.Quality + "\n";

Lediglich wie ich den Timestamp in einen String wandle habe ich gefunden, somit entfällt schon mal das Umrechnen in Excel.

Wenn du den Zeitstempel in String umwandeln kannst, dann kannst du auch loggedTag.TimeStamp vor dem loggedTag.TimeStamp.toString() in Lokalzeit umrechnen. Gibt es dafür eine fertige Javascrpt-Methode oder kann man dafür getTimezoneOffset() verwenden? Ich weiß jetzt nicht, ob getTimezoneOffset() den zum Datum passenden Offset liefert oder den gerade aktiven Offset. Das müsste man ausprobieren. Wenn das hier niemand weiß, dann kanst du ja wieder im Siemens-Forum oder den Siemens Support fragen.