Vault has no CoDeSys adapter and needs none. Control three files as one atomic set: the project file plus the .ci and .ri written beside it at download. Mark them binary, check the set out exclusively, commit after every download, and label the commit with the release.
Vault has no adapter for CoDeSys, and none is needed. The minimum set to control is three files: the project file plus the .ci and .ri written beside it when you build, download and save. The .ci and .ri carry the compile information that ties a checkout to the code already in the controller. Leave them out of the repository and every clean machine answers a login with the 'project has changed' message. The checks below define the exact set on your own installation, configure Vault around it, and prove a checkout before a release goes near a machine.
The minimum file set
Commit these as one set:
- The project file, the container for program, configuration and visualization.
- The .ci file, the compile information for the code that was downloaded.
- The .ri file, written beside the .ci at the same save. Commit both or the prompt returns.
- Your own libraries, at least their sources, so any released version stays identifiable.
- A version note per release: the programming system version and the target-support package version, in the commit message or a text file in the same commit.
Leave backup copies and autosave artifacts out. The listing in the next section separates them from the real set.
A project file that will not open at all is a different fault; recovering a corrupt CODESYS project file after a crash covers that job.
Check which files your download writes
Confirm the set on your own installation. File layout differs between CoDeSys generations and with project options, so the listing below is the decision, not a fixed list.
- Close the project and record the folder state:
Get-ChildItem -Recurse C:\Projects\MyPlc | Sort-Object LastWriteTime | Select-Object Name,Length,LastWriteTime - Open the project, run a full build, download to the target and save.
- Run the same listing. Every file whose timestamp moved is a candidate for the controlled set.
- Expect the project file, the .ci and the .ri to move. Anything else that moved is a backup or autosave artifact, or a file you need to evaluate.
- If the .ci or .ri never move, the compile record is being written somewhere else. Check the project options and the working folder until you know where, and bring that location into the set.
Set Vault up for binary files
- Mark the project file, the .ci and the .ri as binary. A text merge on any of them corrupts it.
- Put exclusive checkout on the project set. Two engineers cannot merge one binary project, so the lock is the merge policy.
- Keep libraries on their own repository paths, so a library change can be committed alongside the release that uses it.
Commit rules
- Build, download and save, then confirm with the listing that the three files carry the download time.
- Check the project file, .ci and .ri in as a single commit. Partial sets are the main cause of the prompt.
- Label the commit with the target's release identifier, so the set that runs on a field machine can be pulled exactly.
- Add changed libraries to the same commit.
- Never label a mid-edit commit. Its .ci and .ri match no code that ever ran.
- If the download fails, stop before committing; fixing ProgramFetchSynchronousError after a download is its own job.
Recommendation: mark the project file, .ci and .ri as binary, take exclusive checkout on the project set, and commit all three together after every download, labeled with the release identifier, whenever more than one engineer can touch the project. On a single-engineer project the binary marking still matters, because it rules out any text merge reaching the files.
Scenario: proving release REL-7 before it ships
A packaging-line controller ships as REL-7. At 14:05 the engineer builds, downloads to the target and saves. The listing shows exactly three files with new timestamps: the project file, MyPlc.ci and MyPlc.ri, all stamped 14:05. One Vault commit checks in those three files plus the version note, labeled REL-7 at 14:32.
Before the machine ships, the set is proved on the bench. The working folder is deleted, REL-7 is pulled into a new empty folder, and the project opens on a workstation carrying the recorded programming system version and target-support package. The engineer goes online without building or downloading: 0 rebuilds, 1 login, no prompt, and the online view shows program state and values. That is the pass condition. The arithmetic: 3 files moved, 3 files committed, 1 commit to reproduce the release, 0 rebuilds to connect. Had the prompt appeared, the first check is the file timestamps against the commit time.
When the prompt still appears
Work down the symptoms before touching the project.
| Symptom | Cause |
|---|---|
| Prompt on every clean checkout | The committed .ci or .ri is older than the code in the target |
| Prompt only after a teammate's commit | The project file was committed after an edit, without a matching download |
| Prompt on one workstation only | Programming system version, libraries or target-support files differ on that machine |
| Vault reports a merge conflict on the project | Two people had the project checked out; the exclusive lock was not in force |
The workstation-only case is the version trap. Opening a project in a different programming system version can force a conversion or a recompile, and a recompile rewrites the compile record; the version note per release is what lets you level a workstation to match.
One rule holds throughout: do not clear the prompt by rebuilding and downloading again. That writes a fresh compile record into a machine running code you have not reconciled, and it buries the missing file. Fix the set, then go online.
What to send when you escalate
If a complete, correctly ordered set still triggers the prompt, or a project will not open on a workstation at the recorded version, stop and take the vendor's documented support route, with these in hand:
- The programming system version and the target-support package version.
- The timestamped folder listing from before and after the download.
- The Vault commit label and its time.
- Which machines prompt and which do not.
A repository problem ends at the repository. A project that misbehaves on a matching installation belongs with the tool vendor or the target supplier.
Questions
Can two engineers work on the same CoDeSys project at the same time?
Not in one project file. A CoDeSys project is binary, so two sets of edits cannot be merged; the exclusive checkout exists to enforce one worker at a time. If two engineers must work in parallel, give each a separate project, combine the changes by hand in one of them, then build, download and commit the combined set as usual.
What does the 'project has changed' prompt actually mean?
It means the compile information in your checkout does not match the code the controller is running, so the programming system will not present a clean online view. Treat it as a file-set question before anything else: are the .ci and .ri present, current, and committed from the same build that was downloaded? Rebuilding is the last resort, not the fix.
How do I roll a field machine back to an earlier release?
Pull the labeled commit into a new empty folder, on a workstation carrying the programming system version, target-support package and library versions recorded for that release. Open the project and go online without building or downloading; a rebuild writes a new compile record and defeats the point of the label. Verify the online view before you call the rollback done.
My project folder shows no .ci or .ri files at all. What now?
Run the timestamp check anyway: build, download and save, then list the folder again. If nothing except the project file moved, the compile record is being written somewhere else, so check the project options and the working folder until you know where. A set is complete when a fresh checkout into an empty folder goes online with no prompt.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.