PLC Version Control: The Fix Is Process, Not Filenames

The project panel shows a familiar failure: the online controller does not match the file you opened, the latest change is missing, or the only clue is a folder named PROJECT_FINAL_FINAL. Start here. The fault is not the filename itself. The fault is the lack of one authoritative project, one controlled change path, and one verified release record.

Read the symptom before editing

Do not download, upload, or rename anything yet. First identify what failed: file selection, project comparison, change ownership, or release traceability.

Take the first reading from the controller and engineering workstation: record the project identity displayed by the software, the file modification time, and the result of the platform’s online/offline comparison. If the comparison matches, move to the release-record check. If it differs, preserve both states and identify which one operates the machine before proceeding.

Find the authoritative project

A project cannot be controlled until the team can point to one location and say, “This is the source used for the release.” A shared folder full of dated copies is storage, not version control.

1. List the candidate project copies without changing them.
2. Read each project’s internal identity, engineering metadata, and last saved time where the platform exposes them.
3. Compare each candidate with the online controller using the manufacturer’s comparison function.
4. Check the commissioning or service record for the change that produced the running state.
5. Select the authoritative baseline only after the controller comparison and change record agree.

If one stored copy matches the controller, use it as the candidate baseline and continue to the file-format check. If none matches, upload or otherwise capture the running state through the approved engineering workflow, but keep it separate from every existing candidate. An upload can recover controller-resident logic; it may not recover every workstation-side item, library dependency, annotation, or external configuration.

If multiple copies appear equivalent, compare their project contents rather than trusting names such as PROJECT_V1_REV1 or date-coded folders. Renaming files does not establish ancestry, authorship, or approval.

Check whether the project can be compared

Next, inspect the project representation. This reading decides whether Git-style workflows can provide useful line-level history or only retain whole-file snapshots.

• If the engineering system exports logic and configuration as stable text, place those source artifacts under version control. Review diffs before accepting a change.
• If the project is one large binary file, Git can retain revisions, but ordinary text diff and merge operations cannot explain or combine the internal PLC changes.
• If the platform supplies its own project comparison or server workflow, use that function for engineering-level differences and use the repository for release records, exported source, and supporting documents.

Test this with one controlled edit. Export or save the project, change a single documented element, save again, and inspect the resulting difference. A focused text change means normal review is practical. A complete binary replacement means you need the engineering tool’s comparator or a strict whole-project ownership rule.

Do not waste time changing Git hosting services when the underlying editor still produces an opaque binary project. Bitbucket and GitHub can host repository content, but the project format determines whether reviewers receive a meaningful diff.

Separate source, generated data, and release evidence

Version only the artifacts needed to recreate, audit, and deploy the controller application. Keep temporary files, local caches, and automatically generated output out of the change review when the engineering platform can recreate them.

For each revision, bind these items together:

• The PLC project or stable text exports
• Required libraries and external configuration references
• The reason for the change
• The engineer or controlled account that made it
• The controller or machine scope
• The online/offline comparison result
• The tested release identifier
• Backup and restoration instructions

A separate changelog.txt fails when saving the project and updating the log are independent actions. Generate the history from repository commits or require the change record in the same release transaction. Jira or Trello can track work, but a task card does not prove which project revision reached the controller. Link the task to the immutable release identifier.

Choose one concurrency rule

Commissioning and ad-hoc service create the hardest branch: several engineers may need to change the same application while the machine is active. Pick one ownership model and enforce it.

• Merge workflow: Use it when source is text-based and the engineering format supports repeatable comparison. Integrate and review changes before deployment.
• Exclusive ownership: Use it for binary projects that cannot be merged safely. One engineer owns the editable project; other changes wait or pass through that owner.
• Platform project server: Use a product-specific server, such as Siemens Project Server where it fits the installed workflow, when the engineering platform must coordinate project access. Validate its behavior with a controlled multi-user test before commissioning.

If two engineers can save different copies without a conflict indication, treat the project as exclusive-edit. That is the reading that matters. Adding more filenames, a second shared drive, or another manual spreadsheet will not fix concurrent ownership.

Apply the controlled baseline and verify it

Once you have the authoritative copy, a usable comparison method, and an ownership rule, establish the first controlled release.

1. Back up the running controller state and all required external configuration through the approved platform workflow.
2. Archive competing copies as read-only evidence. Do not silently delete them.
3. Place the selected baseline and its dependencies in the chosen repository or project server.
4. Commit or register the baseline with its machine scope and comparison result.
5. Make one harmless, documented test change in a non-production test context.
6. Review the project-level difference. Confirm that only the intended element changed.
7. Build or validate the project with the installed engineering software.
8. Deploy through the site’s approved change process.
9. Run the online/offline comparison again and record the result against the release identifier.
10. Restore the release on a suitable test target or by the platform’s approved recovery method to prove the backup is usable.

The resolving branch ends only when the running controller matches the registered release and another engineer can locate that release without interpreting filenames. If the comparison still reports differences, stop. Capture the reported objects and determine whether they are logic, configuration, generated metadata, or another online service change before accepting the release.

FAQ