Taking over someone else's PLC program: 4 things to do first
You inherit a program nobody can explain — the previous engineer left, the original documentation is gone, or it was simply "get it running first". The most common mistake here is opening TIA Portal and starting to edit.
Why you must not edit first
In a program that runs, logic that "looks redundant" may well be a patch added after an incident. Touching it without a baseline and without evidence does not remove the problem — it replaces it with the next one, and the next one is harder to find because you introduced it yourself.
The 4 things to do first
- ① Collect evidence — do not edit yet
- Archive everything you can get right now: the program uploaded from the PLC, the diagnostic buffer, alarm history, actual states of the main I/O, and the operators' description of when the problem occurs. This is the raw material for every later judgement — once you start editing, the machine state is gone for good.
- ② Establish a version baseline
- Store the uploaded program as an archive with a date and a note on where it came from, plus one line: "uploaded from the machine on <date>, unmodified". It looks trivial, but it is the only basis on which you can later say what you changed and why — and the starting point that lets the next person take over.
- ③ Static analysis + logical reasoning to narrow the field
- Do not guess from the symptom. Run the program through tooling (division-by-zero risk, array bounds, block call depth, unused variables, naming chaos) to reduce the suspect area to a few blocks. Then list possible causes and rank them by likelihood instead of trying them one by one.
- ④ Verify the conclusion before changing anything
- Change only after the root cause is confirmed in simulation or by single-stepping on site. After the change, run a regression to confirm there are no knock-on effects (fixing A and breaking B is the norm, not the exception). Document every change the same way.
A rule of thumb: when taking over an old program, 90% of the time should go into "understanding what it actually is", and only 10% into "making it what I want". The other way round, you are usually back where you started two weeks later — with more problems than before.
What to ask for (if they have it, take it; if not, still ask)
- Program backups — any version, the older the better (they are useful for comparison)
- PLC model and firmware version (the order number is the most precise)
- I/O list or electrical drawings (even a rough draft helps)
- What faults happened historically and how they were handled (write down verbal accounts too)
- Anyone who knows *why* a piece of logic was written that way — that person is worth more than any document
How we do this kind of work
Program rescue and fault diagnosis are part of our scope (Retrofit · diagnostics · program rescue). Our method is exactly the four steps above: evidence first, conclusions second, no guessing. One boundary worth stating: wiring and hardware replacement, on-machine trace capture and independent verification of safety functions must be done on site — program-layer investigation can be remote, physical problems cannot.