How to Document a PLC Program Without Original Documentation

To document an undocumented PLC program, start with what you can extract automatically: the block list, cross-reference data, and I/O assignment list. Then systematically work through the program block by block, tracing signal flow from physical inputs through logic to physical outputs. Name every address symbolically as you go. The result is a living document that makes the program maintainable.

This situation is extremely common. The original programmer left the company years ago. The documentation was on a laptop that was reformatted. The filing cabinet with the printouts was cleared out. Or — most commonly — the documentation never existed in the first place. You have a running machine, a PLC with a program in it, and no idea what any of it does.

Step 1: Back Up Everything First#

Before you touch anything, make a complete backup:

For S7 (STEP 7 / TIA Portal):

• Upload the complete program from the PLC (all blocks, symbol table, comments)
• Archive the project (File → Archive)
• Save to at least two locations (USB drive + network)

For S5 (STEP 5):

• Upload using STEP 5 or S5 for Windows (S5W)
• Save the .S5D file to multiple locations
• If you only have the PLC and no software: the S5W demo version can read offline files, but cannot upload from a live PLC. You need the full version or original STEP 5 with a PG cable.

Critical: Never start modifying a program you don't understand. The backup is your safety net. If something goes wrong during documentation or maintenance, you can always restore.

Step 2: Generate the Automatic Reports#

Every Siemens programming tool can generate reference data automatically. These reports are your starting point:

Cross-Reference List (most important)#

The cross-reference list shows every address used in the program and where it appears. For every input, output, flag, timer, counter, and data block address, you see which block uses it and how (read, write, or both).

STEP 7 Classic: Options → Reference Data → Display → Cross Reference

TIA Portal: Right-click on any tag → Cross Reference (or Ctrl+Alt+R for global view)

What this gives you: A complete map of which addresses are used where. If E 0.0 (Input 0.0) is used in OB1 Network 3, FB10 Network 7, and FC22 Network 1, the cross-reference shows all three locations.

I/O Assignment List#

Shows all used input and output addresses. This tells you which physical I/O points the program actually uses — critical for matching addresses to field wiring.

STEP 7: Options → Reference Data → Display → Inputs/Outputs

Block List with Call Structure#

Shows which blocks exist and which blocks call which other blocks. This reveals the program architecture: OB1 calls FB1, FB1 calls FC10, etc.

STEP 7: Options → Reference Data → Display → Program Structure

Symbol Table#

If the previous programmer created symbolic names, they are stored in the symbol table. Even partial symbolic names are valuable — "Motor_Pump1" tells you more than "A 4.0".

STEP 7: Open the Symbols object in the project tree.

Many undocumented programs have an empty or nearly empty symbol table. In that case, you create one from scratch (Step 4).

Step 3: Trace Signal Flow at the Machine#

Sit at the machine with a laptop connected to the PLC. Put the PLC in monitor mode (online observation without making changes). Then systematically trace signals:

Start with the physical I/O:

1. Look at the I/O modules in the cabinet. Note which terminal connects to which input/output address.
2. Activate inputs manually (press buttons, trigger sensors) and observe which addresses change in the PLC monitor.
3. For outputs: observe what happens when each output activates. Which motor starts? Which valve opens? Which light turns on?

Document as you go:

• E 0.0 = Start button, green, panel front
• E 0.1 = Stop button, red, panel front (NC contact)
• E 1.0 = Proximity sensor, conveyor 1, part present
• A 4.0 = Motor contactor K1, conveyor drive
• A 4.1 = Solenoid valve Y1, pneumatic cylinder extend

Pro tip: Take photos of the I/O modules with terminal labels visible. Take photos of the wiring diagrams if they exist in the cabinet door. These photos become part of your documentation.

Step 4: Create the Symbol Table#

Now assign meaningful names to every address you identified. This is the single most valuable documentation step. A program with symbolic names is readable. A program with absolute addresses is cryptic.

Naming convention (recommended):

Enter these names into the symbol table in STEP 7 or TIA Portal. From now on, the program shows symbolic names instead of raw addresses.

Step 5: Document Block by Block#

Work through each program block systematically:

For each block (OB, FB, FC):

1. Read the block title and any existing comments (even in German — translate if needed)
2. Look at the cross-reference: which I/O addresses does this block use?
3. Trace the logic network by network
4. Add a comment to each network describing what it does in plain language
5. Group related networks mentally: "Networks 1-5 = conveyor control", "Networks 6-8 = filling station"

For each data block (DB):

1. List all data words with their purpose
2. Check the cross-reference: which blocks access which DB addresses?
3. Name the DB fields: DB10.DBW0 = "Recipe_Number", DB10.DBW2 = "Target_Weight"

Common patterns to recognize:

• Self-holding circuit: U E0.0 / S M10.0 / U E0.1 / R M10.0 → Start/Stop with latch
• Timer delay: U M10.0 / L KT... / SD T1 / U T1 / = A4.0 → Delayed motor start
• Sequence (step chain): Merker bits controlling a sequence of steps, advanced by conditions
• Analog scaling: Load PEW → arithmetic → transfer to MW/DB → used for display/control
• Handshake: Two bits toggling between PLC and HMI/SCADA for data exchange

Step 6: Create the Documentation Package#

A complete PLC documentation package contains:

1. Program overview: One page describing the purpose, machine type, PLC hardware, and software version
2. Block list: All blocks with description of purpose
3. I/O list: All inputs and outputs with symbolic name, address, description, and terminal/wire number
4. Symbol table: Complete, printed or exported as CSV
5. Cross-reference list: Printed or PDF
6. Network comments: Every network has a comment describing its function
7. Data block layout: All DBs with field descriptions
8. Timer/counter list: All timers and counters with purpose and set values
9. Electrical drawings: If available, scanned and linked
10. Change log: Date, person, and description of every modification going forward

Format: PDF for archival. Keep the live version in the PLC project (comments, symbol table). Store a backup of both the project and the PDF on network storage.

How PLCcheck Pro Helps#

Documenting an undocumented program manually takes 2–5 days for a medium-sized program. PLCcheck Pro can generate most of the documentation automatically:

• Upload your AWL/STL code → instant block inventory with cross-references
• Auto-generated I/O list from all used input/output addresses
• Timer and counter summary with calculated durations
• Plain-language explanation of each network's function
• Exportable documentation as structured report

The AI won't tell you that E 0.0 is a "green start button on the panel front" — that requires being at the machine. But it will tell you that E 0.0 is used in a self-holding circuit that controls A 4.0 through a 5-second on-delay timer. That cuts your documentation time from days to hours.

Upload your code now →

Frequently Asked Questions#

How long does it take to document an undocumented PLC program?

For a medium-sized program (50–100 blocks, 50–200 I/O points): 2–5 working days for complete documentation including machine-side I/O tracing. For a small program (under 30 blocks): 1–2 days. For a large program (200+ blocks): 1–3 weeks.

What if there is no symbol table at all?

Create one from scratch. Start with the I/O addresses you can identify at the machine, then expand as you trace the logic. A partial symbol table is infinitely better than none.

Can I document a program without going to the machine?

Partially. You can generate block lists, cross-references, and trace logic flow from the code alone. But you cannot identify the physical meaning of I/O addresses (what sensor connects to E 1.0) without being at the machine or having wiring diagrams.

What is the minimum documentation I should create?

At a bare minimum: a symbol table and network comments. These live inside the PLC project itself and are available to anyone who connects to the PLC. Everything beyond that (PDF reports, I/O lists) is a bonus.

---

Maintained by PLCcheck.ai. Last update: March 2026. Not affiliated with Siemens AG.