Das Speicherformat

In diesem Kapitel wird das dateibasierte Speicherformat beschrieben. Dabei werden die Textkodierung der Dateien, die Ordnerstruktur, die Ablage von Programmierobjekten und ihrer Metadaten sowie den Quelltext in Strukturiertem Text und in den grafischen Sprachen erläutert.

Textkodierung und Formatierung

Bei jeder Datei, die von CODESYS File-Based Storage geschrieben wird, werden dieselben Konventionen eingehalten. Dadurch bleiben Projekte zwischen Betriebssystemen portabel und es entstehen saubere Unterschiede in der Versionsverwaltung.

Kodierung: Alle Textdateien werden in UTF-8 ohne Byte Order Mark (BOM) geschrieben. Beim Lesen einer bestehenden XML-Datei wird die angegebene Kodierung verwendet. Ein vorhandenes Byte Order Mark wird toleriert.
Zeilenenden: Dateien werden mit dem Zeilenvorschubzeichen (\n) geschrieben. Beim Lesen werden sowohl der Zeilenvorschub als auch das Windows-Zeilenende (\r\n) akzeptiert.
Zeilenende in der Versionsverwaltung
Konfigurieren Sie die Versionsverwaltung so, dass Zeilenvorschübe als Zeilenende erhalten bleiben, um unnötige Unterschiede zu vermeiden.
Einrückung: JSON- und XML-Dateien werden mit einem Tabulatorzeichen pro Verschachtelungsebene eingerückt.

Ordner

Jeder Ordner im Projektbaum wird zu einem gleichnamigen Verzeichnis. Ein Ordner besitzt optional eine Metadatendatei mit dem Namen .folder_meta.json. In dieser Datei werden die Objekt-GUID des Ordners und seine Propertys gespeichert:

{
	"objectGuid": "1b3a0c5e-...",
	"properties": {
		"PropertyName": "PropertyValue"
	}
}

In CODESYS 3 besitzt jeder Ordner eine Objekt-GUID. Diese wird in die Datei .folder_meta.json geschrieben, damit der Ordner auch nach Umbenennungen und Verschiebungen weiterhin verfolgt werden kann. Das Feld properties wird nur geschrieben, wenn der Ordner Propertys besitzt, sonst entfällt es. In CODESYS 4 besitzt ein Ordner keine Objekt-GUID. Ein Ordner ohne gespeicherte Metadaten besitzt keine Datei .folder_meta.json.

Programmierobjekte

Jedes Programmierobjekt wird als einzelne Textdatei gespeichert. Der Dateiname hat die folgende Form:

<Objektname>.<Klasse>.<Sprache>

Der Klassenteil kennzeichnet den Objekttyp und der Sprachteil kennzeichnet die Implementierungssprache. Konkret lauter der Sprachteil für Strukturierten Text st. Ein Funktionsbaustein in Strukturiertem Text heißt beispielsweise Timer.fb.st.

Objekttyp	Klassenteil	Beispiel
Programm	`prg`	`Main.prg.st`
Funktionsbaustein	`fb`	`Timer.fb.st`
Funktion	`fn`	`Add.fn.st`
Methode	`meth`	`Start.meth.st`
Aktion	`act`	`Reset.act.st`
Transition	`trans`	`Step1.trans.st`
Eigenschaft eines Programmierbausteins	`prop.st`	`Enabled.prop.st`
Schnittstelle	`itf`	`IMotor.itf`
Schnittstellenmethode	`meth`	`Run.meth`
Schnittstelleneigenschaft	`prop`	`Speed.prop`
Struktur (DUT)	`struct`	`Point.struct`
Aufzählung (DUT)	`enum`	`Color.enum`
Alias (DUT)	`alias`	`Distance.alias`
Union (DUT)	`union`	`Value.union`
Globale Variablenliste	`gvl`	`Globals.gvl`

Ein Objekt mit untergeordneten Objekten (beispielsweise ein Funktionsbaustein mit Methoden) wird als Verzeichnis gespeichert, dessen Name mit einem Zirkumflex (^) endet. Das Objekt selbst ist die Datei in diesem Verzeichnis. Die untergeordneten Objekte liegen daneben:

Timer.fb.st^/
    Timer.fb.st    (der Funktionsbaustein selbst)
    Start.meth.st    (eine Methode)
    Stop.meth.st    (eine Methode)

Objekt-Metadaten

Wenn ein Objekt Metadaten enthält, die sich nicht anders rekonstruieren lassen, wird die Datei mit einem Metadaten-Kommentar begonnen. Beispiele dafür sind eine stabile Objekt-GUID oder Objekt-Eigenschaften. Der Kommentar wird mit (* METADATA … *) gekennzeichnet. Die Metadaten darin werden als JSON abgelegt.

(* METADATA
{
	"v3Meta": {
		"objectGuid": "e75fc257-..."
	}
}
*)

Wenn ein Objekt keine Metadaten enthält, wird kein Metadaten-Kommentar geschrieben und die Datei beginnt direkt mit dem Objektkopf.

Die Projektinformationen (Titel, Version, Autor, Firma, Beschreibung und weitere Einstellungen) werden in der Datei ProjectInfo.json im Projektstammverzeichnis gespeichert.

Quelltext von Objekten in Strukturiertem Text

Strukturierter Text wird als reiner Text ohne Marker gespeichert. Der Deklarationsteil wird immer zuerst geschrieben, direkt gefolgt vom Implementierungsteil.

Beispiel 1. Beispiel

Das folgende Beispiel zeigt das Strukturierter-Text-Programm PLC_PRG in der Datei PLC_PRG.prg.st.

PROGRAM PLC_PRG
VAR
    nCounter : INT;
END_VAR
nCounter := nCounter + 1;
END_PROGRAM

Quelltext grafischer Sprachen

Andere Sprachen als Strukturierter Text, etwa die grafischen Sprachen Kontaktplan (KOP), Funktionsplan (FUP), Continuous Function Chart (CFC) und Ablaufsprache (AS), lassen sich nicht als Strukturierter Text schreiben. Für diese Sprachen wird die Deklaration weiterhin als reiner Text gespeichert. Der Implementierungsteil wird jedoch von zwei Markerzeilen eingeschlossen, die die jeweilige Sprache benennen.

FUNCTION_BLOCK TSSend
VAR_INPUT
    xExecute : BOOL;
END_VAR
__BEGIN_IMPLEMENTATION('CFC')
{
    ... die Implementierung im eigenen Format der Sprache ...
}
__END_IMPLEMENTATION
END_FUNCTION_BLOCK

Mit dem Marker __BEGIN_IMPLEMENTATION('<Sprache>') wird die Implementierung eröffnet und die Sprache benannt, zum Beispiel LD für Kontaktplan, FBD für Funktionsplan, CFC oder SFC für Ablaufsprache. Mit dem Marker __END_IMPLEMENTATION wird sie geschlossen. Alles zwischen den Markern wird im eigenen Textformat der jeweiligen Sprache abgelegt. Für die eingebauten grafischen Sprachen wird dieses Format als JSON verwendet, eingerückt mit einem Tabulatorzeichen pro Verschachtelungsebene.

Die Marker sorgen dafür, dass die Deklaration unabhängig vom Inhalt des Implementierungsteils zuverlässig davon getrennt wird. Für Strukturierten Text werden keine Marker benötigt und verwendet.

Objekte ohne natives Format

Nicht jeder Objekttyp besitzt eine eigene Textdarstellung. Objekte wie Gerätekonfigurationen und Taskkonfigurationen werden in einer Ausweichdatei mit der Endung xml.v3 gespeichert, die die ursprüngliche CODESYS-Serialisierung umschließt. Diese Dateien bleiben Textdateien und erzeugen weiterhin zeilenweise Unterschiede in der Versionsverwaltung. Solche Objekte lassen sich später in ein natives Format migrieren, sobald eines zur Verfügung steht

Für weitere Informationen siehe: Objekte migrieren

Wenn sich der Inhalt eines Objekts überhaupt nicht interpretieren lässt, bleibt das Objekt unverändert erhalten, damit keine Informationen verloren gehen.

In diesem Abschnitt: