Function Block Diagram

How it works

A function block diagram is a set of blocks, each with named input pins on the left and output pins on the right, connected by wires that carry values. A block executes when its inputs are available and produces its outputs; the next block along the wire consumes them. The diagram reads like a signal path: the raw input enters at the left, passes through scaling, filtering, and validation, feeds a PID controller, and leaves as a speed reference at the right.

Blocks can be standard instructions supplied by the platform, such as a timer, a comparator, or a PID, or user-defined function blocks written in any IEC language. A wire can carry any data type, including a structure, which is how a whole pump status travels from block to block as one connection.

Execution order

In a text language the order of statements is explicit. In a diagram it is implied by the wiring, and the platform resolves it: blocks execute in an order that ensures each has its inputs before it runs, generally left to right and top to bottom where the wiring allows. That works until the diagram has a feedback loop, where the output of a block feeds back to an input of an earlier block. Then some value must come from the previous scan, and the platform either requires a marker on the feedback wire or picks one silently.

Where FBD fits

User-defined function blocks

The reason FBD carries so much of a modern program is the user-defined function block. A block called PumpControl is written once, with inputs for the call, the run feedback, the fault inputs, the HOA state, and the setpoints, and outputs for the run command, the status word, the alarms, and the run time. Every pump in the plant is an instance of that block, wired to its own I/O. When the failed-to-prove logic needs a change, it changes in one place and every pump gets it.

1. 1

   Define the interface

   Inputs and outputs as structures where the platform supports it: one command structure in, one status structure out, plus the configuration parameters. A block with forty loose pins is hard to wire and harder to read.

2. 2

   Write the internals in the language that suits them

   The interlock logic can be ladder; the timers and counters can be FBD; the state machine is structured text. The block hides which.

3. 3

   Publish the state

   The block writes its mode, its active hold reason, its fault list, and its counters to the status structure, so the HMI faceplate and the online monitor show what it is doing without opening it.

4. 4

   Test it once, well

   Simulate every input combination the block claims to handle, including the failure cases. That test is worth repeating on every revision, because every pump depends on it.

5. 5

   Version it

   A block used a hundred times needs a version number in its description and a change record. A silent edit to a shared block is a change to a hundred pumps.

Keeping a diagram readable

• Signal enters at the left, leaves at the right, and does not double back.
• One idea per sheet: one loop, one pump, one analyzer. Cross-sheet connections use named tags, not wires that leave the page.
• Name every intermediate wire that carries something an operator or a troubleshooter would want to see. Unnamed wires cannot be trended.
• Align blocks in the order they execute and keep the wiring uncrossed where possible. A diagram that looks like a circuit board is not being read by anyone.
• Put constants in named parameters, not in literal pins scattered across the sheet.
• Comment the sheet with what it does and why, at the top, once.