Ordnerstruktur S7 Projekt

Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe das mit Excel schon etwas fortgeführt.
Wenn ich CRDATAT1 unverändert lasse und CRDATAE2 und das Datum wie nachfolgende herunterziehe, berechnet Excel das Datum und die Uhrzeit bis auf ein paar Sekunden auch korrekt.
Dennoch habe ich die Systematik noch nicht verstanden und ich habe auch ein anderes Datum (02.03.2151) bei undefinierten Werten von CRDATE1 und CRDATE2.
:confused:
Wo lässt Du in Deiner Tabelle CRDATE1 unverändert? Du wechselst zwischen den Werten 0, 1875734464 und -1875734464.
Wo sind CRDATE1 und CRDATE2 undefiniert? Meinst Du damit die wohldefinierten Nullen?
Woher weisst Du, dass Excel das Datum und die Uhrzeit bis auf ein paar Sekunden korrekt berechnet? Womit vergleichst Du?
Ich habe die Systematik Deines Herunterziehens nicht verstanden.
Du müsstest zuvor einen Plan haben bzw. eine bestimmte Absicht damit verfolgen. Kannst Du darüber etwas sagen?
Welches ist der Zusammenhang der Spalte 'Erstellt am Datum' mit den beiden anderen Spalten? Negative Datumswerte oder Zeitwerte mag Excel nämlich gar nicht.

Nachfolgend der Excel Datumswert plus Zeitwert zu Deiner Spalte 'Erstellt am Datum':
Code:
     Datum+Zeit      Datwert+Zeitwert
2151-03-02 02:00:00    91738,083333333
2151-03-02 16:06:03    91738,670868056
2151-03-02 16:06:57    91738,671493056
1984-01-17 18:33:56    30698,773564815
1984-01-17 18:34:50    30698,774189815
2158-04-03 22:02:54    94327,918680556
2158-04-03 22:03:49    94327,919317130
 
Zuletzt bearbeitet:
Die negativen Werte sind eben so wie sie in der dBase Datei gespeichert werden und du sie wieder auslesen kannst (z.B. mit Access). Wie schon geschrieben macht Siemens das an anderer Stelle auch so, dass in einer Integer Spalte ein spezial codierter Zeitstempel gespeichert wird und nicht der Zeitstempel von dBase verwendet wird. Diesen musst du eben als Integer auslesen, in die einzelnen Bytes zerlegen und daraus den richtigen Zeitstempel generieren.
 
So wie es aussieht muss crdate1 und crdate1 zu einem 64 Bit Integer kombiniert werden, was dann die Anzahl x100 Nanosekunden seit dem 1.1.1600 angibt.

Mit deinem Beispielzeitstempel 18.10.2020 15:37:54
CRDATE1= -507958783
CRDATE2= 30844243

dez 30844243 = hex 1D6A553
dez -507958783 = hex E1B92A01

kombiniert
hex 1D6A553E1B92A01

entspricht
dez 132475018741885441

mal 10^-7 =
13247501874.1885441 Sekunden

Wenn du das zurückrechnest kommst du je nach verwendetem Kalender (das ist noch genau zu ergründen) bei 1.1.1600 heraus.


Der "Zuletzt geändert am" in Step7 ist identisch mit "Geändert" Zeitstempel vom Windows Explorer. Der wird so wie es aussieht nicht selber gespeichert sondern aus den Dateieigenschaften ausgelesen. Wenn du die .awl mit einem Texteditor außerhalb von Step7 änderst, dann funktioniert das mit dem Zeitstempel nämlich auch noch.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich hätte eher Vermutet, das es die Windows FILETIME-Struktur ist.
https://docs.microsoft.com/de-de/windows/win32/api/minwinbase/ns-minwinbase-filetime

Bei folgendem Programm
Code:
#include <Windows.h>
#include <stdio.h>

int main() {
    FILETIME ft = {0xE1B92A01,0x1D6A553};

    SYSTEMTIME st = {};
    FileTimeToSystemTime(&ft, &st);

    printf("%u.%u.%u  %u:%u:%u.%u", st.wDay, st.wMonth, st.wYear,
        st.wHour, st.wMinute, st.wSecond, st.wMilliseconds);

    return 0;
}

kommt dies raus: 18.10.2020 13:37:54.188

Das ist der Korrekte Wert, nur in UTC. Wenn man jetzt noch die Zeitzone auf MESZ umrechnet (+2 Stunden) kommt man auf den Wert.
 
Hallo,

schon mal vielen Dank für eure vielen nützlichen und sehr konstruktiven Hilfestellungen.
Ich bin gestern leider nicht weiter dazu gekommen, mir das weiter anzuschauen.
Doch ich werde mir gleich eure ganzen Tipps vornehmen und versuchen, damit das Rätsel vollständig zu lösen.
Ich werde hier auf jeden Fall auch meine Erkenntnisse weiter teilen, so wie ihr es schon getan habt.

Danke

MfG

sinumerik.user
 
Was mich noch irritiert:
Aber was nun richtig ist, sollte sich ja über vorhandene Werte berechnen lassen, also CRDATE 1 + CRDATE2 aus Step 7.

Hier steht:
Contains a 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601 (UTC )
https://docs.microsoft.com/de-de/wi...se/ns-minwinbase-filetime?redirectedfrom=MSDN

Hier steht:
ausgedrückt in 100-Nanosekunden-Schritten seit dem 1. Januar 1600, 0:00 Uhr.
http://www.selfadsi.de/ads-attributes/user-lastLogonTimestamp.htm
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich kann nun bestätigen, dass der Zeitstempel in CRDATE1 und CRDATE2 der FILETIME-Struktur entspricht.
Wie von Thomas_v2.1 beschrieben, müssen CRDATE2 und CRDATE1 zu einem 64 Bit Integer kombiniert werden.

CRDATE1= -507958783
CRDATE2= 30844243

dez 30844243 = hex 1D6A553
dez -507958783 = hex E1B92A01

kombiniert
hex 1D6A553E1B92A01

entspricht
dez 132475018741885441


CRDATE1= -507958783
CRDATE2= 30844243

dez 30844243 = hex 1D6A553
dez -507958783 = hex E1B92A01

kombiniert: hex 1D6A553E1B92A01 = dez 132475018741885441

Diese 64 Bit Integer Ziffernfolge repräsentiert Intervalle von 100 Nanosekunden seit dem 1. Januar 1601 im UTC Format.
Wie Windoze damit schon richtig beschrieben hat, entspricht der Zeitstempel damit dem 18.10.2020 13:37:54.188 UTC.
Unter Berücksichtigung der Zeitzone und der Sommerzeit müssen nun noch 2 Stunden addiert werden.
So ergibt sich die gesuchte Angabe von Datum und Uhrzeit 18.10.2020 15:37:54:188.
Handelt es sich um ein Datum im Bereich der Winterzeit muss nur 1 Stunde für die Zeitzone addiert werden.

Ich habe das nun mit einigen Quellen ausprobiert und konnte das Datum so immer präzise berechnen.

Vielen Dank für eure Unterstützung.
 
Zuletzt bearbeitet:
Hallo,

wo und wie werden in Step7 Projekten verwendete GSD Dateien in der Ordnerstruktur oder Datenbanken des Projekts gespeichert?
Das Projekt muss irgendwo diese Dateien enthalten, da die GSD Dateien ja auch über das Projekt automatisch installiert werden, wenn in der aktuelle Step 7 Installation diese GSD Dateien noch nicht installiert sind. In den DBF Dateien habe ich bisher nur den Namen der verwendeten GSD Datei, den Namen des Symbolbildes der Station und einige Parameter der Station gefunden. Eine Suche nach Strings aus der GSD Datei z.B. Revision über das ganze Step 7 Projekt brachte kein Ergebnis. Daher vermute ich, dass die verwendeten GSD Dateien irgendwie zusammen gepackt werden. Also z.B. in ein ZIP Archiv. Wenn eine GSD Datei beim Import des Projekts automatisch installiert wurde, ist diese GSD Datei ja absolut identisch zu der originalen Datei welcher der erste Autor des Projekts verwendet hat. Sie enthält somit alle Kommentare und Parameter der originalen GSD Datei. Aus diesem Grund bin ich der Überzeugung, das die GSD Dateien unter Umständen irgendwie verschlüsselt in dem Projektverzeichnis zu finden sein müssen.
Ich bitte um Unterstützung wo ich diese Daten finden kann.

Mit bestem Gruß

sinumerik.user
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe mich auch schon gefragt, was denn alles online in der SPS gespeicher wird. Denn einige Informationen wie der Name der Verwendeten GSD-Datei sind auch in den Systemdaten vorhanden. Aber die gesamte GSD-Datei vermute ich nicht, zumindest nicht online.
im Ordner Global liegt dem Namen nach vermutlich komprimiertes ab (Dateiendung .compressed).
Du meinst S7hCompressedMetadata.cmf? Oder liegt das an meiner Step7 5.5 Version. Dort habe ich noch eine S7hMetaData.umf, falls das die unkomprimierte Version ist, dann sind dort die Daten der GSD-Datei jedenfalls nicht enthalten.
 
bei mir liegt da beispielsweise in einem Projekt eine Datei namens gsdml-v2.2-hilscher-cifx re pns-20120224.compressed.

Das riecht für mich stark nach GSD.
 
Das habe ich eben auch mal ausprobiert, mit einem Danfoss FC an Profibus, da wird dort nichts abgelegt. Aber an der Datei gibt es Änderungen. Vielleicht ist das bei Profinet nochmal anders gelöst (hinten angeflanscht).
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
ich habe es auch gerade ausprobiert.
Wenn man Stationen im Bus hinzufügt oder entfernt, ändert sich die Datei S7hCompressedMetadata.cmf.
Habe mir das auch im Hex-Editor angeschaut, doch konnte ich noch nichts spannendes feststellen.
Auch beim Vergleich von zwei Dateien noch nicht.
Es ist auch die Frage wie ist die Datei komprimiert?
 
Es scheint zumindest nicht die ganze Datei komprimiert zu sein, denn es ändern sich nur einzelne Teile davon wenn man etwas ändert. Typische Werte für einen zlib Header sind Werte wie 78 9c und dergleichen. Davon findet man einige Vorkommen, müsste man nochmal prüfen ob untypisch oft. Step7 wurde ja noch umfangreich mit den MFC programmiert, vielleicht gibt es da fertige Methoden um beispielsweise ein Objekt in einer Datei zu sichern.
 
Du meinst MFC = Microsoft Foundation Classes?
In meiner Datei habe ich leider noch nichts ähnliches zu nachfolgender Aufstellung gefunden:

CMF | FLG
0x78 | 0x01 - No Compression/low
0x78 | 0x9C - Default Compression
0x78 | 0xDA - Best Compression
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also in der S7hCompressedMetadata scheint es nicht angelegt zu werden. Ich habe mal ein Projekt ohne Profibusteilnehmer gesichert, und dann ein Profibusteilnehmer ergänzt und dann die Dateien verglichen. Da sind keine Unterschiede zu finden.
Aber es scheint irgendwo komprimiert gespeichert zu werden, mit einer reinen Textsuche findet man nichts aus der GSD-Datei wieder.
 
Mache ein Testprojekt und eine Kopie davon. Dann projektiere ein Gerät mit GSD Datei und speichern und schau welche Dateien neu/geändert sind. Oder ändert sich zuviel?
 
Zurück
Oben