Rockwell PLC DevOps: Modernizing Version Control

As PLC and industrial automation systems continue to scale, projects are growing larger and more complex. Increasing demands for automation, quality, and advanced features require greater oversight and automated testing of control code well before it reaches the factory floor.

To address this, DMC applies modern version control, continuous integration, and continuous deployment practices widely used in traditional software development. These processes, and the software that enables these processes, seek to lower the barrier between development (Dev) and operations (Ops). This blog will review how to apply the foundational DevOps principle of version control to Rockwell PLCs.

Version Control and Git

Version control systems (VCS) are essential for applying modern DevOps practices to Rockwell PLC development. These systems help create a standardized and reliable way for teams to collaboratively develop, manage, and test code efficiently.

Git, which is a distributed version control system (DVCS) originally created by Linus Torvalds, enables effective collaboration among developers through useful features such as branching and merging. Some of the key concepts to understand in Git include the following:

Multiple developers can work on different features simultaneously without interfering with each other. Git facilitates this by allowing branching, merging, and pulling code changes. It also has built-in data integrity mechanisms that help prevent lost changes and keep the history consistent

The main branch of code is called “main” or, in legacy systems, “master”. This branch should generally be the head of development and is the only branch present when first starting a project.

Other branches of development branch off from main, usually with a focus on implementing a specific feature or fixing a specific bug. After this code is completed, it is merged back into main (which can be configured to require appropriate permissions), and then usually either deleted or compressed into a single commit.

Local Repository Command

These core Git commands interact directly with your PC’s local repository. It is important to note that these commands do not affect the remote repository, which requires a different set of commands that will be covered next.

• Branch: This command allows you to create a copy of an existing branch, usually the main branch, so you can work on new features separately without affecting the main codebase.
  • This command stages your changes, preparing them for commit to the active branch. It essentially tells Git which changes you want to include in the next commit.
• Commit: This command saves the staged changes to the active branch, creating a new snapshot of your project at that point in time.
• Merge: This command combines two branches into a single branch, allowing you to integrate changes from different lines of development.

The following additional commands are also commonly used as part of the normal git workflow. These commands are typically utilized by more experienced developers who are comfortable with advanced git operations and want to manage their code more effectively.

• Stash: This command allows you to temporarily save the changes you have made to your modified files in your current working branch without committing them. This is useful when you want to switch contexts or branches but are not yet ready to commit your work.
• Switch: This command is used to move between different active branches of development within your repository. It enables you to quickly and efficiently switch your working branch, making it possible to work across features or fixes.
• Diff: This command compares two different branches and highlights the differences between the files contained in each. It is particularly useful for reviewing changes, understanding what has been modified, and preparing for merges or code reviews.

Remote Repository Commands

These commands and concepts are commonly used to facilitate interaction between the local repository on your personal computer and a remote repository hosted on a server. They help synchronize and manage changes efficiently across different environments:

• Fetch: This command downloads commits, branches, and tags from a remote repository into your local repository. It allows you to see changes made by others without merging them into your working branch immediately.
• Pull: This command fetches changes from the remote branch and then merges those changes directly into your current working branch. It is a convenient way to update your local branch to the latest remote changes in a single step.
• Push: This command sends your committed changes from the local working branch to the designated remote branch. It is used to share your updates with others and keep the remote repository up to date with your work.

Merging

When developing, code differences and conflicts can arise when multiple developers work on the same file across different branches. When this occurs during a merge, it is called a merge conflict and must be resolved.

This is easily handled in traditional text-based programming environments using standard compare-and-merge tools like VSCode (free), which includes functionality for merging text files.

Step	Description
1	Configure the default merge tool, usually at the global level. This only needs to be done once. git config --global diff.tool vscode git config --global mergetool.vscode.cmd 'code --wait --merge $REMOTE $LOCAL $BASE $MERGED'
2	Call the mergetool with the named tool command vscode when a merge conflict occurs during a push/pull (or manual merge). git mergetool -t vscode
3	Git will automatically create temporary LOCAL, REMOTE, and BASE files based off of the branches that are being compared. It will then call VSCode with the command-line arguments specified in the configuration above.
4	VSCode will open and highlight the differences and allow the developer to pick which changes to keep.
5	Once merging is complete, the developer will commit their changes to the local branch and push these changes back to the remote repository.

The image of VS Code shows both branches (left/right) being merged, as well as the final merge result at the bottom of the screen. It is important to note that the developer could have chosen to merge the calls to the foo/bar functions without actually merging the function definitions. This makes this tool very powerful, but not error-proof.

For programs that are not text-based or are overly complicated to merge by hand, additional merge tools can be configured to simplify these conflicts.

Git and Logix Designer Compare Tool

As part of their standard product offering, Rockwell provides the Logix Designer Compare Tool to allow visual merging of Rockwell PLC code and to identify differences between PLC code. See the full Getting Results Guide from Rockwell.

This application not only offers a GUI for starting compare/merge operations, but also provides a full command-line interface to run them automatically. Based on our previous example with VS Code, the Logix Designer Compare Tool can be configured as a full git merge tool using the following commands. The path to the application can vary depending on where the tool is installed, which is accounted for by the additional path command.

git config --global merge.tool rockwell_merge

git config --global mergetool.rockwell_merge.path 'C:\Program Files (x86)\Rockwell Software\\'

git config --global mergetool.rockwell_merge.cmd 'RSLCompare.exe -m \$LOCAL \$REMOTE \$BASE'

After configuring the Rockwell merge tool, the development workflow operates exactly the same as if developing with a text-based language like Python, i.e., using standard commit, branch, merge, and push/pull commands.

Repeating the foo and bar example from earlier with Rockwell, I created a Studio 5000 ACD project with a single program/rung. From there, I created two branches of development:

• Foo – JSR to a new Foo routine, with basic logic
• Bar – JSR to the new Bar routine, with basic logic

When merging these branches, I encountered a merge conflict because the ACD file in both branches had been modified. I can resolve this by calling git mergetool -t rockwell_merge. This will tell git to take the file from both branches, as well as the base file they both originated from, and perform a three-way merge. The left content is the local branches, the right content is the remote branch, and the center content is the base branch that the local/remote branches diverged from. The following images show how this merge works:

After selecting all of our changes, we will select File → Save As… to save the resulting ACD file over our existing ACD file in our local repository. After we close the merge application, we can commit the merge result and push to our remote repository. Once this change is in the remote repository, other developers can use the same method to synchronize their code changes, enabling accelerated system development and programming.

Next Steps in DevOps

This tutorial introduced the basic concepts of Git, how to configure merge tools, and how to leverage them for Rockwell-based PLC development. Over the next few blogs in this series, we will review how to leverage Git and GitLab for continuous integration and continuous deployment (CI/CD).

In the meantime, you can work on refining your git skills and workflow with the following free resources:

• Git – Learn
• Git and GitHub learning resources – GitHub Docs
• Git Tutorials and Training | Atlassian Git Tutorial