PLC Version Control: Why Your Factory's Most Important Code Has No Standard

9 min read · Last updated August 10, 2026

The code running your factory is probably tracked with filenames like Final_V3 and copies passed over Slack. A former Rivian controls engineer on why PLC code never got real version control — and what that gap actually costs.

PLC code controls every machine on a factory floor. Load the wrong program onto the wrong machine and it can cost someone a limb.

You'd expect code this dangerous to be tracked with military precision. It isn't. Ask 100 controls engineers how they track changes to their PLC code and you'll get 100 different answers.

Some engineers use date-stamped filenames, others used emailed copies, or a nightly backup nobody looks at. Thing is, none of these solutions describe version control in the sense a software engineer would recognize. They just describe backup and file naming.

To understand this issue, we sat down with Karthik Velamati, a former staff controls engineer at Rivian who spent years living this problem across car plants and beverage-packaging lines.

How Controls Engineers Actually Track Their Code

Let's start with what actually happens on most factory floors, because it's less systematic than you would think.

Programs live in whatever folder each engineer keeps them in. The latest version is whichever one that engineer has learned to recognize as latest. When someone else needs it, it moves by email or chat.

"Everyone had their own local folder with tons of different files. Each engineer had their own little way of recognizing which one was the latest, and we were Slacking each other files — 'hey, I have the latest one, if you want it, here you go.' It was messy."

It wasn't one bad employer, either. Earlier in Karthik's career, at a beverage-packaging plant, it was the same story with different tools:

"There were two of us, and we'd email each other files or append the name with the date or a description of the changes — 'this is final version V3.' Every company and every team has its own unique way to do it. There is no standard. There's whatever works for you."

Two symptoms fall out of this, and both matter.

Nobody's sure which file is the real one. Version control has to start from a single source of truth — one canonical copy you track changes against. A factory rarely has that. The same program can sit on the machine, on an engineer's laptop, and on a USB stick in a drawer at once. The moment someone edits the running machine and forgets to save the change back, those copies disagree, and nothing tells you which one is right.

There's no standard to fall back on. Software converged: everyone adopted the same convention, so an engineer joining a new team already knows how it works. Factory code never converged.

"If you go to Reddit right now and ask people how they do version control, a lot of the answers are 'I just save my file name with the date, or with a description of the changes.' That's the state of the industry."

That "which copy is real?" problem hits a panel's wiring paperwork too. Blitzpanel builds every panel so the drawings always match what's actually inside. Build a panel with us.

But Is Any of That Actually Version Control?

Mostly, no. It's worth being precise about why, because the fix depends on it.

In software, "version control" means a specific set of things: one source of truth, a running history of every discrete change, each change tagged with who made it, when, and why, the ability to compare any two versions and see exactly what differs, a review step before a change goes live, and a clean way to roll back. Git is the canonical example, and it's free, so the entire industry standardized on it.

Hold factory practice up to that definition and most of it falls short:

A date-stamped filename captures a snapshot, not a change. Final_V3 doesn't tell you what's different from Final_V2, who changed it, or why.

Emailing or Slacking files isn't tracking at all — it's distribution, and it's the thing that breaks the single source of truth.

A nightly automated backup is disaster-recovery insurance. It tells you what the program was at 2 a.m. last Tuesday. Version control tells you what changed, who changed it, and why.

Karthik drew that last line from experience:

"We used one tool for version control and another for disaster recovery. It automatically backs up the PLC every day on a schedule. That gives you some version-control capability, but it's not really user-friendly, and we weren't using it as a team to collaborate. We only touched it when we had to. As long as the PLCs were running, we just kept backing up automatically."

A backup can restore yesterday's program. It can't tell you how it differs from today's, or which of five folder copies you actually meant to keep. Real version control—history, authorship, review, diffing the actual logic—is the part that's mostly missing.

Why Factory Code Resists Real Version Control

So why not just adopt Git and be done with it? Because Git assumes three things the factory doesn't provide:

Readable files. A PLC project is saved as a proprietary binary—a dense blob with nothing a person can skim. Open two versions side by side and you can't spot what changed, which is the entire point.

Text-based code. Even setting the file format aside, most PLC logic is authored as ladder: a wiring-style diagram engineers read at a glance. Git compares lines of text. A diagram gives it nothing to line up.

Comparable copies. Software engineers freely spin up copies to test ideas. A factory has one physical controller, wired to live motors and safety circuits, running right now. You can't stand up a second copy of a moving production line just to compare.

You can force Git onto factory code, but here's what that actually takes:

"The format Studio 5000 stores its files in is a binary file, and binary files aren't compatible with GitHub or Git-based platforms. So you have to export it to XML. XML has a bunch of data you don't need as a programmer. You clean it up, then you have to find a way to represent it back in ladder format, because engineers are used to seeing ladder. You're basically reverse-engineering everything."

Translate the program out of its native format, scrub it, rebuild it into something an engineer can read, and hope nothing got mangled on the way. Most of what makes Git great — line-by-line diffs and cheap throwaway copies — simply doesn't apply to a picture running on one live machine. There's also resistance from the people in the factories themselves:

"There's a lot of resistance to change in our industry, especially in how we program. People who use Studio 5000 want to keep using Studio 5000 for as long as they program."

That resistance might make sense in the short term. Across decades, it's expensive.

The Tools That Do Exist

The market has a few partial answers, in three flavors:

Compare tools built into the big brands. Rockwell and Siemens each include a way to compare two versions of a program. Handy, but locked to that one brand and not built for teams.

Backup-and-archive systems. Tools like Octoplant (formerly VersionDog) and MDT AutoSave quietly poll controllers, save every program, and raise a flag when the running machine no longer matches the saved copy. Great for recovery and audits — weak as a way for a team to actually work together.

Modern, Git-style tools for ladder. A few newer platforms (Copia is the notable one) can finally compare the ladder diagram itself, with proper history, branching, and review. This is the closest anyone has come to how software teams work.

What's missing is a free, open version everyone can rally around. In software, the standard tools are free and community-owned. Factory version control has mostly stayed behind paid products. Karthik thinks that's the gap worth closing:

"Version control is so fundamental to developing programs that it should be open source. The goal is a platform as reliable and as widely trusted as GitHub—so intuitive and easy to use that people naturally reach for it instead of dealing with the mess."

Why It Matters

If you build, buy, or run control panels, this isn't housekeeping. It's risk management on three fronts.

Downtime. If a controller dies and your newest good copy is six months old, you'll reload outdated logic. Best case, the line runs wrong; worst case, you bring back a hazard you'd already fixed.

Rules and security. Standards like IEC 62443 and 21 CFR Part 11 increasingly demand a paper trail showing who changed the safety logic and when. A backup can't prove that. Version control can, and it's shifting from nice-to-have to required.

Reputation. How a shop handles its code is a quick read on how it handles everything. A team that can tell you exactly what's running, and what changed last, is a team that has its act together.

The tools are catching up. The shared habit isn't here yet. But the direction is obvious: the industry still naming files Final_V3 is going to end up looking a lot more like the software world it's been quietly borrowing from.

Version control for PLC code may still be catching up—but the hardware it runs on doesn't have to be a guessing game. Here at Blitzpanel, every UL-certified panel we build ships wired, labeled, and fully documented. Start a project with us.

Frequently Asked Questions

What is Blitzpanel?

Blitzpanel designs and builds custom electrical control panels. We work with engineers, OEMs, and integrators, providing expert engineering expertise and manufacturing support so panels are built right, documented properly, and delivered fast. Book a call with us here.

Do controls engineers actually "version control" their code?

Usually not in the way a software engineer means it. Most shops rely on date-stamped filenames, emailed or messaged copies, and automated nightly backups. Those are backup and file-naming habits, not version control. They don't give you a tracked history of who changed what and why, a diff of the actual logic, or a review step before a change goes live. True version control exists for PLCs, but adoption is still rare.

Can you use Git for PLC programs?

Technically yes, but by default it won't do what you want. Native project files from Studio 5000 or TIA Portal are proprietary binaries, so a standard comparison shows nothing readable. You can't see that a rung was added or a control loop retuned. Getting real value out of Git means exporting to a text format (like L5X/XML), stripping the noise, and often rebuilding a ladder view, or using a purpose-built tool that compares the logic directly.

What's the difference between a PLC backup and version control?

They answer different questions. An automated backup captures whatever is running, on a schedule. It's disaster-recovery insurance, and it tells you what the program was at a given moment. Version control tells you what changed, who changed it, and why, and it lets a team review a change before it goes live. Many plants have solid backups but no real version control, which is why they can restore yesterday's program but can't explain how it differs from the copy on someone's laptop.

Is there an industry standard for PLC version control?

No. Software converged on Git, but PLC programming never settled on a shared convention. In practice, approaches range from date-stamped filenames and emailed copies to vendor compare tools and commercial change-management systems. It varies from one company to the next, and often from one team to the next inside the same company.

What tools exist for PLC version control?

Roughly three tiers. Vendor compare tools (Studio 5000's compare, TIA Portal's project compare and Version Control Interface) work within a single ecosystem. Backup and change-management systems like Octoplant (formerly VersionDog) and MDT AutoSave poll controllers, archive programs, and flag when a running program no longer matches the archive. And Git-native tools like Copia compare and merge the ladder logic itself, with branching and review. Free, self-hostable open-source options remain scarce.

Do I need version control if I only have one machine?

Even a single controller drifts. The "real" program can live on the PLC, on a laptop, and on a USB stick at the same time, and one online edit to a running machine can quietly knock them out of sync. Version control matters most when multiple engineers or integrators touch a system over its life, or when you need to recover or audit it. But even a one-machine shop benefits from knowing exactly which copy is current.

Does version control help with compliance and cybersecurity?

Increasingly, yes. Standards like IEC 62443, and 21 CFR Part 11 in regulated industries, expect an audit trail proving who changed safety-relevant logic and when. A backup can't produce that; version control can. As those requirements tighten, revision control is shifting from good hygiene toward a hard requirement.

Why is Studio 5000's file format hard to version?

The native project file (.ACD) is binary, so it doesn't compare meaningfully in Git. Exporting to L5X gives you an XML text file that's far more Git-friendly, but it's verbose, carries data a programmer doesn't need, and drops the native ladder view unless it's rebuilt. That export-clean-rebuild cycle is the core friction behind versioning Rockwell projects.