Part 2

Software Engineering
for Automation
In this section, you’ll broaden your skills beyond programming and dive into the essential tools,
practices, and architectural techniques that support professional software development. You’ll
learn how to manage code effectively with Git, navigate the software development lifecycle, and
use UML to design clear, scalable architectures. You’ll also explore methods for testing, debug-
ging, and leveraging AI to troubleshoot issues, along with applying SOLID principles to produce
high-quality, maintainable automation software. By the end of this part, you’ll have the practical
knowledge needed to collaborate confidently, architect solutions, and ensure your code is robust
and resilient.

This part of the book includes the following chapters:

• Chapter 8, Getting Started with Git

• Chapter 9, SDLC: Navigating the SDLC to Create Great Code
• Chapter 10, Architecting Code with UML
• Chapter 11, Testing and Troubleshooting
• Chapter 12, Advanced Coding: Using SOLID to Make Solid Code
8
Getting Started with Git
Many small and mid-sized automation companies, for whatever reason, will not invest time or
money in version control. Unfortunately for them, this is a recipe for disaster. Source control is
as much a part of modern software as gasoline is to car racing. In short, an organization will not
be able to scale without adequate version control software.

There are many different types of version control platforms available. Many of these platforms
are geared toward traditional software development; however, most of these can still be used
to great success in the automation world. It is true that without proper plugins, some features
of the version control software may be unavailable; regardless, it can still be leveraged to great
success within an organization.

This chapter is going to be dedicated to understanding one of the most, if not the most, popular
version control platforms on the market: Git. To do this, we’re going to take a hands-on approach
to using the Git command-line interface (CLI) and learn to use the software via a terminal. If you
don’t have any experience working with a terminal, don’t fret; it may seem scary, but it is quite
simple to use. The key to working with any terminal program is simply learning how to talk to it.
To do this, we’re going to look at the following:

• Understanding what version control is

• Understanding what version control is not
• Understanding Git
• Understanding GitLab
• Using the Git CLI
• Understanding branches
• Exploring PLCopen XML
200 Getting Started with Git

Finally, to round out the chapter, we’re going to create a project for a simulated car wash to ex-
periment with creating branches and pushing changes.

Technical requirements
To follow along with this chapter, you will need a few things. First, you will need Git installed on
your machine in some way, shape, or form. On the off chance you have access to a Linux computer,
you can install or use the prepackaged version of Git for Linux. However, in the more likely sce-
nario of you using Windows, you can use a program called Git Bash, which can be downloaded
at the following link: [Link]

Git Bash is the CLI that will allow you to interface with a repository management system. With
that, you will also need a Git repository manager. For this project, you can set up a free account
with GitLab and use it for the following tutorials. However, you are not limited to GitLab; you
can use pretty much any system, such as GitHub, Bitbucket, or anything else that also supports
Git, so the only real consideration there is when picking a repository manager for this book is
to ensure that it is compatible with Git. You can sign up for a free account with GitLab at the
following URL: [Link]

What is version control?

When I first started out as an automation engineer, I would often be required to modify software,
install software, or do any number of things to a machine’s codebase. However, I came to realize
that this was often quite difficult as the correct codebase was usually stored on someone else’s
computer or lost in the vacuum of cyberspace. This meant that I would have to spend needlessly
long periods of time at a customer site doing tasks that were already done. In other words, I would
have to rework jobs, and assignments that would otherwise take a few minutes would turn into
weeklong affairs. As I grew and expanded my horizons as an automation engineer at various
companies, I found this behavior to be common. For anyone else who has ever experienced this,
all hope is not lost. In fact, there is a relatively simple solution to this problem. That solution is
called version control.

Version control is a way of storing software projects as well as other documentation in reposi-
tories that share a centralized URL and can keep track of all changes that have been made to the
files. What we’re going to consider to be version control or version control systems will consist
of a true version control software like Git and a repository manager like GitLab. In day-to-day
speech, when someone refers to version control, they are normally referring to a setup like this.
Chapter 8 201

The terms source control and version control are often used interchangeably, but there is technically
a difference between the two. However, it can be argued that the differences are mostly splitting
hairs, so we’re going to stick with the normal vernacular and use the terms interchangeably.

Version control is especially useful when there is more than one person working on a project or
if someone other than the initial developer needs the source code. The key here is that version
control makes the code be in one centralized point, which means there is one source of truth for
the codebase. This means that if there is a permanent change to the codebase, it can easily be
made available to everyone working on it. In turn, this means that accidentally losing changes
to a codebase, confusing different codebase versions, and requiring extensive rework becomes
a non-issue.

The true power of source control stems from its versioning nature. As the name suggests, source
control software will version the files in a codebase. This means that if you or someone else
makes a modification to the source code and the changes are committed, the original code is not
lost. If needed, the code can be easily rolled back to its original state before the changes were
introduced. This feature is especially handy when it comes to automation. Often, a customer will
need to temporarily change out a machine component, which means the source code will have to
be altered to accommodate it. As every automation engineer knows, the customer will typically
want to roll the changes back and put the original part back in. For an organization that doesn’t
utilize source control, that could easily equate to an extensive rewrite to restore the code, in other
words, unnecessary work. However, for an organization that does use source control, rolling back
the changes can be as simple as pressing a few buttons or copying and pasting some changes.

Traditionally, PLC code is not supported well in standard repository management systems. This
means that certain features available for common languages, such as Java or C#, are not avail-
able for PLC projects. This is at least true for repository management systems such as GitLab or
GitHub. As the line between traditional computer programming and automation programming
blurs, newer automation focused version control systems are emerging, but haven’t made a huge
impact in the industry yet. Nonetheless, a version control program can greatly increase the col-
laboration and productivity of a development team.

Note

Automation software is generally not supported in the same way that traditional
programming languages like C++ or Java are by systems like GitLab or GitHub. There
are some features such as viewing source code in the browser that are typically not
supported.
202 Getting Started with Git

Now that we’ve explored what source or version control is, we can move on and explore what it
is not.

What version control is not

There are a lot of myths and misunderstandings about what the role of source control is. A lot
of these misguided truths stem from older engineers, managers, and business owners who do
not have a solid background in the software development process. Regardless, many myths and
partial understandings have hamstrung a lot of small to mid-sized organizations. In this section,
we’re going to look at some of these to learn what source control is not.

Source control is only for large teams

This is arguably the most misguided myth of them all. Source control can and will increase pro-
ductivity regardless of whether the development team has 100 engineers on it or just one. The
primary purpose of source control is to version files and prevent them from being locked away
on an employee’s development computer. Regardless of the number of engineers on a team, ver-
sion control will allow an organization to have a single point of truth for the software, allow for
the housing of the software in a centralized location, and above all else, keep a record of all the
changes in the code since it was originally pushed.

Source control is a security risk

This is one of my favorite misconceptions about source control, mostly because of how silly it is.
Many older automation engineers and managers who have no experience with source control or
cloud storage often misunderstand what cloud storage is and how version control works. This
myth is multifaceted, with the first misconception stemming from what cloud storage security is.
Many older engineers believe that cloud storage is unsafe because the company using the service
has no control over security. This is a noble but very misguided assumption. First, it is important
to understand that though no organization can guarantee perfect security, the security that many
of these cloud storage solutions offer will be significantly better than anything a small to mid-
size automation company will realistically be able to pull off. It is important to remember that a
respected source control host houses many projects from many companies and individuals, and
though they can never guarantee foolproof security, it is realistically safer to store your code online
than on an in-house system that many small to mid-size automation companies have to offer.
Chapter 8 203

Another facet of this myth is that source control must be stored in the cloud. Again, this is unequiv-
ocally untrue. Most respected source control vendors will offer the ability to deploy an instance
of the software on a local server. Typically, a modern way that vendors will distribute the version
control software is with what’s known as a container or a standard download. Containers will
utilize a system such as Docker or Podman to run the application on a local server. The nature of
Docker and how to run a Docker instance go well beyond the scope of this book. Regardless, it is
possible to deploy and run your own version control instance on your server. Utilizing a container
or download deployment is not recommended for smaller companies, as containerization and
general management of a source control system will require in-depth IT experience and resourc-
es. Housing your own version control instance will require a hefty server computer to store the
code, an admin who can maintain the version control instances (especially if it is a container
deployment), and, ideally, a backup server somewhere that can act as a disaster recovery (DR)
system. Many larger companies that have more resources and budget often opt to run their own
deployments, but for mid-size and, especially, small companies, it’s usually cheaper and safer to
use a version control service in the cloud.

Finally, the last facet of this myth is that anybody can see and pull the code. Again, this is naively
untrue. All quality version control systems will allow users to cherry-pick who they want to view
and access their source code. This means that if person X is no longer employed by the company
or no longer needs access to the codebase, an admin on the system can simply revoke their per-
missions and prevent them from seeing or accessing the code.

Version control is the same thing as a shared file system

This is, unfortunately, the philosophy of many smaller organizations that do not have a solid
foundation in software development principles. A filesystem on a server is not, and cannot replace,
a version control system. A shared filesystem can, at best, house different versions of a program in
different folders. This, unfortunately, is only as good as the least organized developer. If someone
uploads their code to the wrong directory, that is a directory that houses an older version of the
codebase; the old codebase is lost for good.

Overall, a traditional version control system is not going to give the same benefits for a PLC
project that it would for a general-purpose programming language, but it can greatly increase
productivity and promote collaboration across a development team. Version control will create
a much more consistent and cohesive environment to work in and prevent half-baked changes
from finding their way into the codebase. So, how can we start using a version control system?
204 Getting Started with Git

Understanding Git
There are many ways to interact with a source control system. Most systems will support some
type of UI or have a plugin for an IDE such as Visual Studio or CODESYS. These plugins can get
you through the day; for example, you will be able to easily upload and download changes as
well as create branches. However, to effectively use and understand a source control system, it is
important to understand how to use it via a CLI. With that, we’re going to look at installing Git.

Installing Git on Linux

Note

If you are using Windows, you can skip ahead to the Installing Git on Windows section.

Okay—very few people are going to develop PLC code on a Linux system; however, automation is
much more than PLC software engineering. There are niche systems, especially advanced robotics
systems, that often use or require a Linux distro. Regardless of why you’re using Linux, you are in
luck when it comes to Git. Git often comes packaged in most Linux distro repositories; therefore,
it is very easy to get Git up and running.

As any Linux user knows, each distro has its own package manager. The two most common Li-
nux distros are of the Debian variety, such as Ubuntu, and the Fedora variety, such as Rocky, Red
Hat Enterprise Linux (RHEL), or CentOS. For the most part, the following commands can be
used for these distros. Keep in mind that each Linux distro is different and could use a different
package manager, so if these commands don’t work for you, a simple internet search will reveal
the correct command.

Fedora installation
To install Git on a Fedora-based system, you will usually need sudo privileges. Once you secure
those privileges, you can use either of the following commands:
sudo yum install git

You can also opt to use the dnf package manager if it is available on your system, with the following:
sudo dnf install git
Chapter 8 205

Debian installation
If you are using a Debian distro such as Ubuntu, you can use the following command:
sudo apt install git

Now, if you’re using Windows, you will want to use Git Bash. For this book, I’m going to use a
Linux machine; however, the commands will be exactly the same for Windows.

Installing Git on Windows

More likely than not, you’re going to be developing on a Windows machine. This is especially
true if you are using a development system such as CODESYS or TwinCAT.

Git Bash installation

Regardless of what development system you are using, you will need to download a program
called Git Bash. The link to download this program is in the Technical requirements section of this
chapter; to follow along, please follow the link and download the latest available version. If you
follow the instructions properly, you should get a program called Git Bash that will be a simple
terminal program.

The terminal program is an interface for interacting with repositories. After installing Git Bash, you
should be able to use git commands either via a PowerShell terminal or the terminal program that
was installed. If you opt to use the Git Bash terminal, it’s important to note that it will use Linux
commands. If you’re more comfortable with PowerShell, you can apply the same git commands
that we’re going to explore, but you will have to use PowerShell commands to navigate around.

WSL installation
Another way you can install Git on your machine is to use a WSL instance. A WSL instance is a
way to run a Linux instance, such as Ubuntu, on your Windows PC. Essentially, with WSL, you
get a full version of a Linux distribution such as Ubuntu on your computer. WSL is becoming a
very popular choice with all types of developers because you can get the best of both worlds!

Regardless of which option you use to set up your Git instance, the commands will be the same.
You can pick a method to practice with now and easily transfer those skills to any of the other
media we explored here. With that, once you’ve set up your CLI, we can move on to setting up a
remote repository.
206 Getting Started with Git

Understanding GitLab
You may be somewhat confused as to what the role of Git is compared to that of a repository.
Many inexperienced engineers confuse the Git system with actual repositories; however, they
are different. The differences between the two are summarized next:

• Repository: A repository is like a house where the files that make up the codebase live.
For a system such as CODESYS, the program will be contained in a singular unit. In other
words, unlike with a traditional programming language, you will not be able to see the
individual files by default. A repository is also version-controlled when used with a system
like Git. This means that there is a clear record of the changes that were made. In other
words, if you need to revert to an older version of the codebase, you can.
• Git: Git is a program that allows you to interface with the repository. Git allows you to
push files to the repository, pull changes, merge, and more. There are other alternatives
to Git, such as SVN, but Git is the most popular, and most repository systems support it
by default.

As stated before, when someone refers to version control in the wild, they are usually referring
to the repository and Git/SVN. This book will use GitLab as a repository manager; however, the
concepts explored here can be used across any Git-based system, such as GitHub, Bitbucket, or
the like. The procedure for setting up the repository will assume that you’re using GitLab, but
setting up a repository in any system is easy.

To begin with, use the link in the Technical requirements section to navigate to GitLab and set up a
free account. Free accounts are more restrictive with things such as the number of users, project
sizes, and so on; however, for practice, a free account should suffice.

Once you create an account, you can create a new project by selecting Create Blank Project. This
will take you to a form that will prompt you to enter information such as the project name. As
with many things in the IT space, this form has a good chance of changing, so it is best not to
memorize the form but rather understand what the required fields are!

• First, the project name is the name of the project. This field should mirror the name of
the software project. For example, if you’re working on a welder project for Company X,
you could use a name such as Welder_companyx. A name such as this reflects what the
software is for.
• Once you input a name, the system will automatically generate a project URL. The project
URL will be used later to access the code. You will have some freedom when it comes to
this URL, but it is recommended to use the generated link.
Chapter 8 207

You can leave all the other fields blank and click the Create Project button, and your repo should
be set up. Most version control systems will mirror this setup. Setting up a repo is straightforward
and follows the same basic pattern.

Once you have the repo set, you need to choose one of the Git interface methods and install Git.
Again, it is highly recommended that you install Git Bash via the link provided in the Technical
requirements section if you’re using Windows. Installing Git Bash is very straightforward and is
just like installing a typical Windows program. Once you have Git Bash installed, you can opt
to use either the PowerShell CLI or the terminal Git Bash comes with. Either will work for the
remainder of this tutorial.

If you opt to use PowerShell, run the following command:

git -v

This command should provide the version info, as in Figure 8.1.

Figure 8.1: Git version info

Once you see version info, as in Figure 8.1, you should be good to use Git. Now, it is important to
know that the version you see may differ; that is normal.

Once you have the repo and Git Bash set up, you can start exploring version control!

Using the Git CLI

Before we get started, it is important to note that systems such as CODESYS do have tools that
can integrate with GitLab and other systems. These tools are GUI-based, integrate directly with
the platform, and are easy to use. However, they are often specific to a singular system and vary
in their functionality and operations. Some of these plugins are also proprietary, which can fur-
ther hamper their adaptation. So, if you’re using one of these plugins, especially in a production
environment, be careful you are not violating any terms of usage.

For this chapter, we’re going to stick with the classic Git command line because it’s vendor-neutral
as far as programming languages go and can be used with pretty much any file type. Git has a
lot of functionality to offer, and learning the CLI can give us great control over what we’re doing.
This section is going to cover the basic operations that Git offers. To begin getting our feet wet,
we’re going to explore cloning a repo.
208 Getting Started with Git

Cloning a repo
Arguably, the most common Git operation is cloning a repo. Cloning a repo is a fancy way of saying
that we’re going to pull the project from our remote or online repository. The core of cloning the
project is the project’s URL that was created when you set up the repo. To view this URL, navi-
gate to your project and click the Code button. This button is typically to the right of the screen.

Figure 8.2: Clone menu

From here, you will have two options. You can clone the project with SSH or HTTPS. SSH typically
requires a little extra configuration, but once configured, it will not prompt you for login cre-
dentials. On the other hand, HTTPS will require login credentials but requires no further setup;
therefore, in this chapter, we will use HTTPS.

To clone the project, copy the HTTPS URL by clicking the button with the clipboard. Then, run
the following command:
git clone <url>

Add the URL you copied in <url>.

Chapter 8 209

If you type in pwd, you should see the file path where your project was copied to. To open the
project, navigate to that directory. Depending on the system you’re using, you may get a message
saying that you have cloned an empty repo. This is fine because this is a fresh repo with nothing
in it. GitLab typically preloads a [Link] file into the repo, so if you’re using GitLab, you may
not get this particular warning.

Once you have the repo cloned, create a new PLC project on your system of choice and add the
following code:
PROGRAM PLC_PRG
VAR
x : INT;
y : INT;
sum : INT;
END_VAR

The main logic

x := 3;
y := 2;

sum := x + y;

The code for this particular tutorial doesn’t matter much, so don’t worry if it isn’t perfect.

Once you have the code in place, save the project and copy it to the directory that was cloned
down. Essentially, you should have something akin to Figure 8.3.

Figure 8.3: Git project structure

When the project is uploaded, run the following commands in your terminal one by one.

This command will add all new files and projects to Git:
git add .

The following command will commit the project to Git’s history:

git commit -m "Initial Commit"
210 Getting Started with Git

This command will take a message. When you commit, you want to have a descriptive message
about what you’re committing. For example, if you added the logic for a motor drive to the project,
you could have a message such as Motor drive code added for welder. In this case, we’re working
with an initial commit, so just using that phrase as a commit message is fine for our purposes.

Finally, run the following command:

git push origin main

This command will push the code to the remote repository; that is, it will push it to GitLab. More
specifically, the code will be pushed to what is called the main branch. We’re going to cover this
more when we explore branches later in this chapter.

Once you run the final command, navigate to your project in GitLab. You should be met with
something like the following:

Figure 8.4: Project repo

The project can now be cloned by anyone who has access to the repository. The ability for any-
one to access the project is both a pro and a con. On the one hand, anyone who needs access to
the project has it, but on the other hand, anyone can modify the project. So, what can you do to
ensure that your stable project hasn’t changed? You can use branches!

Implementing branches
When done right, a project in a source control system should conceptually look like a tree. That
is, you’ll have the main trunk of the tree – in this case, the main branch that we just pushed to –
and you’ll have other branches. These other branches are logically isolated subprojects. That is,
a branch is the same source code that lives in the main branch, but it is meant to be altered in
some way. Typically, any time you need to address a bug or add a new feature to your codebase,
you’ll first create a branch in your repo.
Chapter 8 211

To create a branch, all you need to do is clone your project and run one of the following commands:
git checkout -b "<name of branch>"
git switch –c "<name of branch>"

The lateral command is newer but serves the same purpose, so you can use either. For this book,
to keep things consistent, we’re going to use the checkout version.

To test this out, we’re going to create a new branch for our welding project called function_block.
We can accomplish this with the following command:
git checkout -b "function_block"

To test whether our branch was created successfully, you can run the following command:
git branch

This command will show all our local branches, that is, branches that exist on our computer. If
the branch was successfully created, you should see something like Figure 8.5:

Figure 8.5: Branch

Now that we have a branch created, we’re going to open our project and add a function block
named mulFB with the following variables in it:
FUNCTION_BLOCK mulFB
VAR_INPUT
a : INT;
b : INT;
END_VAR

VAR_OUTPUT
product : INT;
END_VAR

VAR
END_VAR
212 Getting Started with Git

Once the variables are in place, be sure to add the following logic:
product := a * b;

Modify the PLC_PRG file to include the following variables:

multiply : mulFB;
prod : INT;

Also, add the following logic:

multiply(a:=3, b:=3);
prod := [Link];

Save the file and run the following Git commands in the terminal of your choice:
git add .
git commit -am "Added mulFB"
git push origin function_block

Once you run those commands, you can navigate over to GitLab or whichever system you opted
to use and look for your new branch. In GitLab, you will want to navigate to your project and
click the drop-down menu that says main. When you click the drop-down menu, you will see the
branch you created, as in Figure 8.6:

Figure 8.6: Branch drop-down menu

Chapter 8 213

Once you click the branch name, you should see files similar to the ones shown in Figure 8.7:

Figure 8.7: Project files in Git

Note

Notice that a lot of files were committed. These are cache files that are generated by
CODESYS. You can exclude these files by creating a .gitignore file and listing them.

When you perform a Git clone, you will, by default, pull the main branch. If you’re working on a
specific branch, you will need to check out that branch.

Checking out a branch

To access code in a branch, you need to check out or switch to that branch. This is a simple opera-
tion, and to do this, the first thing we’re going to do is delete the project from our directory. After
you delete the project, run the following commands in your terminal sequentially:
git clone <url>
cd welder_companyx
git checkout function_block

The cd command will simply change the directory to the repo you just cloned. If you changed to
a different directory before you ran the second command, you will need to navigate back to the
directory you cloned the repo in. Once you complete these operations, open the project, and you
should see all the code we just added. In other words, you pulled down your branch!

Once you complete your code changes, the branch needs to be merged into the main branch. Typ-
ically, this is done after a code review. The main drawback to using a raw system such as GitLab
with a PLC programming system is that you can’t view file changes natively like you can with
most traditional programming languages, such as C++ or C#. PLC projects that use a raw system
such as GitLab without additional Git plugins will require your peer reviewers to pull your branch
214 Getting Started with Git

for inspection. Some repository plugins will allow users to view code in remote repos; however,
as was stated before, support and functionality for these tools will vary. This technique can be
thought of as a quick and cheap methodology when plugins aren’t available. Regardless, to sig-
nal your code is ready to be merged into the main branch, create what’s called a merge request.

Merging code changes

A merge request is a request to consolidate code changes in your branch with the main branch.
To do this in GitLab, navigate to your branch and click the Create merge request button. This
button is usually located at the top of the branch page but could be subject to change. At the time
of writing this book, the button looks like the one shown in Figure 8.8.

Figure 8.8: Create merge request button

This will navigate you to a form-like page. Typically, you will assign your reviewers here and add
information in the description box, such as what the changes were for. For now, just click the
Assign to me link, scroll toward the bottom, and click the Create merge request button.

Next, click the Merge button shown in Figure 8.9.

Figure 8.9: Merge button

Once you complete these steps, you can test your merge by deleting your project again and cloning
down your code. Once you have cloned your code, open your project and you should see all the
new code you created!

This was just a quick crash course on how to use the basics of Git. When it comes to a production
environment, you need to consider how your group implements branches and reviews, so we’ll
look at this next.
Chapter 8 215

Understanding branches
Branches are very important when it comes to source control. A poorly implemented branch
strategy can lead to a corrupted main branch. Therefore, here are some basic tips to help you
create great branches and keep your repo nice and clean:
• Naming: A branch’s name should be reflective of what it’s meant to do. For example, if
the goal of your branch is to fix a specific bug, name your branch something along the
lines of motor_bug_fix. If your branch is supposed to integrate a new feature, name it
something such as UDP_Support. If your group uses a ticketing system such as Jira, it is
usually a good idea to put the ticket number on the branch as well. It’s an even better idea
to link the branch to the ticket if possible. It is also important to ensure that your branch
name does not contain any spaces. For example, function block is not a good name and
could cause issues with the version control system you’re working with. It’s a good idea
to ensure that words in a branch name are separated by either a dash or an underscore,
such as feature-branch or feature_branch.
• Check your branch: It is important to know which branch you’re currently on. Working
with different branches can get confusing quickly, and it can be easy to make mistakes.
Typically, your terminal program will put * by the branch you’re on and change its color.
It is important to understand that when you first create a branch, it is what’s called a local
branch which means it lives on your computer. When you push the branch, it becomes a
remote branch which means it lives on whatever server your source control instance is on.
To see all your local branches, you can use git branch; to see all the remote branches you
have access to, you can use git branch -r; and finally, to see all the branches you have
access to, whether they be remote or local, you can simply use git branch -a.
• Reviewers: It is usually a standard practice to have at least one other person review your
code before it is merged. Systems such as GitLab allow you to set a minimum number of
reviewers. Essentially, this feature will block any merger attempts made until the mini-
mum number of approvals is met.
• Intermediate branches: Another good strategy is to have an intermediate branch to merge
with. This methodology is commonly called release branching or staging branching. Many
organizations, especially Agile ones, like to have releases on a specific schedule. So, it
is not uncommon for them to have a branch that everyone merges their code into for a
sprint or a given interval of time. Typically, engineers will merge into this branch, then
that intermediary branch will be merged into main. This strategy is more for projects that
are on a timed schedule and have a lot of people working on them. For a small, one-off
project, this may be more trouble than it’s worth.
216 Getting Started with Git

• Clean up after yourself: Not every branch will get merged. Sometimes a new feature will
be forsaken after the branch has been made; other times a branch may have been created
to test a concept that was never meant to be a part of the project. Branches will also quite
often need to be deleted after they have been merged. In any case, these branches need to
be removed. A simple way to manually delete a branch is with the following command:
git push origin –-delete <branch_name>

Oftentimes, you will either be prompted to delete a branch when it’s merged or the branch
will automatically be deleted. In either of these cases, you will not need to manually delete
it with the preceding command. If, for any reason, the branch is still lingering after you
merge your it, you can still resort to using the command just shown.

Note

It is very important to remember that once a branch has been deleted, it and any
code/data that lived in the branch will also be permanently removed.

• Pull often: Sometimes, you may find yourself working with other engineers in the same
branch. Though it can be argued that this isn’t the greatest practice in the world, it does
happen. If they make a change, you need to ensure your codebase reflects it. To do this,
you can use git pull. This command will fetch all the content from the remote branch
(branch in GitLab or whichever system you’re using) and put it in your project. Now, this
can be easier said than done. If that person has made changes to their code, such as re-
moving something, it could cause a conflict. There are ways to get around this; however,
when it comes to PLC code, it is usually easier to simply delete your project, re-clone the
code, and check out the branch again.

Recently, a new technology has been introduced to help provide some cross-compatibility to
PLC projects. Essentially, for compatible systems, this technology generates a lightweight file to
store in a system such as Git.
Chapter 8 217

Exploring PLCopen XML

Most PLC systems are not compatible, meaning you typically can’t port a project from one PLC
system to another; however, a standard exists that allows developers to export their project in a
specialized eXtensible Markup Language (XML) format. XML is a data exchange language that
used to be popular in the early days of the internet. Though it lost its popularity to more modern
data exchange languages such as JSON, it is still used quite a bit as a generic means of formatting
data that can be used for parsing at another time or by another system. Some of the more advanced
PLC systems are now offering a feature that allows you to export your program and certain other
metadata in an XML format. This means if your programming system is compatible with what’s
called PLCopen XML, you can, in theory, port your project from one system to another.

Note

This is a fairly new technology in terms of practical application, and you could en-
counter bugs that stem from XML files generated in different systems. For example,
a program could use a function block or syntax that is not universal or supported
by the standard.

When it comes to source control, you can store your whole project as we just did; however, it
would be better to export your project when necessary and upload the PLCopen XML file. This
will keep your repos lighter, and if your group is familiar with DevOps tools such as Coverity,
SonarQube, or the like, you can create whole CI/CD pipelines to scan your PLC code, albeit you
will most likely need to create your own custom plugins. New research is currently underway on
how to leverage PLCopen XML and CI/CD pipelines, but at the very least, it is a reliable means of
storing your PLC project in Git and possibly creating CI/CD pipelines around it.
218 Getting Started with Git

To export a program in CODESYS, you can navigate to the option highlighted in Figure 8.10:

Figure 8.10: PLCopen XML export

This will export the program in XML. You will have the option to customize your export; however,
you can export everything on the device by selecting Device, shown in Figure 8.11:

Figure 8.11 -Export selection

Chapter 8 219

Importing one of these files is as simple as selecting Import… from the menu and selecting the file.

Now that we’ve explored the basics of Git and PLCopen XML, we can move on to our final project!

Final project: Modifying a project

For our final project, we’re going to modify a project. We’re going to make a branch and push a
small modification to the branch and finally merge the change. To begin, let’s create a new project
called CarWash in GitLab:

1. Navigate to the root page and click the + button in Figure 8.12:

Figure 8.12: Creating a new project

2. Now, create a blank project, fill out the project name, and click Create.
3. Next, add the following PLC code to a new project:
PROGRAM PLC_PRG
VAR
msg : WSTRING;
END_VAR

4. For the main logic, add the following:

msg := "at the car wash yeah!";

5. Clone the project down, add the PLC program we just created to it, and push the project.

With that, the project is now set up to begin the final simulation.

In this simulation, we will add another message to the code that says, "oh boy". Follow these steps:

1. Pull down the code.

2. Create a branch. In this case, name it new-message.
3. Make your code change.
4. Push the code into your branch.
5. Merge it.

Before you read on, try to do this on your own!

220 Getting Started with Git

Final project: Solution

Were you able to get it right? If not, here’s the solution:
1. To pull down the code, you should have utilized the following command:
git clone <url>

2. The following command should create a new branch named new-message:

git checkout -b new-message

3. Next, you should have modified your PLC program by adding the following:
PROGRAM PLC_PRG
VAR
msg : WSTRING;
msg2 : WSTRING;
END_VAR

Of course, you should have also added the following logic:

msg2 := "oh boy";

4. You should have then saved the project and executed the following commands:
git commit -am "oh boy code added"
git push origin new-message

5. From here, you should have created a merge request. At this point, the code should be in
the main branch!

Summary
This chapter was a short tutorial on how to carry out basic operations in Git. Git is a very powerful
source control tool, and it can mean the difference between haphazard projects strewn across peo-
ple’s computers or everything in one central location. Though many GUIs can be used to perform
Git operations, any engineer worth their salt should have a basic understanding of how to use the
Git CLI. In all honesty, though some people will use a Git plugin to perform these operations, it is
often seen as a crutch. Therefore, you should become very familiar with at least the basics of Git.
Source control, and, by extension, Git, play a pivotal role in the life cycle of software. Software,
as you have probably deduced at this point, is way more than just writing awesome code. In the
next chapter, we’re going to explore key concepts to ensure that your code is designed well as we
explore the software development life cycle!
Chapter 8 221

Questions
1. What is a branch?
2. What is Git?
3. What is the difference between Git and a system such as GitLab?
4. How do you clone a project using Git?
5. What is the difference between a local and remote repository?
6. What does git pull do?
7. What is the difference between git branch -a and git branch -r?
8. How do you create a branch with the Git CLI?
9. What does git add . do?

Further reading
• XML Exchange: [Link]
• Git cheat sheet: [Link]

Join our community on Discord

Join our community’s Discord space for discussions with the authors and other readers: https://
[Link]/embeddedsystems