Malheureusement, la réponse dépendra du fournisseur de PLC que vous utilisez. La plupart d'entre eux stockent leur code dans des formats de fichiers propriétaires, ce qui rend difficile l'utilisation du contrôle de source régulier.
Rockwell propose FactoryTalk AssetCenter si vous utilisez Allen-Bradley. Je ne l'ai pas évalué, mais c'est probablement cher. Il fait cependant plus que le contrôle des sources.
J'ai utilisé le contrôle de source régulier (Mercurial) avec les fichiers PLC Beckhoff TwinCAT. Cela semble fonctionner, mais je n'ai jamais eu à fusionner avec qui que ce soit. Leur nouvelle version de TwinCAT (3) qui sortira plus tard cette année est censée être basée sur Visual Studio 2010, et je suppose que les offres prêtes à l'emploi seront bien meilleures pour l'intégration du contrôle de version. Doigts croisés.
Commencer l'édition
Je voulais juste ajouter que j'ai maintenant utilisé le nouveau produit TwinCAT 3 et j'utilise Mercurial (TortoiseHg et le complément VisualHg pour Visual Studio). Cela fonctionne plutôt bien. Tout d'abord, VisualHg le fait se sentir très intégré dans l'IDE de Visual Studio 2010 que TwinCAT 3 utilise. Cependant, le code source des programmes TwinCAT 3 est généralement stocké dans des fichiers XML. Il s'agit d'une amélioration considérable par rapport aux formats binaires propriétaires d'autres fournisseurs que j'ai utilisés, mais cela ne fusionne toujours pas bien. Certains fichiers n'ont pas de sauts de ligne dans le XML (j'ai écrit à Beckhoff à ce sujet), ce qui signifie qu'un système de contrôle de source ligne par ligne ne fait pas grand-chose. De plus, comme il s'agit de XML, l'ordre des nœuds dans le fichier XML semble changer de façon aléatoire, même lorsque vous n'apportez aucune modification. Aussi, Je pense que cela génère parfois de nouveaux identifiants pour certains nœuds lorsque cela n'est pas nécessaire, ce qui entraîne des changements superflus sur lesquels Hg prend. Cela rend effectivement impossible d'apporter des modifications à un programme TwinCAT 3 par 2 programmeurs en même temps, puis de fusionner les modifications. C'est une fâcheuse erreur de la part des développeurs de TwinCAT 3, qui utilisent sans aucun doute régulièrement le contrôle des sources dans leur propre travail, et ne voient pas l'avantage pour nous, les programmeurs d'automatisation modestes, d'avoir accès à des outils tout aussi puissants. :( qui, sans aucun doute, utilisent régulièrement le contrôle des sources dans leur propre travail et ne voient pas l'avantage pour nous, les programmeurs d'automatisation modestes, d'avoir accès à des outils tout aussi puissants. :( qui, sans aucun doute, utilisent régulièrement le contrôle des sources dans leur propre travail et ne voient pas l'avantage pour nous, les programmeurs d'automatisation modestes, d'avoir accès à des outils tout aussi puissants. :(
Fin de la modification
Lancer l'édition n ° 2
Je voudrais souligner que TwinCAT 3.1 dispose désormais de formats de fichiers mieux adaptés au contrôle de code source, en particulier les fichiers de texte structuré. En fait, je crois que le produit est maintenant conçu pour prendre en charge l'intégration à Team Foundation Server.
Fin de l'édition n ° 2
L'autre alternative est que la plupart des programmes API peuvent être exportés vers des fichiers texte. RSLogix 5000, par exemple, exporte ses projets dans un fichier L5K, qui est juste du texte. J'ai déjà exécuté des scripts sur ces fichiers - ils sont assez faciles à analyser. Ils fonctionneraient bien avec le contrôle de source. Bien sûr, cela signifie exporter à chaque fois, ce qui est nul.
Si vous optez pour un contrôle de version standard, je suggère fortement un VCS distribué, comme Git ou Mercurial, car avec les automates, la moitié du temps vous êtes sur place et ne pouvez pas vous connecter à votre serveur domestique, donc la possibilité de faire des commits locaux est un vrai bonus.
L'autre chose que vous devez comprendre est que certains environnements de programmation PLC, comme RSLogix, incluent déjà un outil de différenciation, vous pouvez donc exécuter des diffs sur deux versions de vos projets. Ceci, combiné à l'enregistrement quotidien d'un nouveau fichier avec la date d'aujourd'hui, est ce que la plupart des ateliers d'automatisation semblent s'en tirer.