learn · South Africa
Function Block Diagram: Typed Signals, State and FBD Tests
Learn function block diagram with typed signal graphs, reset-priority memory, instance tests and practical questions for South African PLC course learners.

Function block diagram, usually shortened to FBD, expresses PLC logic through connected operations and block calls. The connections carry values with defined types and meanings. Understanding an FBD program requires more than following lines: you also need to know which blocks have memory, when they execute and how invalid inputs are handled.
This tutorial develops a typed arithmetic graph, a reset-priority memory example and a two-instance isolation test. The examples are independent software learning models. They are not native project files, validated machine controls or a claim that every editor uses identical block names and execution rules.
For South African PLC learners, the practical outcome is an annotated graph and an evidence record. You should be able to explain the value on each connection, predict the next state and show why a changed input produces the observed result.
Place FBD within the current programming-language standard
The IEC 61131-3:2025 publication summary lists structured text as a textual language and ladder diagram and function block diagram as graphical languages. It separately describes sequential function chart elements for organising programs and function blocks. Older training material may use a different language list.
The standard's scope does not establish which features a particular controller, software edition or library implements. Record the target platform and supported language features when selecting a course or translating an example.
FBD is useful when showing relationships between calculations and decisions makes the logic easier to review. Ladder can be useful for familiar Boolean control patterns, while structured text can express algorithms compactly. The structured-text tutorial provides a complementary way to write and test the same logical relationships.
Choose the representation around the task and the people maintaining it. An arbitrary count of contacts or blocks does not determine readability, migration effort or runtime performance. Compare a small representative example with the intended reviewers before adopting a project-wide rule.
Read a connection as a typed value with a meaning
For every important connection, identify the source, destination, data type and units. A Boolean comparison result answers a question; a real-valued measurement represents a quantity. A line between them does not make those meanings interchangeable.
| Operation in the learning graph | Inputs | Output meaning |
|---|---|---|
| AND | Boolean conditions | True only when all required conditions are true |
| OR | Boolean conditions | True when at least one selected condition is true |
| NOT | Boolean condition | Opposite Boolean value |
| Multiply | Numeric values | Product with the intended units |
| Add | Compatible numeric quantities | Combined numeric value |
| Greater-or-equal comparison | Comparable numeric values | Boolean result of the comparison |
A native editor may provide overloaded operations, conversions and platform-specific instructions. Inspect the actual pin definitions and conversion behaviour. Do not assume that every type mismatch produces the same compiler error, or that an accepted connection necessarily has the intended engineering meaning.
When one output feeds several consumers, review each consumer's interpretation. If several sources must produce one result, use an explicit combination or selection rule. Naming that rule is clearer than leaving competing assignments to imply an undocumented priority.

Build a numeric graph before attaching its decision output
Use two fictional normalised measurements, A and B, each in the interval zero to one hundred percent. Define a derived index as one quarter of A plus three quarters of B. The weights are chosen for this arithmetic exercise and are not a process-control recommendation.
The conceptual graph has two multiplication operations followed by an addition. The numeric result can feed a display and a comparison independently. The comparison asks whether the index is at least sixty percent and produces a Boolean HighIndex indication.
A -- multiply by 0.25 --\
add -- IndexPercent -- compare >= 60 -- HighIndex
B -- multiply by 0.75 --/
This is an explanatory connection sketch, not an importable FBD diagram. The numeric IndexPercent continues to exist after the comparison is added. Do not route the Boolean HighIndex output into an input that expects the numeric index.
For A equal to forty and B equal to eighty, the two weighted contributions are ten and sixty. Their sum is seventy, so HighIndex is true. Reversing the measurements gives twenty plus thirty, or fifty, making HighIndex false.
The scaling and resolution lesson supports checking the meaning of numeric values before they enter a graph. If one source is raw counts and the other is percent, this equation no longer has the stated inputs.
Define the validity contract around the graph
The independent model accepts A and B only when both supplied quality flags are good and both numeric values are finite and inside zero through one hundred, inclusive. Boolean values are not accepted as numeric measurements in this model.
Check that contract before calculating the weighted index. On success, return IndexValid true, the calculated index and the corresponding HighIndex result. On failure, return IndexValid false, DataFault true, no current numeric index and HighIndex false.
An absent HighIndex during DataFault is not proof that the underlying process is below a threshold. It means the learning model has no usable current result. A native implementation using a numeric placeholder must keep the validity indication with that placeholder.
| A | B | Both quality flags good? | Index percent | HighIndex |
|---|---|---|---|---|
| 40 | 80 | Yes | 70 | True |
| 80 | 40 | Yes | 50 | False |
| 0 | 0 | Yes | 0 | False |
| 100 | 100 | Yes | 100 | True |
| 60 | 60 | Yes | 60 | True |
| 80 | 80 | No | Unavailable | False |
Also test an out-of-range value and a non-finite value. A successful calculation at normal inputs does not verify the invalid-data path. The analogue signal types guide explains why an electrical representation and its quality need separate interpretation.

Distinguish pure calculations from stateful block instances
In the arithmetic example, each valid output is determined by the current supplied inputs. No previous index is needed. A stateful block can behave differently because its output also depends on stored values from earlier calls.
The CODESYS function-block object documentation describes calls through instances and the persistence of output and internal values between executions. It also distinguishes the variables belonging to each instance. That provides a concrete example of why a timer or latch needs an identifiable state owner.
State retained between calls is not automatically state retained through power loss, reset or download. Those lifecycle behaviours depend on the implementation and configuration. A learning test should declare its initial state rather than relying on an unstated default.
A useful interface record names each input, output, stored state, initial condition and reset rule. It should also explain what happens when the block is not called. This record is valuable whether the block is displayed in FBD or invoked from another supported language.
Specify reset priority before drawing a memory loop
Use a fictional Boolean memory element with Set, Reset and stored Q. Initialise Q false. On each executed evaluation, first read OldQ, then calculate NewQ as NOT Reset AND the result of Set OR OldQ. Store NewQ as the next Q.
Reset therefore wins when Set and Reset are both true. This is a learning memory rule, not a physical motor-start circuit or a protective function. The CODESYS RS reference provides a documented reset-dominant block example; verify the chosen library's pins when implementing it natively.
| OldQ | Set | Reset | NewQ |
|---|---|---|---|
| False | False | False | False |
| False | True | False | True |
| False | False | True | False |
| False | True | True | False |
| True | False | False | True |
| True | True | False | True |
| True | False | True | False |
| True | True | True | False |
The table covers every Boolean combination of the three inputs to the next-state calculation. Holding Set true after Reset becomes false sets Q again under this rule. If a different restart policy is needed, it must be designed and tested separately.
The start-stop learning exercise explores related memory and request behaviour. Similar-looking graphical patterns should still be compared against their complete truth tables and initial conditions.

Trace the state before and after an executed call
Make the observation order explicit. In the following four-call example, the first state column is read before the memory element executes. The final column is read after the next-state value has been stored.
| Call | Set | Reset | Q before call | Q after call |
|---|---|---|---|---|
| 1 | True | False | False | True |
| 2 | False | False | True | True |
| 3 | False | True | True | False |
| 4 | False | False | False | False |
A monitor or consumer evaluated before the call sees the earlier state in this specified order. A consumer evaluated afterwards sees the updated state. The difference is not evidence that every FBD connection introduces a scan delay.
When implementing the example in a native editor, inspect its execution rules and the location of the consuming logic. Do not infer universal ordering from a line's direction or the visual position of two disconnected groups.
The scan-cycle explanation develops observation timing and ordered assignments. Preserve the required order in the test record so a translation between languages can be checked against the same behaviour.
Give independent devices independent memory
Create MemoryA and MemoryB, each with its own Q initialised false. In each row below, execute both instances once with their own Set and Reset inputs. The output columns show the stored values after both calls.
| Row | A Set | A Reset | B Set | B Reset | A Q | B Q |
|---|---|---|---|---|---|---|
| 1 | 0 | 0 | 0 | 0 | 0 | 0 |
| 2 | 1 | 0 | 0 | 0 | 1 | 0 |
| 3 | 0 | 0 | 1 | 0 | 1 | 1 |
| 4 | 0 | 1 | 0 | 0 | 0 | 1 |
| 5 | 1 | 1 | 0 | 1 | 0 | 0 |
| 6 | 1 | 0 | 0 | 0 | 1 | 0 |
The fourth row resets A while B remains set. The fifth verifies simultaneous Set and Reset on A and an independent Reset on B. These cases expose accidental sharing more clearly than setting and resetting both instances together every time.
For a counterexample, call one shared instance with A's Set true and Reset false, then call that same instance with B's Set false and Reset true. The first call produces true, but the second leaves the shared Q false. You have executed one memory object twice, not created two independent memories.
If an earlier output was copied elsewhere before the second call, that copy can differ from the instance's current stored output. Record both the state owner and observation point instead of diagnosing the disagreement from the diagram alone.

Do not confuse skipping a call with executing a reset
Use the same learning memory rule. First execute Set true and Reset false so Q becomes true. Next, imagine the caller skips the block entirely while the supplied Reset input is true. In this explicit skipped-call model, no next-state calculation occurs and the stored Q remains true.
On a later executed call with Reset true, Q becomes false. The difference is caused by whether the reset logic ran, not by the visual presence of a Reset signal in the surrounding drawing.
This example shows why disabling an operation is not a general substitute for commanding its defined off or reset behaviour. The appropriate output policy depends on the application. Retaining the previous value can be acceptable in one learning task and incorrect in another.
For timer work, use separate instances and document whether each is called every evaluation. The timer integration reference covers the distinction between a skipped call and an executed false input without assuming identical native behaviour on every platform.
Treat EN and ENO as execution information with defined limits
The Siemens STEP 7 V20 EN/ENO overview for FBD describes conditional instruction execution and error reporting. It also explains that configuration and explicit handling within called program blocks affect what ENO reports.
That mechanism should not be turned into a claim that every invalid measurement automatically produces a false ENO, or that every block exposes the same pins. Read the selected instruction and library documentation, including any dedicated status or error outputs.
Keep execution success, measurement validity and application permission separate in the learning design. An arithmetic operation can execute successfully on a value whose engineering interpretation is wrong. A disabled operation can leave a previous result visible without producing a new valid measurement.
In the weighted-index model, IndexValid is assigned by the declared input checks. It is not inferred from an assumed generic ENO chain. DataFault remains visible when the model cannot produce a usable current index, even though HighIndex is false.
Build reusable blocks around a clear contract
A reusable block needs a purpose that can be stated independently of its internal drawing. For the index example, the purpose is to validate two normalised inputs and return a weighted index with validity. For the memory example, it is to apply a reset-priority next-state rule to an owned Boolean state.
Choose the interface around those responsibilities. Name units, accepted ranges, reset conditions and lifecycle assumptions. Reuse should make these rules easier to review rather than hide them behind an unexplained box.
Test a reusable block independently, then test its callers. An isolated truth table cannot detect a caller connected to the wrong instance or a consumer reading before an update. Integration evidence needs the real call pattern and observations as well.
Avoid deciding reuse from an arbitrary number of pins or occurrences. A small block can clarify a meaningful contract, while a large block can conceal several unrelated responsibilities. Review whether another learner can predict the outputs from the interface and test record.

Practise translation without promising identical editors
Draw the weighted-index graph, write its equation and compare the expected outputs. Then express the Boolean memory rule in a supported textual or graphical environment. Preserve types, initial state, reset priority and call order during the translation.
The structured-text learning material provides a relevant companion for expressing the calculations textually. Check the supported syntax and exercise scope instead of assuming that native function-block declarations run unchanged.
The PLC program testing material can help organise expected and observed results. These links support related software learning; the graph sketches here are not instructions for an asserted native-compatible FBD editor in that product.
Keep the six arithmetic fixtures, eight memory combinations, four-call observation trace and six-row instance test together. Add invalid data and the skipped-call counterexample. The calculations and state examples were independently checked as learning models; native compilation and hardware execution require their own evidence.
Compare South African FBD training by its practical content
For PLC courses in Johannesburg, Pretoria, Durban, Cape Town or another South African location, ask which controller family, software version and FBD libraries learners use. Request an exercise involving typed connections and two independent stateful instances.
Ask how the instructor assesses invalid inputs, simultaneous Set and Reset, execution order and recovery after a disabled call. A demonstration where every input is normal provides less evidence than an individual assessment with predicted and observed results.
The South African PLC training guide supports comparing course scope, access and assessment. These location references describe course-search contexts, not local branches operated by this website. Confirm the actual delivery arrangements and certificate meaning with the provider.
Is every box in an FBD diagram a stateful function block?
Inspect the operation and its declaration. A pure arithmetic calculation needs only current inputs, while the memory example needs OldQ. The visual shape alone does not establish stored state or lifecycle behaviour.
Does a feedback line always mean a one-scan delay?
Do not assume that across editors. The example explicitly reads OldQ before storing NewQ. A native implementation must be checked against its execution and feedback rules, including where consumers read the result.
Is a false ENO proof that the output is safe?
No. It is execution or error information within the selected mechanism. Review the actual output policy and the application's requirements. A retained previous result is not automatically an acceptable response.
What should an FBD portfolio demonstrate?
Show typed connections, a valid arithmetic graph, invalid-data handling, reset priority and independent instance memory. Include the expected tables and actual observations, with the implementation platform and remaining limitations clearly identified.