Skip to main content

Dateibasierte Speicherung

In CODESYS 3 wird ein Projekt in einer einzigen binären Datei abgelegt. Der Inhalt dieser Datei lässt sich außerhalb der Entwicklungsumgebung nicht lesen und nicht erzeugen. Ein Vergleich zweier Projektstände zeigt keine lesbaren Unterschiede, und zwei Bearbeiter geraten schon dann in Konflikt, wenn sie verschiedene Objekte ändern.

Mit der Installation des Add-ons CODESYS File-Based Storage wird in CODESYS 3 ein dateibasiertes Speicherformat bereitgestellt, das mit dem Speicherformat in CODESYS 4 kompatibel ist. Es ermöglicht die Konvertierung des dateibasierten Formats in CODESYS 4 zum binären Format in CODESYS 3 und zurück. 

In CODESYS 4 wird ein Projekt in einem offenen, dateibasierten Format verwaltet. Jedes Objekt wird in einer eigenen Textdatei abgelegt und die Projektstruktur ist die Ordnerstruktur im Dateisystem. Einen Objektmanager gibt es nicht.

Daraus ergeben sich die folgenden Vorteile:

  • Ein Objekt wird mit jedem Texteditor gelesen und bei Bedarf auch bearbeitet.

  • Der Vergleich zweier Projektstände zeigt die inhaltlichen Änderungen im Klartext.

  • Änderungen an verschiedenen Objekten stehen nicht in Konflikt zueinander.

  • Ein Projekt wird in einer Versionsverwaltung wie Git, SVN oder Mercurial verwaltet. Dadurch wird das Projektarchiv aus CODESYS 3 entbehrlich.

  • Die üblichen Abläufe der Versionsverwaltung wie Merge-Request, Pull-Request und Code-Review sind nutzbar, da die Änderungen auch im Webportal der Versionsverwaltung einsehbar sind.

Für weitere Informationen siehe: Workspaces und Dateitypen

Quelltext und erzeugte Dateien

Nicht alles, was im Projektordner liegt, gehört zum Quelltext. CODESYS 4 legt neben den Objektdateien auch Zwischenergebnisse, aufgelöste Bibliotheken und anwenderbezogene Einstellungen ab. Diese Dateien werden bei Bedarf neu erzeugt.

Ordner

Lage

Inhalt

.compileContexts

Im Ordner <application name>.iecapp^

Compile- und Referenzkontexte

.intermediate

Im Ordner <application name>.iecapp^

Temporäre Dateien, die zu Diagnosezwecken erstellt werden

.bootapp

Im Ordner <application name>.iecapp^

Erzeugte Offline-Bootapplikation, wenn kein Pfad angegeben ist

.library-cache

Oberste Ebene in .fbsdev und .fbslib

Aufgelöste, kompilierte Bibliotheken

*.user

Oberste Ebene im Projekt

Projekteinstellungen und Präferenzen des Anwenders

Das Verzeichnis wird erst angelegt, wenn zum ersten Mal eine benutzerbezogene Projekteinstellung gespeichert wird.

<workspace name>.fbsws.user

Parallel zur Workspace-Datei

Workspace-Einstellungen und Präferenzen des Anwenders

Der Cache der Gerätebeschreibungen gehört dagegen zum Projekt. Die Gerätebeschreibungen liegen als Textdateien vor und werden auch versioniert.

Zeichensatz, Zeilenumbrüche und Einrückung

Damit ein Vergleich zweier Projektstände die inhaltlichen Änderungen zeigt und nicht Formatänderungen, werden in CODESYS 4 alle Dateien nach festen Regeln geschrieben.

Eigenschaft

Regel

Zeichensatz für IEC-Quelltext und JSON-Dateien

UTF-8 ohne BOM (Byte Order Mark)

Dateien sind am Anfang ohne eine Kennzeichnung für Informationen über die verwendete Zeichenkodierung.

Zeichensatz für XML-Dateien

Bevorzugt UTF-8

Bestandsdateien wie Gerätebeschreibungen werden nach ihrer Meta-Deklaration gelesen

Zeilenumbruch beim Schreiben

LF (Line Feed)

Zeilenumbruch beim Lesen

LF und CRLF (Carriage Return Line Feed)

Einrückung in JSON- und XML-Dateien

1 Tabulator je Ebene

Reihenfolge der Einträge in JSON-Objekten

Deterministisch

Dateien werden immer mit dem Zeilenendeformat LF( 0x0A) gespeichert. Beim Einlesen werden sowohl LF als auch CRLF (0x0D, 0x0A) unterstützt. Dadurch bleiben Dateien auch dann lesbar, wenn sie außerhalb von CODESYS 4 mit einem Editor bearbeitet wurden, der das Zeilenendeformat CRLF verwendet.

Projekte in der Versionsverwaltung

Die deterministische Reihenfolge in JSON-Objekten und die Einrückung mit Tabulatoren haben denselben Zweck: Ein geändertes Objekt erzeugt nur dort einen Unterschied, wo sich der Inhalt geändert hat.

. Was unter Versionsverwaltung gehört:
  • Objektdateien

  • Konfigurationsdateien des Projekts wie Libraries.json und ProjectInfo.json

  • Lock-Datei Libraries.lock.json

  • Workspace-Datei

Was nicht unter Versionsverwaltung gehört sind die aus dem Quelltext erzeugten Ordner und Dateien. Sie enthalten temporäre Daten, Binärdateien oder anwenderbezogene Einstellungen. Andere Entwicklungsumgebungen verfahren ebenso, beispielsweise mit den Ordnern bin und obj eines C#-Projekts.

Bei den folgenden Ordnern ist der Ausschluss eine Voreinstellung und keine Vorschrift. Wenn Binärdateien in Ihrer Versionsverwaltung unproblematisch sind, dann können Sie die Ordner in die Versionsverwaltung mit aufnehmen.

Von der Versionsverwaltung ausgeschlossene Dateien:

  • .library-cache

  • .user

  • <workspace name>.fbsws.user

Stellen Sie die Versionsverwaltung so ein, dass Dateien beim Einchecken in das LF-Format (Line Feed) umgewandelt und beim Auschecken unverändert abgerufen werden. Unter Git erreichen Sie das mit den folgenden Einstellungen.

core.eol = lf
core.autocrlf = false

Legen Sie die Ausschlüsse je Projektordner in einer eigenen Datei mit der Endung .gitignore ab, und die Einstellungen zu den Zeilenumbrüchen in einer eigenen Datei mit Endung .gitattributes. Beide Dateien gehören selbst unter Versionsverwaltung, weil die Regeln sonst nicht wirken.

Dateien außerhalb von CODESYS 4 bearbeiten

Die Objektdateien eines Projekts sind reiner Text. Bearbeiten Sie die Dateien bei Bedarf außerhalb von CODESYS 4, beispielsweise beim Auflösen eines Merge-Konflikts oder bei einer Änderung, die viele Objekte gleichartig betrifft.

Halten Sie dabei die folgenden Bedingungen ein:

  • Die Deklaration bleibt syntaktisch gültig. Die Deklaration wird verwendet, um sie von der Implementierung zu trennen.

  • Der Zeichensatz bleibt UTF-8 ohne BOM.

  • Die Ordnerstruktur bleibt unverändert, weil sie die Projektstruktur ist.

Wenn Sie einen Merge-Konflikt außerhalb von CODESYS 4 auflösen, sollten Sie das Ergebnis anschließend in der CODESYS 4-IDE prüfen. Ein Merge erzeugt unter Umständen Beziehungen zwischen Objekten, die in einem Projekt nicht zulässig sind. Ein Beispiel ist ein Programmierbaustein, der einem anderen Programmierbaustein untergeordnet ist.

Dateien der Versionsverwaltung wie .gitignore liegen im Projektordner und erscheinen daher auch im Workspace-Navigator.