Siemens PLC Ladder Networks: Structure, Rules, and Best Practices

Overview: Why Networks Are First-Class Structures in Siemens Ladder Logic

In Siemens STEP 7 (V5.4/V5.5/V5.6) and TIA Portal (V13 through V19), a Network (German: Netzwerk) is not merely a visual separator — it is a logical container that controls rung evaluation semantics, enables label/jump targets, carries title and comment blocks, and stamps author/date metadata on every code segment. Collapsing all networks in a Function Block (FB), Function (FC), or Organization Block (OB) while keeping only the network titles visible produces a high-level flowchart of the program. Months or years later, the original author — or a completely different engineer — can refresh their understanding of the program in minutes instead of wading through hundreds of unbroken rungs.

Networks also address a structural limitation that is unique to Siemens ladder (called KOP in German, LAD in English): every network begins with an implicit AND stack state. Unlike Allen-Bradley RSLogix 500/5000 or Studio 5000, where a retentive XIC (Examine If Closed) contact persists across rungs, Siemens resets its accumulator logic at the network boundary. This is the single most important rule to internalize when converting RSLogix programs to Siemens and is covered in detail below.

Network Architecture in STEP 7 V5.x and TIA Portal

A Siemens ladder logic program block (OB, FB, FC, DB-initializer) consists of an ordered sequence of networks. Each network contains a header area and a body area.

The network boundary is hard for the LAD compiler: a contact or coil on Network N cannot be combined via implicit OR/AND continuation into Network N+1. If you need the result of Network N to feed Network N+1, you must use one of:

• A bit memory (M) or global DB tag as a handshake
• An EN/ENO parameter on a called FB/FC
• A label and JMP (jump back into the same network structure)

Reference: Siemens Support Entry 109751814 — Programming and Operating Manual STEP 7 V5.x

The Boolean State Rule: Why Every Network Must Start With AND

This is the rule that catches every engineer coming from Allen-Bradley, Modicon, or direct STL backgrounds. In Siemens LAD, the compiler maintains an implicit VKE (Verknüpfungsergebnis — logical operation result), the equivalent of the accumulator in STL. The rule is:

What this means practically in LAD:

• Series of NO contacts at the top of every network is mandatory — you cannot start with a normally-open branch input; you must build a top rail of contacts in series.
• You cannot perform an OR operation that "remembers" the previous network's state. Each network is its own logical sandbox.
• This is why a coil that drives a tag on Network 2 cannot be the implicit input of an OR on Network 3. You must reference the tag via a fresh contact.

The trade-off is clean isolation: each network is locally auditable because no hidden state leaks across the boundary except what you explicitly write to a tag.

Reference: Siemens — STEP 7 V5.x LAD/FBD/STL Programming Reference, Section 3.2 (Bit Logic Instructions)

Labels, Jumps, and Network Navigation

Labels (LBL in STL, Sprungmarke) and jumps (JC — jump if VKE=1, JCN — jump if VKE=0, JU — unconditional jump) in Siemens ladder are bound to networks. In TIA Portal and STEP 7, you cannot place a label mid-network in LAD; the label must be the first symbol of a network. This structural rule is why networks exist as separate compilation units.

Practical guideline: Use jumps sparingly. Each jump is a hidden GOTO and breaks the top-down reading flow. Modern TIA Portal code style favors SCL (Structured Control Language) for complex branching — SCL's IF / CASE / FOR / WHILE is compiled to the same MC7 code but reads like a high-level language and is fully network-aware inside FBs.

Reference: Siemens — STEP 7 V5.x Jump Instructions

Comments, Titles, and Author Stamps

STEP 7 V5.4 and later stamp every segment (network) with the following read-only metadata, visible from the LAD/FBD editor and from the cross-reference (XRef) tab:

• Author — Windows login of last editor (configurable in TIA Portal Project Settings)
• Created — Timestamp of network creation
• Last modified — Timestamp of most recent change
• Checksum / MD5 (TIA Portal V16+) — detects post-compile edits in blocks

This metadata is your audit trail. When commissioning or troubleshooting, you can immediately answer "who wrote this and when?" without checking source control. Pair this with a network title and a multi-line comment and you get self-documenting code that survives personnel turnover.

Recommended comment structure per network:

1. Title (one line) — A verb-phrase describing what the network does: e.g., "Start pump 1 when level > 80% and not in fault".
2. Comment (multi-line) — Why this exists, what tag names mean, what the failure mode is, and any cross-references to the electrical drawing or P&ID.
3. Tags / constants table (optional) — Quick-reference for non-obvious constants used in the network.

Reference: Siemens — STEP 7 V5.x Editor Reference (Network Header and Comment Fields)

Multi-Coil Branching Rules and the TIA Portal Change

Historical ladder logic allows you to drive multiple coils from a single rung by branching. Each branch can end in its own coil assignment. In STEP 7 V5.x and TIA Portal up to V15, this works as expected. In TIA Portal V16 and later, Siemens introduced stricter compiler warnings (not errors) about "multiple coil assignments" to the same tag — these are visible as warning W: "Assignment to coil that is already assigned in this network or block" in the compile log.

The rules in detail:

Cross-Network Tag Handling: NO/NC and Shared Bits

A common confusion — discussed in the Siemens SiePortal community thread "Ladder logic — Tag values in different networks" — is whether a tag's NO (normally open) and NC (normally closed) representations in different networks see the same value. The answer is yes, always: a BOOL tag has one value in the process image (or directly in memory for non-I/O tags), and every NO/NC contact reads that same value at the moment the network is evaluated.

However, you will get surprising behavior if:

1. You write to the tag within the same scan cycle before reading it — common when a CNT (counter) or timer reset is in Network 2 and the contact evaluation is in Network 3. Both networks run in the same OB1 scan, so the reset takes effect immediately.
2. You read from a tag whose source is a peripheral input (PIW/PQB) updated asynchronously — the process-image update occurs at a fixed point in OB1, not when your network runs.
3. You read from a multi-instance DB tag and the FB runs in a different priority class — OB35 (cyclic interrupt) writes to a tag that OB1 (main) reads. Time-of-update depends on OB priority.

Reference: Siemens — Process Image and OB1 Scan Cycle (STEP 7 V5.x)

STEP 7 V5.x vs TIA Portal: Network Differences

TIA Portal V16+ also introduced network-level software units — a single FB can now be split into multiple compilation units, each with its own version, but this is an organizational feature, not a network feature.

Reference: Siemens — TIA Portal V18 Programming Reference

Network Organization Best Practices

1. One logical decision per network. If your title cannot describe the network in a single verb-phrase, split it. Multi-decision networks are the #1 source of "I cannot read this anymore" comments six months after commissioning.
2. Top-down flow. Network 1: Inputs scan and conditioning. Network 2: Permissives. Network 3: Mode selection. Network 4: Outputs. Network 5: Fault handling. Repeat this skeleton for every FB and your team will read the code like a book.
3. Limit network size to ~15 contacts/coils on a standard 24-inch engineering monitor. Anything wider requires horizontal scrolling, which kills reviewability.
4. Naming convention for networks. Use a structured prefix when exporting to documentation: [SECTION].[SUBSECTION] Verb Object — e.g., 2.1 Start Pump P-101, 2.2 Stop Pump P-101, 2.3 Acknowledge Fault.
5. Never reuse a network number (the number assigned by the compiler). When you delete a network, the number is gone forever. Insert your new logic at the bottom and renumber using the TIA Portal / STEP 7 "Reorder Networks" tool.
6. Comment on intent, not mechanics. "If start button pressed" is a comment that duplicates the code. "Allow start only if pump is healthy and tank level > 30%" explains why the network exists.

Common Pitfalls and Troubleshooting Matrix

Reference: Siemens — TIA Portal Compile Error Reference (V18)

Network Counts by Application Type

From field experience, the following network density ranges produce maintainable code. If your block falls outside these ranges, refactor before commissioning:

These are guidelines, not hard limits. A well-commented 60-network motor controller will outperform a poorly-commented 12-network one.

Verification Checklist Before Commissioning

1. Collapse all networks in every FB/FC/OB and read only the titles top-to-bottom. The result should describe the program's behavior in plain English.
2. Compile with all warnings enabled — in TIA Portal: Project → Properties → Compile. In STEP 7 V5.x: Options → Custom → "Display all warnings".
3. Cross-reference every output tag to verify it is driven from exactly one network (or intentionally driven from two with a documented reason).
4. Walk the program offline with the CPU in STOP and the monitor table forcing all inputs through one state machine.
5. Print to PDF with the network comments visible (TIA Portal: Project Documentation → Generate; STEP 7: File → Print with all expanded). Hand it to a colleague unfamiliar with the project. If they cannot explain the program in 15 minutes, refactor.
6. Sign and date the network metadata in the project properties so future engineers know the source.

FAQ