Purtroppo la risposta dipenderà dal fornitore del PLC che stai utilizzando. La maggior parte di essi memorizza il proprio codice in formati di file proprietari, quindi rende difficile utilizzare il controllo del codice sorgente normale.
Rockwell offre FactoryTalk AssetCenter se si utilizza Allen-Bradley. Non l'ho valutato, ma è probabilmente costoso. Fa più del controllo del codice sorgente però.
Ho usato il controllo del codice sorgente (Mercurial) con i file PLC Beckhoff TwinCAT. Sembra funzionare bene, ma non ho mai dovuto fondermi con nessuno. La loro nuova versione di TwinCAT (3) che uscirà entro la fine dell'anno dovrebbe essere costruita su Visual Studio 2010 e presumo che offriranno offerte immediate molto migliori per l'integrazione del controllo delle versioni. Dita incrociate.
Inizia Modifica
Volevo solo aggiungere che ora ho usato il nuovo prodotto TwinCAT 3 e sto usando Mercurial (TortoiseHg e il componente aggiuntivo VisualHg per Visual Studio). Funziona abbastanza bene. Innanzitutto VisualHg lo rende molto integrato nell'IDE di Visual Studio 2010 utilizzato da TwinCAT 3. Tuttavia, il codice sorgente per i programmi TwinCAT 3 è generalmente memorizzato in file XML. Questo è un grande miglioramento rispetto ai formati binari proprietari di altri fornitori che ho usato, ma ancora non si fonde bene. Alcuni file non hanno interruzioni di riga nell'XML (ne ho scritto a Beckhoff), il che significa che un sistema di controllo del codice riga per riga non fa molto. Inoltre, poiché è XML, l'ordinamento dei nodi nel file XML sembra cambiare casualmente, anche quando non si apportano modifiche. Anche, Penso che a volte generi nuovi ID per alcuni nodi quando non è necessario, il che rende superflue le modifiche che Hg rileva. Ciò rende effettivamente impossibile apportare modifiche a un programma TwinCAT 3 da parte di 2 programmatori contemporaneamente, quindi unire le modifiche. È una sventura svista da parte degli sviluppatori di TwinCAT 3, che senza dubbio utilizzano regolarmente il controllo del codice sorgente nel proprio lavoro e non vedono il vantaggio per noi programmatori di bassa automazione di avere accesso a strumenti altrettanto potenti. :( che indubbiamente usano regolarmente il controllo del codice sorgente nel proprio lavoro e non vedono il vantaggio per noi umili programmatori di automazione di avere accesso a strumenti altrettanto potenti. :( che indubbiamente usano regolarmente il controllo del codice sorgente nel proprio lavoro e non vedono il vantaggio per noi umili programmatori di automazione di avere accesso a strumenti altrettanto potenti. :(
Fine modifica
Inizia Modifica # 2
Vorrei sottolineare che TwinCAT 3.1 ora ha formati di file più adatti al controllo del codice sorgente, in particolare i file di linguaggio di testo strutturati. In effetti, credo che il prodotto sia ora costruito per supportare l'integrazione con Team Foundation Server.
Fine modifica n. 2
L'altra alternativa è che la maggior parte dei programmi PLC può essere esportata in file di testo. RSLogix 5000, ad esempio, esporta i suoi progetti in un file L5K, che è solo testo. Ho già eseguito degli script su quei file: sono abbastanza facili da analizzare. Funzionerebbero bene con il controllo del codice sorgente. Ovviamente questo significa esportare ogni volta, il che fa schifo.
Se vai con qualsiasi controllo di versione standard, ti consiglio vivamente un VCS distribuito, come Git o Mercurial, perché con i PLC, la metà delle volte sei in loco e non riesci a connetterti al tuo server di casa, quindi la possibilità di eseguire commit locali è un vero vantaggio.
L'altra cosa che devi capire è che alcuni ambienti di programmazione di PLC, come RSLogix, includono già uno strumento diff, in modo da poter eseguire diff su due versioni dei tuoi progetti. Questo, combinato con il salvataggio di un nuovo file ogni giorno con la data odierna, è ciò che sembra fare la maggior parte dei negozi di automazione.