Version control for ladder logic (LL) programs for programmable logic controllers (PLCs) seems to be virtually non-existent. It may be because LL is a visual language and tends to be stored in binary files, or it may be because source code control hasn't "caught on" in process control engineering circles – or perhaps my Google-Fu is weak tonight.
Do you know of any realistic and useful solutions for version control for such systems?
Definitions:
- realistic = changes to the programs are tracked by user and subject to reversion and merges
- useful = the system integrates with visual LL designers, is not limited to LL from a single PLC manufacturer, and does not cost a ridiculous amount of money?
Note: I have heard of people using SVN or Mercurial et al to track the binary files, but I don't think the diff/merge capabilities would display readable differences.
ADDENDUM:
At first we only had to support Allen-Bradley PLCs. Now we also have Siemens and MicroLogix PLCs. Still searching for a viable solution…
Best Answer
Unfortunately the answer is going to depend on the PLC vendor you're using. Most of them store their code in proprietary file formats, so it makes it difficult to use regular source control.
Rockwell offers FactoryTalk AssetCenter if you're using Allen-Bradley. I haven't priced it, but it's likely expensive. It does more than source control though.
I have used regular (Mercurial) source control with Beckhoff TwinCAT PLC files. That seems to work OK, but I never had to merge with anyone. Their new version of TwinCAT (3) coming out later this year is supposed to be built on Visual Studio 2010, and I'm assuming will have much better out-of-the-box offerings for version control integration. Fingers crossed.
Start Edit
I just wanted to add that I've now used the new TwinCAT 3 product, and I am using Mercurial (TortoiseHg and the VisualHg add-in for Visual Studio). It is working pretty well. First of all VisualHg makes it feel very integrated into the Visual Studio 2010 IDE that TwinCAT 3 uses. However, the source code for TwinCAT 3 programs are generally stored in XML files. This is a vast improvement over other vendor's proprietary binary formats that I've used, but it still doesn't merge well. Some of the files don't have any line breaks in the XML (I've written to Beckhoff about this) which means a line-by-line source control system doesn't do much. Also, since it's XML, the ordering of the nodes in the XML file seems to change randomly, even when you don't make any changes. Also, I think it sometimes generates new IDs for some nodes when it doesn't have to, which makes for superfluous changes that Hg picks up on. This effectively makes it impossible to make changes to a TwinCAT 3 program by 2 programmers at the same time, and then merge the changes. It's an unfortunate oversight by the TwinCAT 3 developers, who undoubtedly use source control regularly in their own work, and didn't see the advantage for us lowly automation programmers to have access to similarly powerful tools. :(
End Edit
Start Edit #2
I would like to point out that TwinCAT 3.1 now has file formats that are better suited to source control, particularly the structured text language files. In fact, the product is now built to support integration to Team Foundation Server, I believe.
End Edit #2
The other alternative is that most PLC programs can be exported to text files. RSLogix 5000, for instance, exports its projects to an L5K file, which is just text. I've run scripts against those files before - they're fairly easy to parse. They would work well with source control. Of course that means exporting every time, which sucks.
If you do go with any standard version control, I highly suggest a distributed VCS, like Git or Mercurial, because with PLCs, half the time you're onsite and can't connect to your home server, so the ability to do local commits is a real bonus.
The other thing you have to realize is that some PLC programming environments, like RSLogix, already include a diff tool, so you can run diffs against two versions of your projects. This, combined with saving a new file with today's date every day, is what most automation shops seem to get by with.