In this guide 6 sections
Folders fail fast once two people edit. Vendor tools see only their own format. A controlled repository records who changed what and why, and tags the version running at each site, so firms with several engineers and many sites should start there.
What goes wrong with shared folders
A shared folder feels simple. Each project gets a directory, and engineers save copies named final, final2 and final_site_edit until the folder cannot show which archive is running on the line. The file names tell you nothing.
The real failure is silent overwrite. Two engineers open one Studio 5000 archive, edit different ladder routines and save over each other, so a conveyor interlock fault returns weeks later after somebody fixed it.
Folders hold no reason for any change. A timestamp says when, but it never says why a TON preset moved or why a tag table lost an alarm.
- Copies with names like final2 and site_edit
- No record of who changed a rung or tag
- Overwrites when two people save the same archive
- Drawings stored apart from the program they describe
What vendor tools give you and where they stop
Controller vendors offer project comparison, multi-user check-in and change logs inside Studio 5000, TIA Portal or CODESYS, which suits a plant standardised on one brand. The limits are practical.
Each tool knows only its own format, so a firm with Rockwell, Siemens and CODESYS controllers, HMI panels and robot backups keeps a different habit for each. Nobody audits any of them. Their histories never meet.
Vendor tools rarely link a program to the electrical drawing set or the commissioning report, and they depend on memory, which engineers lose under deadline. Check-in becomes optional.
What a controlled repository adds
A repository stores every revision with its author, date and message, and you can compare two versions line by line wherever the format allows it. Exported text covers the rest.
Branches let one engineer try a change without disturbing the released program, and a tag marks the version that went live at one site on one day. Creating a branch costs nothing.
Binary project files compare poorly, so many teams also export the program as text or XML on each save, and that export is what makes review practical. Reviewers can finally read diffs.
- Author, date and reason attached to every change
- Tags that mark the version running at each site
- Branches for trials before release
- Drawings, I/O lists and parameter files kept beside the code
- Access rights by engineer and by customer
Knowing which version is live at which site
Every service call starts with one question, what is running there now, and a repository answers it only if each download is recorded against the site and controller. That discipline is the hard part.
Keep a site register listing controller model, firmware, program tag, download date and the engineer who did it, with a column for whether the checksum matched the tagged build. A mismatch means drift.
This register matters most after a bad download, because with a tagged earlier version and a backup taken before the change, recovery takes an hour instead of a day. Recovery stops being a scramble.
A sensible way to move over
Do not migrate every old project. Start with live sites and new work, load the current as-running program, tag it, and keep the old folder read-only.
Write a short rule for the team: nothing is downloaded to a controller unless it is committed first, and the controller is backed up before every change.
Test the whole path once on a spare controller, including a deliberate rollback, because if recovery works there it will work at the site. Do it before the first real site.
PLC site version register
A register listing each controller: site, line, controller model, firmware, HMI and drive files, program tag, download date, engineer, backup file location and checksum match. Below it sit the pre-download steps, with tick boxes for backup, commit and rollback test, and a line for whoever approved the release.
Open a blank worksheet to printQuestions owners ask
Can Git handle PLC project files?
Git stores them without trouble. Binary archives compare poorly, so many teams export the program to text or XML on each save and review the readable copy.
Is a backup of the controller enough?
A backup helps with recovery. It cannot tell you who changed a rung, which tag moved or why, so history and backups solve different problems, and a plant needs both.
Who should be allowed to release a program?
Name a release owner. Everyone can commit, but a release tag should need approval from a named lead engineer or reviewer, so a second pair of eyes checks what reaches a controller.