Documenting Siemens S7 PLC Programs DOCPRO, S7-Graph Best

Overview: Why Program Documentation Is a Deliverable, Not an Afterthought

Siemens SIMATIC S7-300/400 and S7-1500 PLCs are programmed in three of the four languages defined by IEC 61131-3: Ladder (LAD), Statement List (STL), and Structured Control Language (SCL). The fourth, Sequential Function Chart (SFC) - implemented in Siemens tools as S7-Graph - is itself a graphical documentation of state transitions. The default programming environment, SIMATIC Manager (Step 7 V5.x) or TIA Portal, stores the source of truth in machine-readable blocks (OB, FB, FC, DB, UDT), but the printed, human-readable form is what electricians, maintenance technicians, process engineers, and auditors actually consume.

The field reality: a compressor skid program in STL that ran for 14 years without complaint becomes incomprehensible the day a process engineer who never saw the code is asked to add a permissives interlock. Documentation closes that gap. This reference covers the toolchain (DOCPRO V5.4, S7-Graph, TIA Portal printout functions), the conventions (naming, symbol tables, network comments, structured programming), and the verification steps that turn undocumented logic into an inspectable deliverable.

Tool Selection Matrix for S7-300/400 Documentation

Siemens offers three primary documentation paths. Each fits a different audience and program style.

DOCPRO V5.4 is the canonical documentation package for legacy S7-300/400 plants. It extracts the symbol table, the program structure (OB/FB/FC/DB hierarchy), the cross-reference, and the network comments, then renders them into a project-defined layout. The printout uses a configurable title page, page header (project name, plant designation, document number), and page footer (page n of m, date, generated by). For multi-cabinet panels, DOCPRO can stitch together wiring lists across multiple stations and produce a single plant document.

Structured Programming: FC/FB Division of Labor

Documentation scales with the program only if the program itself is structured. The single most common cause of unreadable S7 code is the "one giant OB1" pattern, where all logic is dumped into cyclic OB1 with shared flags. Replace it with the following hierarchy:

OB1 should read as a table of contents:

Network 1:   // --- Inputs acquisition ---
            CALL  FC_Read_DI
            CALL  FC_Read_AI

Network 2:   // --- Mode selection ---
            CALL  FC_Mode_Selector

Network 3:   // --- Sequential control ---
            CALL  FB_Batch_Sequencer    DB_Batch

A maintenance technician who does not know STL can read this and immediately understand the program shape. That is the goal.

Symbol and Tag Naming Conventions

Siemens S7 supports two parallel naming spaces: the absolute address (I 0.0, MW100, DB10.DBD0) and the symbolic name. The symbol table is the bridge between the two, and it is the first document a non-programmer will read. Adopt a strict prefix scheme and apply it to every entry in the symbol table before the first FB is written.

Avoid raw M-bits and unnamed FCs. A program with 30% symbolic names and 70% absolute addresses cannot be documented, because the printout will show MW 102 instead of MEM_Batch_Running. Enforce the naming scheme at the symbol table, not in code.

Network Titles and Comments: The Non-Programmer's Reading Path

A network title is the single line of text that appears above each LAD/FBD/STL network. Treat it as a sentence, not a fragment.

Block comments go in the Block Properties dialog (Author, Family, Title, Version, Comment). The Comment field is where you store the function description in plain English; it appears on the printout header. The Title field is a 24-character or so summary used in the cross-reference list. The Version field is critical: increment it on every functional change. A printout dated 2018 with Version 1.4 cannot be reconciled with the live PLC if the current source is Version 2.1, and that is the question the auditor will ask.

S7-Graph: Documentation as the Program Itself

For sequential processes - batch recipes, machine cycles, conveyor routing - S7-Graph is the documentation tool that doubles as the programming language. The SFC view shows steps (rectangles) and transitions (small bars with conditions). Each step has a defined action set (N, S, R, D, CALL) and each transition has a Boolean condition expressed in LAD, FBD, or STL.

The S7-Graph online monitor in the SFC view shows the active step highlighted and the satisfied conditions highlighted in green, which is what the field engineer wants when watching a stalled machine. The printout shows the full sequence in graphical form. The documentation trade-off:

• Pro: The SFC is a flow chart. Non-programmers can read the sequence. Online monitoring is intuitive.
• Pro: Steps and transitions have dedicated comment fields, so each state change can be described in plain language.
• Con: S7-Graph is licensed separately. On S7-300/400 it is option package 6ES7811-0CC06-0YA0 (or successor). It only makes sense for sequential logic; continuous control belongs in PID blocks.
• Con: Documentation of parallel and alternative branches is rich in S7-Graph but the print layout is less flexible than DOCPRO. Hand-edit the SFC printout header to add the title page.

Use S7-Graph for state machines, not for everything. A pump start/stop that has 6 permissives and one timer is better as a structured-text FB with a UDT; turning it into a 1-step S7-Graph chain is over-engineering and hurts readability.

DOCPRO V5.4 Configuration and Output

DOCPRO is invoked from SIMATIC Manager via Options > SIMATIC Documentation > DOCPRO. The configuration steps:

1. Create a documentation project. In DOCPRO, define a new project. The project becomes a container for one or more print jobs.
2. Select the S7 program(s) to document. Add the S7-300 or S7-400 station(s). DOCPRO will pull the symbol table, the block folder, and the system data from the offline project.
3. Configure the job structure. A DOCPRO job is a sequenced list of sections. Typical sections in order: Cover page, Table of contents, Plant/Project overview, Symbol table, Block list, Cross-reference, Program printout (per FC/FB), Wiring list, Index.
4. Select the layout. DOCPRO ships with several default layouts. For multi-volume plants, define a custom layout with the project number in the page header and the document ID in the footer.
5. Define cover page fields. Plant designation, document number, revision, date, preparer, approver. These map to the project's automation header (BSK/ATV standard). Lock the fields once the cover is approved.
6. Generate. Output to a printer queue or to PDF via the print driver. Verify pagination and font rendering - field experience shows that some Siemens logos and special characters break under non-Western Windows locale settings.

DOCPRO does not convert STL to flow charts. The program printout is a textual rendering of the source. If the requirement is a graphical flow chart, that has to be drawn separately, typically in Visio, AutoCAD Electrical, or draw.io, against the printed STL as the source of truth.

TIA Portal Printout and Cross-Reference

For TIA Portal projects (S7-1200, S7-1500, and S7-300/400 imported as V15+ portal projects), the printout function replaces DOCPRO for most day-to-day work. The printout is generated from Project tree > Print. Configure the printout to include:

• Project tree (folder/block structure)
• PLC tag table (the modern symbol table) with comments
• Block list with block properties (Author, Title, Version, Family, Comment)
• Block code (LAD/FBD/STL/SCL/GRAPH) with network comments
• Cross-reference (Tools > Cross-reference) showing each tag's use site (read/write/inout) and its network location
• Watch tables and force tables in their current state (audit; do not leave forced values in production)
• Hardware configuration: device list, slot assignment, module order numbers, firmware versions, IP/profinet device names

The cross-reference is the single most valuable document for the non-programmer. A maintenance engineer asked "what writes to MEM_Auto_Mode_Latched?" can answer the question in five seconds with a sorted cross-reference printout. Generate it after every functional change and store the printout alongside the project archive.

Flow Chart Generation: What Works and What Doesn't

Siemens does not provide a tool to auto-convert STL, SCL, or LAD into flow charts. The community has tried several approaches; the realistic options are:

For a brownfield retrofit where the customer wants a flow chart and the code is 2000 lines of STL, the realistic deliverable is a 1-2 page top-level flow chart that names each FC and shows the data flow between them, plus a printout of each FC in source form. Do not promise a fully expanded flow chart of the STL - it is not feasible in budget.

Documentation Verification Checklist

Before signing off a documentation deliverable, run the following matrix against the project. Each row is a check, the column indicates the evidence required.

Field-Proven Pitfalls

The following are failure modes that field engineers have flagged repeatedly. Treat them as design-time red flags, not post-hoc surprises.

• Markers (M area) used in place of symbols. A program with 200 M-bits and 20% symbol coverage is the #1 documentation failure. Every M-bit must have a symbolic name in the symbol table and a comment that explains its purpose.
• OB1 with 80 networks of inline logic. The printout will be unreadable. Restructure into FCs before documenting, or the document will describe an unmaintainable program.
• No version field on blocks. When the next programmer asks "is this the same code that was running in 2019?" the only honest answer is to compare block checksums via online/offline compare and the version metadata.
• DOCPRO cover page out of sync with the program. The cover lists the document number, but the symbol table and program printout were regenerated two revisions later. Lock the cover after regeneration, or set a build script that ties the two together.
• Symbol table comments truncated. The S7 symbol table allows up to 80 characters per symbol and 80 characters per comment. Long device tags get clipped, and the printout shows "AI_PressureTransmitter_PT364" without a unit or range comment. Add the range and units in the comment: // 0-10 bar, 4-20 mA, scale in FC101.
• Forced values left in the printout. A watch table screenshot that includes a forced bit will mislead a future reader into believing it is a normal condition. Clear all forces before the screenshot, and document force operations in a separate log.
• S7-Graph used for non-sequential logic. A PID loop or a continuous process control does not benefit from S7-Graph; the printout becomes a one-step chain with no value added. Reserve S7-Graph for state machines with discrete steps.
• No online/offline verification before generating the printout. A common mistake is to document the offline project without checking that the offline matches the live PLC. Always run an online/offline compare and resolve all differences (or document the approved deviations) before generating the document.

Recommended Documentation Stack by Project Phase

The single most important habit: regenerate the documentation at every functional change. A program that is "in the field, working, documented once in 2017" is, in 2026, a program that no one can modify safely. Documentation is not a milestone; it is a continuous artifact.

FAQ