grokkingstuff Home Blog Projects Wiki Calculators About

Transfer Functions & Block Diagrams

date2026-07-24tags:ele: :control:

A transfer function is the Laplace-domain ratio of a system's output to its input under zero initial conditions[fn:: "Zero initial conditions" is the load-bearing caveat: it is what licenses the algebraic treatment. The moment a system stores energy in a capacitor, a spring, or an integrator at =t=0=, the transfer function stops being the whole story and you need the full state-space treatment (State-Space Representation) to recover the modes the Laplace transform quietly suppressed.], and a block diagram is the pictorial notation engineers use to compose such ratios without losing track of which signal feeds which. Neither object is a theory of dynamics; both are bookkeeping devices for linear, time-invariant, single-input single-output systems, and they work precisely to the extent that those adjectives hold[fn:: The pedagogical temptation is to treat block diagrams as if they were the system. They are not. They are a visual crutch for the algebra of rational functions in s, and like every crutch they fail exactly when the leg they support is asked to bear real weight - nonlinearity, multiplicity of inputs, or topology dense enough that the eye can no longer parse it.].

The transfer function as a Laplace-domain object

Given an LTI system described by an =n=-th order linear ODE with constant coefficients,

\begin{equation} a_n \frac{d^n y}{dt^n} + \dots + a_0 y = b_m \frac{d^m u}{dt^m} + \dots + b_0 u, \end{equation}

the Laplace transform (see Control Theory: Signals & Laplace) converts differentiation into multiplication by s, integration into division by s, and - crucially - dissolves the initial conditions into additive terms that we then *declare out of scope*[fn:: This declaration is not innocent. It is the reason transfer functions are the wrong tool for systems whose initial state matters: switched networks, reset integrators, anything with a discontinuity at =t=0=. The state-space form keeps the initial state as a first-class citizen; the transfer function throws it away and then pretends it never existed.]. What remains is the transfer function

\begin{equation} G(s) = \frac{Y(s)}{U(s)} = \frac{b_m s^m + \dots + b_0}{a_n s^n + \dots + a_0}, \end{equation}

a rational function whose poles (roots of the denominator) dictate the natural modes and whose zeros (roots of the numerator) dictate the forced response's frequency-shaping. Stability reduces to a question about the left-half-plane location of poles - a question answered by Routh-Hurwitz (Stability: Routh-Hurwitz) without ever solving the characteristic polynomial, and refined by the root locus (Root Locus: Evans Construction) as a parameter varies.

The transfer function is therefore a compact summary of the impulse response via the convolution theorem[fn:: =y(t) = g(t) * u(t) = \int_0^t g(\tau) u(t-\tau) d\tau=, and =Y(s) = G(s) U(s)=. The frequency domain trades an integral for a multiplication; this is the entire reason it exists.], and every block-diagram operation that follows is an algebraic manipulation of these G(s) objects.

Open-loop vs closed-loop

A plant G(s) driven directly by a command R(s) is open-loop: =Y(s) = G(s) R(s)=. It is honest, fragile, and almost never what one builds, because the output is at the mercy of every unmodelled disturbance and every parameter drift. Closing the loop introduces a sensor H(s), a comparator, and the canonical feedback equation

\begin{equation} \label{eq:closedloop} T(s) = \frac{G(s)}{1 + G(s) H(s)}, \end{equation}

where the 1 in the denominator is doing all the work[fn:: The sign convention matters: equation \ref{eq:closedloop} assumes negative feedback. Positive feedback replaces the + with a -, and with it the entire stability intuition inverts. Most textbook diagrams draw the summer with a minus sign next to the feedback line and never explain that this single symbol is what separates a servo from an oscillator.]. The open-loop transfer function G(s) H(s) is the loop gain, the object around which the root locus, Nyquist, and Bode analyses are organised; the closed-loop transfer function T(s) is what the reference command actually sees. The two are related by the Möbius-like map x \mapsto x/(1+x), which is nonlinear in x even though every block underneath is linear - a small observation with large consequences for loop shaping.

The product G(s) H(s) is also the thing whose encirclements of −1 Nyquist counts, and whose gain/phase margins the PID tuner (PID Control: Theory & Tuning) is, in the end, trying to push into a comfortable region of.

Block-diagram algebra: three rules, no more

Every block-diagram reduction is one of three moves, and the claim that one can "reduce" an arbitrary diagram is really the claim that these three moves suffice to flatten the topology:

Series (cascade)

Two blocks G_1, G_2 in series multiply:

\begin{equation} G_{\text{series}}(s) = G_1(s) G_2(s). \end{equation}

This is the convolution theorem in disguise, and it is non-commutative in the time domain but commutative in the s domain for LTI blocks[fn:: The commutativity is an LTI privilege: cascade two nonlinearities, or even two LTI blocks separated by a sampler, and the order suddenly matters. The =s=-domain commutativity is one of the quiet luxuries the continuous-time Laplace framework buys you, and the discrete/z-transform version inherits it only when the blocks are shift-invariant.].

Parallel

Two blocks fed the same input and summed at the output add:

\begin{equation} G_{\text{parallel}}(s) = G_1(s) + G_2(s). \end{equation}

Feedback

A forward block G wrapped by a feedback block H collapses to equation \ref{eq:closedloop}. This is the only non-trivial rule, and it is the one that introduces the 1 + GH denominator whose roots everyone spends the rest of the course chasing.

These three rules are sufficient because any diagram can be driven to a single block by repeated application of them provided the diagram is well-formed - no algebraic loops that the rules cannot resolve, no multi-input summers that hide an implicit constraint[fn:: "Well-formed" is doing a lot of work here. Real schematics bristle with take-off points, summing junctions with mixed signs, and blocks whose inputs are drawn from the middle of another block's output wire. Each of these is a notational convenience that, under reduction, resolves to one of the three canonical forms - but only after the reader has manually unwound the drawing conventions. The diagram does not reduce itself.].

Signal-flow graphs

A signal-flow graph is the stripped-down, topological skeleton of a block diagram: nodes are signals, directed edges are gains, and the boxy paraphernalia of summing junctions and take-off points vanish into the node-edge structure. The graph

\[ x_j = \sum_{i \to j} a_{ij} x_i \]

is a system of linear algebraic equations in the s domain, and Mason's gain rule is the closed-form solution of that system expressed purely in terms of graph topology. It is, in other words, block-diagram reduction promoted from a craft to a formula[fn:: The promotion is not free: Mason's rule requires you to enumerate every forward path and every loop, and to determine which loops touch which paths. For a graph of moderate size this is a combinatorial bookkeeping task - the same task the three-rules-plus-patience approach demands, but now with the discipline of a checklist instead of the intuition of a sketch.].

Mason's gain rule

For a signal-flow graph with input node R and output node C, the overall gain is

\begin{equation} \label{eq:mason} T = \frac{1}{\Delta} \sum_{k} P_k \, \Delta_k, \end{equation}

where:

The phrase "non-touching" means sharing no node; two loops that pass through the same node touch, and so do not contribute to the L^{(2)} term[fn:: Touching is a purely graph-theoretic notion - it cares about shared nodes, not shared edges. Engineers regularly miscount by conflating "touching" with "connected by an edge"; the definition is sharper than the intuition.].

A worked example

Consider a graph with nodes R, x_1, x_2, x_3, C and edges

FromToGain
Rx_11
x_1x_2G_1
x_2x_3G_2
x_3C1
x_1x_3G_3
x_2x_1H_1
x_3x_2H_2

The two extra edges x_1 \to x_3 and the two feedback edges x_2 \to x_1, x_3 \to x_2 give us one bypass path and two loops.

Forward paths. There are two paths from R to C:

P_1
R \to x_1 \to x_2 \to x_3 \to C, gain =P_1 = 1 \cdot G_1 \cdot G_2 \cdot 1 = G_1 G_2=.
P_2
R \to x_1 \to x_3 \to C, gain =P_2 = 1 \cdot G_3 \cdot 1 = G_3=.

Loops. Two individual loops:

L_1
x_1 \to x_2 \to x_1, gain =L_1 = G_1 H_1=.
L_2
x_2 \to x_3 \to x_2, gain =L_2 = G_2 H_2=.

Non-touching loop pairs. L_1 touches nodes \{x_1, x_2\}; L_2 touches nodes \{x_2, x_3\}; they share x_2, so they touch. Hence =\sum L^{(2)} = 0=, and there are no higher-order terms.

Graph determinant.

\begin{equation} \Delta = 1 - (L_1 + L_2) = 1 - G_1 H_1 - G_2 H_2. \end{equation}

Cofactors.

\Delta_1
path P_1 passes through \{R, x_1, x_2, x_3, C\}, i.e. every node, so neither loop is non-touching with it. =\Delta_1 = 1=.
\Delta_2
path P_2 passes through \{R, x_1, x_3, C\}. L_1 touches x_1 (shared with P_2), L_2 touches x_3 (shared with P_2). Both loops touch P_2, so =\Delta_2 = 1=.

Result. Applying equation \ref{eq:mason}:

\begin{equation} T(s) = \frac{P_1 \Delta_1 + P_2 \Delta_2}{\Delta} = \frac{G_1 G_2 + G_3}{1 - G_1 H_1 - G_2 H_2}. \end{equation}

The numerator is the sum of the two forward-path gains (each weighted by a unit cofactor); the denominator is 1 minus the two loop gains (the loops touch, so no second-order term appears). This is exactly what block-diagram reduction would produce, but arrived at by counting instead of *redrawing*[fn:: The 12000.org canonical example[fn:: See =https://12000.org/my_notes/mason_rule/mason.htm= for the reference treatment.] makes the same point at length: the diagram-reduction route and the Mason route converge, but Mason's route is auditable - you can re-derive the answer from the path/loop list without re-drawing the diagram, and the list is a checklist instead of a sketch.]. When the topology grows, this auditability is the only thing that survives.

Why block diagrams are a notation, not a theory

The temptation, especially in a first control course, is to treat the block diagram as if it were the system - as if drawing a box labelled G(s) somehow constituted a model. It does not. The diagram is a visual rendering of a set of algebraic relations among rational functions in s, and its claim to existence is ergonomic, not ontological: human engineers parse pictures faster than they parse systems of equations, and the three reduction rules are simple enough to apply by eye[fn:: This is also why block diagrams survive in textbooks long after they have ceased to be computationally relevant: software like MATLAB reduces a system to state space, computes its response, and never draws a single box. The diagram is for the human, not the machine - a fact that becomes salient the first time one tries to explain a feedback topology to a colleague without reaching for a pen.]. The theory lives in the Laplace domain (Control Theory: Signals & Laplace); the diagram is a way of keeping one's place while doing the algebra.

This ergonomic framing is also what predicts the diagram's failure modes: a notation optimised for human visual parsing will fail exactly when the human eye fails.

When it breaks

In each case the diagnosis is the same: the diagram is a rendering of a set of algebraic relations, and when those relations cease to hold the diagram ceases to mean what it depicts. The fix is uniformly to retreat to a representation - state space, describing functions, Lyapunov - that does not lean on the linearity, time-invariance, and SISO assumptions that gave the diagram its leverage in the first place.

Related