Walk onto most factory floors and ask where the current version of the PLC program lives. The answer is usually one of three places: a network share named PLC_Backup with 47 folders sorted by date, the laptop of the controls engineer who left six months ago, or — most concerning — the PLC itself, and we hope it never loses power long enough for the capacitor to drain. This ad-hoc approach works until a processor fault requires restoring from backup, an auditor asks for a change history of a safety-related function, or two engineers make conflicting edits to the same routine. This article lays out a practical version control and change management workflow for PLC programs — from the network share that most plants start with to the Git-based automation that a few are beginning to adopt.
Why PLC Version Control Is Harder Than Software Version Control
PLC programs are not plain text. A Rockwell ACD file, a Siemens TIA Portal project, and a CODESYS project are binary or proprietary-format archives that cannot be diffed line-by-line the way a Python script can. This means the core software engineering tool — comparing two versions to see exactly what changed — does not work out of the box for PLC code. A diff of two ACD files returns "binary files differ," which tells a controls engineer nothing about whether the change was a timer preset adjustment or a complete rewrite of the safety interlock.
Modern PLC engineering platforms are beginning to address this. The Emerson PACSystems RX3i CPL410, running on a Linux-based runtime, supports exporting control logic in plain-text structured text and function block representations that can be stored in Git. CODESYS-based platforms can export projects as PLCopen XML which — while verbose — is diffable. Even for platforms without native text export, a disciplined manual export workflow is the first step out of the network-share trap.
Building a Practical Version Control Workflow: Four Levels of Maturity
Level 1 — Centralized Backup: All PLC program files live on a versioned network share or NAS with automated daily snapshots. File naming convention is enforced: MachineID_Date_EngineerInitials_ChangeDescription. This is the minimum viable practice for any facility with more than five PLCs. It costs nothing beyond existing IT infrastructure.
Level 2 — Manual Export + Git: After every edit session, the engineer exports the program as a plain-text representation and commits to a Git repository with a commit message describing the change. The binary project file is stored alongside the text export for disaster recovery. This level adds 5–10 minutes to each editing session and provides a complete, diffable change history.
Level 3 — Automated Export on Build: The engineering workstation automatically exports a text representation every time the project is compiled or downloaded. A pre-commit hook pushes the export to Git. The engineer does not need to remember — the toolchain catches every download. This is current best practice for regulated industries where every control change must be traceable to a change request.
Level 4 — CI/CD for Control Logic: A continuous integration pipeline validates every commit against a set of rules: no forced I/O overrides left enabled, all rungs have descriptions, all tags follow the naming convention, and the logic compiles without errors. This is emerging practice requiring an engineering team comfortable with both controls and DevOps — but for automotive and CPG companies managing hundreds of PLCs, the reduction in commissioning errors alone justifies the investment.
Change Management: The Process That Makes Version Control Work
Version control stores the history; change management controls what enters it. Minimum viable change management for PLC programs consists of three elements: a change request that describes what is being changed and why, a risk assessment that identifies which safety functions or validated processes are affected, and a rollback plan that names the previous version file and the person authorized to restore it. For validated processes add a fourth element: a verification test procedure that proves the change works before the system returns to production. Browse PLC platforms for controllers with modern change management toolchain support.
The network share is not the enemy — it is the starting point. The enemy is the belief that the program is in the PLC counts as a backup strategy. It does not. It counts as a single point of failure with a capacitor-backed clock.
