Speicherformat
Es stehen zwei Implementierungen der Schnittstelle IDataStorage zur Verfügung: ASCIIDataStorage und BinaryDataStorage.
Für beide Formate gilt: Die erste Variable die gespeichert wird, ist die reservierte Variable ___xCompressTags vom Typ BOOL. Ihr Wert gibt an, ob die Instanzpfade komprimiert gespeichert werden. Falls ein Integritätsobjekt geschrieben wird, dann wird es als letzte Variable mit Namen ___Integrity vom Typ BOOL mit Wert TRUE geschrieben.Alle persistenten Variablen außer diesen reservierten Variablen werden in der Reihenfolge nach Ihrem vollen Instanzpfad sortiert gespeichert. Dabei ist es egal ob die Instanzpfade komprimiert werden oder nicht.
Tipp
Falls die Daten durch den Anwender verändert werden, muss dieser sicherstellen, dass die Sortierreihenfolge beibehalten wird.
ASCII-Format
ASCIIDataStorage schreibt jeweils den Instanzpfad der persistenten Variablen (möglicherweise gepackt), den Typ und den Wert als String in eine Datei. Dabei trennt ein Tabulatorzeichen den Namen und das restliche Datum (änderbar durch Parameter codbySeparator). Beim Lesen wird eine Konvertierung durchgeführt. Deshalb kann die Datei auch extern editiert werden. Zeilen müssen mit "\r\n“ getrennt werden (Windows-Konvention). Zeilen die mit einem Strichpunkt beginnen, werden beim Einlesen ignoriert und beim erneuten Speichern nicht wieder eingefügt.
Format einer ASCII-Datei:
{timestamp}\r\n
{instance path}{bySeparator}{Typ}:{value}\r\n
…
{instance path}{bySeparator}{Typ}:{value}\r\nDer Zeitstempel gibt den Zeitpunkt an, zu dem das Speichern angestoßen wurde. Er wird als DATE_AND_TIME- Literal geschrieben (beispielsweise. DT#2012-01-11-15:11:09).
Behandlung von REAL und LREAL-Variablen:
Die Werte der Variablen werden als ST-Literale geschrieben. REAL- und LREAL-Werte werden gesondert behandelt, da die Konvertierung in Dezimalbrüche und von Dezimalbrüchen nur schwierig verlustfrei zu implementieren ist. Um dennoch einen Genauigkeitsverlust zu vermeiden und gleichzeitig die Lesbarkeit und Änderbarkeit der ASCII-Datei zu bewahren, werden sie in einem Hexadezimal-Format gespeichert, das leicht ohne Genauigkeitsverlust berechnet werden kann. Der (ungenaue) Dezimalbruch wird als Kommentar dahinter ausgegeben. Beim Einlesen werden sowohl das Hexadezimalformat als auch das ST-Dezimalformat unterstützt, so dass ein Anwender den Wert einfach auf einen neuen Dezimalbruch ändern kann. Beim Einlesen wird alles ignoriert, was hinter dem Hexadezimalformat steht.
Das Hexadezimalformat ist wie folgt definiert:
F16#{Mantissa}H{Exp} | F16#NaN | F16#+Inf | F16#-Inf
{Mantissa} ::= {HexNumeral}
{Exp} ::= {HexNumeral}
{HexNumeral} ::= [+-]?[1-9A-F][0-9A-F]*Wenn m die durch die Mantisse dargestellte Zahl und e die durch den Exponenten dargestellte Zahl ist, dann ist der Wert der gesamten dargestellten Zahl m * 16^e.
lr1 LREAL:F16#F0H-3 0.05859375
Binärformat
BinaryDataStorage speichert die Daten im Binärformat ab. Darauf folgt ein Zeitstempel (Typ DATE_AND_TIME). Es folgen die einzelnen Variablen.
Komprimierte Archive
Die Variablenwerte werden jeweils mit Pfad und Namen (im Pfad sind weder Applikation noch Gerätenamen enthalten) abgelegt, allerdings in einer kompakten Schreibweise, um Ressourcen und Zeit zu sparen.
Die Instanzpfade müssen in jedem Fall (ob gepackt oder nicht) korrekt nach dem vollen Instanzpfad sortiert sein. Die Sortierung ist alphabetisch, wobei aber Array-Indizes numerisch sortiert werden.
Objekte | Verkürzte Repräsentation |
|---|---|
|
|
|
|
|
|
|
|