Siemens PLC interview questions, answered by engineers

OB (Organization Block) — the entry point called by the CPU operating system. OB1 is the main cyclic block; separate OBs exist for startup, cyclic interrupts, hardware interrupts and error handling.
FC (Function) — a block with no memory of its own. Every call starts clean; anything it must remember has to be passed in or stored elsewhere.
FB (Function Block) — a block with an associated instance data block, so it retains state between calls. This is what makes it correct for motors, valves, timers and PID objects.
DB (Data Block) — data storage, either as the instance DB belonging to an FB call or as a global DB shared across the program.

The answer that shows real understanding is the why: you choose an FB when the object has state that must survive between scans, and an FC when the logic is a pure calculation.

This is the single most reliable hands-on discriminator on the Siemens list. With optimized block access, the CPU arranges data-block variables in memory in whatever order it considers most efficient, and you address them symbolically. There is no guaranteed fixed offset — so an address like DB10.DBW4 has no stable meaning.

That is faster and safer inside the program. But any external client that addresses by absolute offset — an older HMI, a third-party SCADA driver, a Modbus mapping, a reporting tool — can no longer resolve the address. Switch a DB between optimized and standard access, or resize a structure inside it, and those tags silently break or, worse, read the wrong variable.

The correct handling: use symbolic access end-to-end where the client supports it, and where it does not, deliberately set that specific exchange data block to standard (non-optimized) access and document it as an interface.

A single instance gives an FB call its own dedicated instance DB — clear and easy to browse, but it multiplies DBs when you have many identical objects. A multi-instance stores a called FB's data inside the calling FB's instance DB, which is the right pattern when you build a composite object (a station FB that internally calls motor, valve and timer FBs) and want one clean data structure per station rather than fifty scattered DBs.

Strong candidates connect the choice to maintenance: multi-instance keeps the object hierarchy visible in the data structure, so a maintenance engineer can find "station 4's outfeed motor" without a cross-reference hunt.

An instance DB belongs to a specific FB call and holds that call's parameters and static data; its structure is defined by the FB interface and changes when the FB changes. A global DB is a free-standing data area you define yourself and any block can access — used for recipes, machine setpoints, interface areas to the HMI, and data exchanged with other systems.

The practical discipline: keep the global DBs that form external interfaces deliberately stable and documented, because everything outside the PLC depends on them.

The library holds reusable, version-controlled types — blocks, HMI faceplates, data types, screens — that can be deployed across projects and updated centrally. Interviewers ask because it separates two kinds of engineer: the one who copy-pastes a motor block into forty projects and then cannot fix a bug in any of them, and the one who maintains a versioned typed library and can push a corrected version through a controlled update.

A senior answer mentions versioning and the update workflow — knowing that instances must be updated to the new type version, and that this needs to be planned, tested and re-verified rather than done casually on a live machine.

The pairing is driven by CPU firmware, not by preference. A given TIA Portal version supports firmware up to a defined level, so a CPU running newer firmware needs an engineering version that carries it in its hardware catalogue. This is why a project opened in an older TIA Portal can show a CPU as unavailable, or push you to configure a lower firmware level than the hardware actually runs.

The operationally-aware answer goes further: teams standardise one engineering version per plant and control it deliberately, because a project file upgraded on one laptop cannot be opened by a colleague on the older version — a genuine site-support hazard when a machine is down.

Always confirm the exact supported version and firmware combination against current Siemens documentation for the specific CPU before committing to it — this pairing changes with each release.

The honest senior answer describes discipline, not a tool. Archive a dated, named project archive before and after every site change. Keep a change log inside the project (a commented block or documented header) recording who changed what and why. Use the library for typed reusable content so a fix propagates deliberately. Compare online against offline before you assume the file you have matches the running machine — and treat the controller as the source of truth during a breakdown, not the laptop.

Candidates who have supported a plant will raise the failure they have lived through: a machine down, three project files in circulation, and nobody able to prove which one is running.

PROFIBUS DP is a serial fieldbus on RS-485, running from 9.6 kbps up to 12 Mbps, with a master polling addressed slaves. PROFINET is industrial Ethernet — standard Ethernet hardware with real-time extensions — and is the default for new Siemens designs. Both are standardised under the IEC 61158/61784 families and governed by PROFIBUS & PROFINET International.

The difference that matters day to day is identification: PROFIBUS devices are identified by a bus address set on the device, PROFINET devices by a device name stored in the device. That single distinction drives most of the field troubleshooting on each.

Almost always: the device name was never assigned. PROFINET identifies IO devices by name, and the name lives in the device — not in the cable, not in the slot, not in the switch port. A brand-new replacement arrives without the name the controller is looking for, so the controller never establishes the connection even though the physical link is perfect.

The fix is to assign the same PROFINET device name to the replacement using the engineering tool, or to rely on a configured automatic device replacement scheme — which itself only works if the topology is defined in the project, because the controller infers the device's identity from its neighbours.

Second and third candidates, in field-probability order: an IP conflict (frequently a laptop someone left plugged into the machine network), and a topology mismatch that defeats automatic replacement.

Exactly two active, powered terminations — one at each physical end of the segment, and nowhere else. "Powered" matters: the termination network needs supply from the connector, which is why a terminated device that is switched off can take the segment down.

Ranked by how often it is actually the cause in the field:

1 — A terminator switched on at a device in the middle of the run. The classic.
2 — Segment length exceeding the limit for the baud rate — at 1.5 Mbps the segment limit is around 200 m, and it shortens as the rate rises.
3 — Stub or spur lines off the RS-485 trunk, which are not permitted at higher rates.
4 — A connector screen not properly seated, so the shield is effectively floating.

RT (Real Time) is soft real-time over standard Ethernet hardware — cycle times of roughly a millisecond, with jitter acceptable for ordinary distributed I/O and process control. IRT (Isochronous Real Time) reserves bandwidth in hardware-synchronised switches to deliver hard real-time with jitter below a microsecond.

The engineering point: you specify IRT when axes must be genuinely synchronised to each other, and you accept that it constrains your hardware — IRT needs switches that support it, and a planned topology. Using RT where IRT is required produces a machine that almost works, which is the worst outcome to debug.

Check before touching the wiring: the diagnostic LED pattern on the devices and the master's diagnostic buffer. Then, in probability order — an address conflict with an existing slave; the new device's terminator switched on mid-bus; and a GSD file mismatch causing a parameterisation fault, where the configured device profile does not match the hardware actually fitted.

Reading diagnostics first is the marker. Engineers who have worked a live plant know that pulling connectors on a running segment to "test" makes a one-device problem into an outage.

By zones and conduits, per IEC 62443. Control-level traffic (controller to distributed I/O, controller to controller) sits in its own zone on its own switching. Supervisory traffic (HMI, SCADA, historian collection) sits above it. Anything crossing to the business network crosses through a defined, controlled conduit with a demilitarised zone in between — not a straight route.

The hard line a senior engineer will state plainly: a controller does not talk directly to a public cloud service. If plant data needs to reach a cloud platform, it goes via an edge or historian node at the supervisory or site level, through the DMZ. Flattening those levels onto one network to save a switch is the architecture mistake that shows up in every OT security audit.

The diagnostic buffer, first, before anything else. It timestamps the events leading to STOP in order, so the most recent entries name the trigger directly — a programming error such as an area-length or unassigned-pointer access, a rack or station failure, a module fault, or a scan-cycle overrun. That entry also tells you which error OB was missing to intercept it.

Only then do you go outward: module LEDs, the failed station, the field. And before you change anything, archive the current state — upload and save the running program and parameters. That is the escape hatch every engineer eventually wishes they had taken.

Leakage current, most likely from a two-wire proximity sensor. Two-wire sensors need a small residual current to power their own electronics even in the OFF state, and if that leakage exceeds the input card's OFF threshold, the PLC sees a permanent ON.

How to confirm in the field: measure the voltage at the input terminal with the sensor disconnected — more than a few volts indicates leakage. The fix is a bleeder resistor across the input to sink the leakage below threshold. Other candidates: moisture bridging the terminals, or a genuinely failed input channel.

Wiggle-test the common / 0 V terminal on that module first. One loose common takes down the whole group, and it is by far the most frequent cause of a "several inputs on one module" pattern — the pattern itself is the clue, because a single failing channel does not present that way.

Next: an unshielded input cable sharing a tray or duct with VFD output cables — electrical noise coupling straight into the signal. Then a failing module power rail.

In field order: an earth loop, where the transmitter and the PLC are earthed at different potentials; a shield earthed at both ends, which creates exactly that loop; or loop resistance over budget because too many devices are in series on a 4–20 mA loop.

How to confirm the earth loop: measure the voltage between the two earth points. More than about a volt and you have found it. The rule that follows: the shield lands at one end only — the control-room / panel end — always, and a 360° clamp is better than a pigtail.

Modify writes a value once; the program can immediately overwrite it on the next scan. Force overrides the value persistently at the I/O level, so the program cannot change it — which is precisely why it is dangerous.

The rule every commissioning engineer states without being asked: forces are logged, and a force-removal audit is mandatory before handover. A forgotten forced interlock is a latent incident waiting for the right conditions. Candidates who describe their force log and their sign-off procedure have been through a real commissioning; those who describe only the happy path have not.

Scan the program for a double coil — a cross-reference on the tag. It costs nothing and it is frequently the answer. Then measure the 24 V rail under full load, because a marginal supply dipping when several outputs pull in produces exactly this symptom. Third: worn relay output contacts on an inductive load with no suppression fitted.

At least 300 mm of separation, or a steel barrier between them, and where they must cross, they cross at 90°. The mechanism is the reason: a VFD output is a fast-switching, high-dV/dt waveform that capacitively and inductively couples into any conductor running parallel alongside it. Distance and perpendicular crossing both reduce the coupled energy; a steel barrier gives you the separation when the duct space does not.

This is a deliberate screening question — panel-fluent engineers answer in millimetres and mechanism. Candidates who say "we follow the standard" have specified panels but never traced a noise fault back to a cable tray.

The answer interviewers want is boring and procedural, because that is what the job is. A signed loop folder per loop. Force the signal at the field device — not at the terminal, not in software — and observe it at the HMI, so the entire chain is proven. For outputs, prove it in both directions. Record the result against the loop number with a signature and a date.

Commissioning-fluent engineers volunteer the paperwork discipline unprompted. The ones who describe only the happy path have never had a startup punch list handed back to them.

A FAT (Factory Acceptance Test) happens at the integrator's works before shipment, proving the system against specification in a controlled environment. A SAT (Site Acceptance Test) happens after installation, against real field I/O, real instruments and real process conditions.

The insight that marks experience: FAT with simulated I/O cannot catch earth loops, cable transpositions or device polarity errors — and that is exactly where SAT punch lists concentrate. Engineers who have run both budget SAT time accordingly rather than treating it as a formality, and expect a meaningful proportion of loops to throw at least one punch item on first checkout.

Cause forced at source — at the actual initiating device — not by pressing a button on the HMI to simulate the condition. Each line of the cause-and-effect matrix is tested and signed individually. Demonstration testing proves the graphic works; it does not prove the interlock works.

And every motor gets a bump test for rotation direction after cable termination. Three-phase transposition between panel and field is routine when different contractors terminate each end.

The current SIMATIC line for new machine and plant automation is the S7-1200 / S7-1500 family in TIA Portal, with the S7-1500 positioned as the successor tier for S7-300 and S7-400 class applications. Older SIMATIC S5 installations map forward to the same current family.

What makes it harder than a conversion wizard suggests: the memory model and addressing change (symbolic and optimized access), block interfaces change, and HMI tag structures and libraries have to be reworked to match. A realistic plan therefore describes convert, then rework, then re-verify — including a full re-run of interlock tests and loop checks, because the logic is not the same logic even when it looks identical on screen.

Confirm the supported engineering-tool and firmware combination against current Siemens documentation before committing to a migration plan; these pairings change with each release.

Capture the as-found state. Upload and archive the PLC program, the drive parameters and the instrument configuration before any modification, and store it somewhere that is not the laptop in your bag. Photograph the panel and the terminal state. Note the machine's current behaviour, including the faults it already had.

This is the answer that separates engineers who have been burned from those who have not. When the modification does not work and the plant needs to run tomorrow morning, the as-found archive is the only route back.

Heat and dust, and then the monsoon. Panel thermal design has to be calculated against a real summer ambient rather than a nominal 25 °C, because drives inside a sealed enclosure add their own losses on top of it — fan-and-filter is a minimum, and above the higher ambient bands you are looking at panel cooling. Filters in a dusty plant clog within months, and nuisance trips follow, so the maintenance interval is part of the design, not an afterthought.

Then the seasonal pattern: humidity ingress and earth faults that appear every monsoon and clear in the dry season. An engineer with genuine Indian plant experience volunteers that pattern without being prompted — it is one of the most reliable authenticity markers in a screening call.