Format de stockage

Les mêmes conventions sont suivies pour chaque fichier écrit par CODESYS File-Based Storage Cela permet de garantir la portabilité des projets entre les systèmes d'exploitation et de créer des différences nettes entre les systèmes de contrôle de version.

Chaque dossier de l'arborescence du projet devient un répertoire portant le même nom. Un dossier peut contenir un fichier de métadonnées nommé .folder_meta.json Ce fichier stocke l'identifiant unique global (GUID) de l'objet dossier et ses propriétés :

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

Dans CODESYS 3 Chaque dossier possède un GUID d'objet. Celui-ci est écrit dans le .folder_meta.json Le fichier permet de suivre le dossier même après l'avoir renommé et déplacé. properties Ce champ n'est renseigné que si le dossier possède des propriétés. Sinon, il est omis. CODESYS 4 Un dossier ne possède pas d'identifiant unique global (GUID). Un dossier sans métadonnées enregistrées ne possède pas d'identifiant unique global (GUID). .folder_meta.json déposer.

Chaque objet de programmation est enregistré dans un fichier texte distinct. Le nom du fichier respecte la syntaxe suivante :

<object name>.<class>.<language>

La partie classe spécifie le type d'objet et la partie langage spécifie le langage d'implémentation. Plus précisément, la partie langage pour le texte structuré est st Voici un exemple de bloc fonctionnel dans un texte structuré : Timer.fb.st.

Un objet contenant des objets subordonnés (par exemple, un bloc de fonction avec des méthodes) est stocké sous forme de répertoire dont le nom se termine par un accent circonflexe (^L'objet principal est le fichier situé dans ce répertoire. Les objets secondaires se trouvent à côté :

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

Si un objet contient des métadonnées qui ne peuvent être reconstituées autrement, le fichier commence par un commentaire de métadonnées. Il peut s'agir, par exemple, d'un GUID stable ou de propriétés d'un objet. Ce commentaire est marqué par un symbole spécifique. (* METADATA … *) Les métadonnées sont stockées au format JSON.

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

Si un objet ne contient pas de métadonnées, aucun commentaire de métadonnées n'est écrit et le fichier commence directement par l'en-tête de l'objet.

Les informations du projet (titre, version, auteur, société, description et autres paramètres) sont stockées dans le ProjectInfo.json fichier dans le répertoire racine du projet.

Le texte structuré est stocké en texte brut, sans marqueurs. La déclaration est toujours écrite en premier, suivie immédiatement de l'implémentation.

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

Les langages autres que le texte structuré – les langages graphiques, tels que le diagramme à contacts (LD), le diagramme de blocs fonctionnels (FBD), Tableau de fonction continue Les langages CFC (Context-Framework) et SFC (Sequential Function Chart) ne peuvent pas être écrits sous forme de texte structuré. Pour ces langages, la déclaration est donc stockée en texte brut. Cependant, la section d'implémentation est encadrée par deux lignes de repère indiquant le langage concerné.

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

La mise en œuvre commence par le marqueur __BEGIN_IMPLEMENTATION('<language>') qui cite la langue (par exemple, LD pour le diagramme en échelle, FBD pour le diagramme fonctionnel, CFC pour un diagramme de fonction continue, ou SFC (pour le diagramme de fonctions séquentielles). Il sera fermé par le marqueur __END_IMPLEMENTATION Tout ce qui se trouve entre les marqueurs est stocké au format texte de la langue correspondante. Pour les langages graphiques intégrés, ce format est utilisé au format JSON, avec une indentation d'une tabulation par niveau d'imbrication.

Les marqueurs garantissent que la déclaration est bien séparée du contenu de la partie implémentation, quel que soit ce contenu. Non marqueur n'est nécessaire ni utilisé pour le texte structuré.

Tous les types d'objets ne possèdent pas leur propre représentation textuelle. Les objets tels que les configurations de périphériques et les configurations de tâches sont enregistrés dans un fichier d'échange avec l'extension .swap. xml.v3, qui renferme l'original CODESYS Sérialisation. Ces fichiers restent des fichiers texte et continueront de générer des différences ligne par ligne dans les systèmes de contrôle de version. Ces objets pourront être migrés ultérieurement vers un format natif dès qu'il sera disponible.

Pour plus d'informations, veuillez consulter les documents suivants : Migrer des objets

Si le contenu d'un objet ne peut absolument pas être interprété, alors l'objet reste inchangé et aucune information n'est perdue.