Skip to main content

Archiviazione basata su file

In CODESYS 3 Un progetto viene memorizzato in un singolo file binario. Il contenuto di questo file non può essere letto o modificato al di fuori dell'ambiente di sviluppo. Un confronto tra due versioni del progetto non mostra differenze evidenti e due editor entrano già in conflitto quando modificano oggetti diversi.

Dopo aver installato il CODESYS File-Based Storage componente aggiuntivo in CODESYS 3, viene fornito un formato di archiviazione basato su file compatibile con il formato di archiviazione in CODESYS 4. Consente la conversione del formato basato su file in CODESYS 4 in formato binario in CODESYS 3 e ritorno. 

In CODESYS 4 Un progetto viene gestito in un formato aperto, basato su file. Ogni oggetto è memorizzato nel proprio file di testo e la struttura del progetto corrisponde alla struttura delle cartelle nel file system. Non esiste un gestore di oggetti.

Da ciò derivano i seguenti vantaggi.

  • Un oggetto può essere letto con qualsiasi editor di testo e modificato se necessario.

  • Il confronto tra due stati del progetto mostra le modifiche di contenuto in formato testo semplice.

  • Le modifiche apportate a oggetti diversi non sono in conflitto tra loro.

  • Un progetto è gestito in un sistema di controllo di versione come Git, SVN o Mercurial. L'archivio del progetto da CODESYS 3 è superfluo per questo motivo.

  • È possibile utilizzare i processi standard di un sistema di controllo di versione, come le richieste di merge, le richieste di pull e la revisione del codice, poiché le modifiche possono essere visualizzate anche nel portale web del sistema di controllo di versione.

Per ulteriori informazioni, consultare quanto segue: Spazi di lavoro e tipi di file

Codice sorgente e file generati

Non tutto ciò che si trova nella cartella del progetto appartiene al testo sorgente. Oltre ai file oggetto, CODESYS 4 Vengono inoltre memorizzati i risultati temporanei, le librerie risolte e le impostazioni specifiche dell'utente. Questi file vengono rigenerati all'occorrenza.

Cartella

Posizione

Contenuto

.compileContexts

Nel <application name>.iecapp^ cartella

Compilare e fare riferimento ai contesti

.intermediate

Nel <application name>.iecapp^ cartella

File temporanei creati a scopo diagnostico

.bootapp

Nel <application name>.iecapp^ cartella

Se non viene specificato alcun percorso, viene generata l'applicazione di avvio offline.

.library-cache

Livello massimo in .fbsdev E .fbslib

Librerie compilate risolte

*.user

Livello più alto nel progetto

Impostazioni del progetto e preferenze utente

La directory viene creata solo quando si salva per la prima volta un'impostazione di progetto personalizzata.

<workspace name>.fbsws.user

Parallelamente al file dell'area di lavoro

Impostazioni dell'area di lavoro e preferenze utente

La cache delle descrizioni dei dispositivi, invece, appartiene al progetto. Le descrizioni dei dispositivi sono disponibili come file di testo e sono soggette a controllo di versione.

Impostazione dei caratteri, interruzioni di riga e rientro

Per garantire che un confronto tra due versioni del progetto mostri modifiche di contenuto e non modifiche di formato, tutti i file vengono scritti secondo regole fisse in CODESYS 4.

Proprietà

Regola

Set di caratteri per il codice sorgente IEC e i file JSON

UTF-8 senza BOM (Marcatore di ordine dei byte )

Inizialmente i file omettono qualsiasi informazione sulla codifica dei caratteri utilizzata

Set di caratteri per file XML

UTF-8 preferito

I file di inventario, come le descrizioni dei dispositivi, vengono letti in base alla loro dichiarazione meta.

interruzione di riga durante la scrittura

LF (Alimentazione in linea )

interruzione di riga durante la lettura

LF e CRLF (Alimentazione della linea di ritorno del carrello )

Rientro nei file JSON e XML

1 scheda per livello

Ordine delle voci negli oggetti JSON

Deterministico

I file vengono sempre salvati con il formato di terminazione di riga LF (0x0A). Sia LF che CRLF (0x0D, 0x0A ) sono supportati durante l'importazione. Ciò garantisce che i file rimangano leggibili anche quando sono stati modificati al di fuori di CODESYS 4 con un editor che utilizza il formato di terminazione di riga CRLF.

Progetti nei sistemi di controllo di versione

L'ordine deterministico negli oggetti JSON e l'indentazione con tabulazioni hanno lo stesso scopo: un oggetto modificato crea una differenza solo dove il contenuto è cambiato.

. Cosa deve essere sottoposto al controllo di versione:
  • file oggetto

  • File di configurazione del progetto come Libraries.json E ProjectInfo.json

  • Libraries.lock.json file di blocco

  • File dell'area di lavoro

Le cartelle e i file generati dal codice sorgente non fanno parte del controllo di versione. Contengono dati temporanei, file binari o impostazioni specifiche dell'utente. Altri ambienti di sviluppo gestiscono questo aspetto allo stesso modo, ad esempio un progetto C# ha il bin E obj cartelle.

Per le seguenti cartelle, l'esclusione è un'impostazione predefinita, non un requisito. Se i file binari non rappresentano un problema per il sistema di controllo della versione in uso, è possibile includere le cartelle nel sistema di controllo della versione.

File esclusi dal controllo di versione:

  • .library-cache

  • .user

  • <workspace name>.fbsws.user

Configurare il sistema di controllo della versione in modo che i file vengano convertiti in formato LF (Alimentazione in linea ) quando viene effettuato il check-in e viene recuperato senza modifiche quando viene effettuato il check-out. In Git, è possibile configurarlo con le seguenti impostazioni.

core.eol = lf
core.autocrlf = false

Salva le esclusioni per ogni cartella di progetto in un file separato con il .gitignore estensione e le impostazioni per le interruzioni di riga in un file separato con l' .gitattributes estensione. Entrambi i file devono essere gestiti tramite controllo di versione, altrimenti le regole non funzioneranno.

Modifica dei file al di fuori di CODESYS 4

I file oggetto di un progetto sono in testo semplice. Se necessario, è possibile modificare i file al di fuori di CODESYS 4, ad esempio quando si risolve un conflitto di unione o quando si apporta una modifica che influisce su molti oggetti allo stesso modo.

Qui è necessario rispettare le seguenti condizioni:

  • La dichiarazione rimane sintatticamente valida. La dichiarazione viene utilizzata per separarla dall'implementazione.

  • Il set di caratteri rimane UTF-8 senza BOM.

  • La struttura delle cartelle rimane invariata perché corrisponde alla struttura del progetto.

Ogni volta che si risolve un conflitto di unione al di fuori di CODESYS 4, dovresti controllare il risultato in seguito nel CODESYS 4 IDE. Un'operazione di merge può creare relazioni tra oggetti non consentite in un progetto. Un esempio è un POU subordinato a un altro POU.

File del sistema di controllo della versione come .gitignore si trovano nella cartella del progetto e pertanto compaiono anche nel navigatore dell'area di lavoro.