Basic Binary Blobs vs. Groovy Git: A Comparison of PLC Version Control Strategies

Published on
December 2, 2022

When developing new PLC code, it’s important to plan for Version Control, also known as Source Control or Change Control. 

A few of the many important benefits of having a Version Control Strategy in place as the Control Logic takes shape are:
  1. Ensuring the Controls team can easily share code and information between Engineers
  2. Always having access to the “ground-truth” version of PLC logic, even if a Controls Engineer goes on vacation or leaves the company
  3. Being able to go back and undo changes, or access previous versions, at a moment’s notice
There are a few different options that can provide these benefits to a Controls team, but that doesn’t make them all equal. Let’s take a look at a few of the most popular options.

Binary Blobs

Binary Blob Version Control essentially means any form of Versioning or Development Backup where an entire file is copied and saved every time, without knowing what the file actually contains.  One type of Binary Blob Version Control readers may be familiar with is the Archive Folder Method.  The Archive Folder Method of Version Control is the most basic form of Version Control, and essentially means that programmers periodically copy their current version of the PLC project to a backup folder. By manually giving each version a different name, copying the backup folder to a shared drive, and periodically downloading other engineers’ versions to stay synchronized as a team, the basic requirements of version control, listed above, can be met.  The advantage here is that it often requires that little to no additional infrastructure be set up, it supports any file type, and, when correctly executed, it “gets the job done”.  The main disadvantage is the amount of cumbersome manual work required to correctly carry out version control with an archive folder;  for example, combining the contributions of two programmers into a single PLC project may mean opening both versions, manually seeking out any additions or differences between them, and manually copying code from one project to the other.  With an Archive Folder, If any step is skipped, one or more benefits of using version control at all may be lost.  To compound this, as a Controls team grows, so too do the number of potential failure points.

Example of an Archive Folder containing a Studio 5000 project

Other forms of Binary Blob Version Control may mitigate some of these risks by reducing the failure points, but some manual work always remains; if the files being tracked are a black box to the Version Control System, users will have to manually open files in their original environment and track down changes by hand to have any insight into the contents of any particular version.

Git-Based Source Control

Git Diff of an open source Python file, showing changes highlighted clearly

Git is the gold standard for version control in general software development, such as for apps, games, and business software, and with good reason.  It is robust, easy to set up, and removes most of the steps of Archive Folder version control. Git makes it much easier to realize the benefits listed above, and provides several additional benefits, such as by rendering files with changes highlighted, and automatically combining changes from multiple parallel development versions.  The catch is, git has traditionally been limited in scope to text files only; anything else, from images and executable files to even files containing text, but saved as binary, such as PDFs and, notably, most PLC code, is saved as a Binary Blob.

Binary Blobs with Git

When versioning via Binary Blobs, Git still removes many of the manual steps, and therefore points of failure, of the traditional Archive Folder method. However, much of the additional benefit of using Git is left on the table; Git can’t interpret these files, so the best it can do is to copy the entire file (blob) as binary, without regard for what that file contains. Synchronizing multiple versions of a file requires opening both versions and manually modifying one to contain both sets of changes.  Simply figuring out what changed from one version to the next requires opening both versions in an external program and manually scanning through everything in both versions with a keen eye, being careful not to miss any details.  Thankfully, for many file types not supported by base Git, including PLC code, extra tools exist to unlock those additional benefits traditionally limited to text-based files

Studio 5000 PLC project file loaded as a Binary Blob in base Git


Studio 5000 PLC project file Diff rendered with Copia

Copia uses Git, building on top of it custom tools that allow it to work seamlessly with various PLC file types. With these tools, users are no longer limited to Binary Blob Version Control for PLC programming, and can leverage the full power of Git; changes are detected automatically and highlighted clearly, any two versions can be compared with a couple clicks, and changes can be quickly and easily synchronized between teammates, without the fuss of manually copying changes over. 

See how Copia can bring best-in-class Version Control to your PLC projects: request a free custom demo.