TIA Portal FBs vs AOIs: Instance Data and Worked Tests

In TIA Portal, a function block with instance data is the closest starting point when translating the idea of an Allen-Bradley Add-On Instruction. Both let you reuse behaviour while keeping data for an individual use of that behaviour. They are not interchangeable files, and a familiar interface name does not prove identical execution, parameter or restart rules.

This guide is for South African learners, technicians and instructors moving between the two environments. It uses Siemens V20 documentation and Rockwell's September 2025 Add-On Instruction manual, checked on 12 September 2026. The worked exercise is a fictional, platform-independent model of a value that approaches a target by a limited amount per call. It is not a compiled TIA Portal project or a motion-control implementation.

We operate PLC Simulation Software and may benefit from its use. Product links support general learning and testing. They do not imply that the browser product imports AOIs, opens TIA projects or reproduces either manufacturer's complete engineering environment.

Translate the design responsibility before translating names

An AOI definition describes reusable instruction behaviour. Each use needs appropriate instance data. Siemens separates the function-block code from its associated instance data block. The important question is which state belongs to each independent device or operation, then how the selected platform represents that state.

Siemens' S7-1200 function-block documentation explains that an instance DB holds parameters and static data after the call finishes. Different instance DBs let one FB serve independent devices. Values are available on later calls in the same scan or subsequent scans. Persistence between calls should not be confused with survival through every power, reset or download event.

Rockwell's Add-On Instruction manual describes instruction-defined instance tags containing the instruction's data. It also distinguishes externally accessible parameters from local tags, which are not generally accessed programmatically through that instance tag; alias parameters provide a supported route in applicable cases. Do not assume that a Siemens static member and a Rockwell local tag have identical visibility simply because both hold internal state.

A translation plan should therefore list behaviour, data ownership, parameter direction, call conditions and initialisation. Renaming an AOI to an FB addresses only one item. A useful review asks whether the same input history produces the same required output history, including invalid inputs and restarts, within the limits of the target system.

02

FBs, FCs and organisation blocks have different jobs

Use the function versus function-block guide to separate a calculation from an operation that needs memory across calls. A pure conversion can calculate a result from current inputs without carrying a private history. A running sequence, accumulated quantity or previous-value comparison needs somewhere explicit to store history.

An FC does not provide its own instance DB in the way an FB does. That does not mean an FC is incapable of changing external data or affecting application state. Calling it simply “stateless” can hide writes through parameters or other accessible variables. Review actual data access as well as the block type when deciding whether a calculation is independent.

An organisation block defines an entry point associated with a runtime event. Do not treat every OB as ordinary cyclic logic or transfer an OB number from an older Siemens family without checking the target. For a training project, document which configured event invokes the containing program and how often the reusable block can execute within it.

This distinction prevents a common timing mistake: assuming that one source-code call means one execution per scan. The caller might contain a loop, execute under more than one event or call the same instance again later. The block's behaviour depends on actual calls and state, not the visual distance between two boxes in a diagram.

Single instances and multi-instances preserve separate state differently

A single instance gives an FB use a dedicated instance DB. That arrangement is easy to inspect in a first project because the association is visible as a named data block. Name it for its role, such as a training channel, rather than depending on an automatically assigned number as if that number were a universal convention.

Siemens' V20 multi-instance documentation describes storing a called FB's instance data within another FB's instance DB, using the Static declaration area. This can reduce separate DBs and organise related suboperations. The documentation also describes call options and directly declared instances. Check availability and details against your target rather than assuming every historical TIA version offers the same forms.

For two independent channels inside a parent FB, declare two distinct child instances. They may occupy the same parent DB while remaining separate state objects. “They share a DB” is therefore not enough information to diagnose a fault. Sharing a containing data block differs from calling the same child instance for two unrelated operations.

Draw the ownership tree before coding: parent instance, first child instance and second child instance. Each child's history must have a unique path. If you create another parent instance, its children should belong to that new parent. This exercise makes the relationship clearer than counting how many DB files appear in the project tree.

Define an interface that exposes meaning, not accidental storage

For the fictional exercise, choose inputs named Target, Step and Reset. Keep a persistent integer Current. Return the resulting value and a status that distinguishes reset, movement, arrival and invalid input. The names are a specification, not a claim that a particular vendor library already supplies this exact block.

The block owns Current: callers request a target but do not overwrite the state halfway through an update. If another design deliberately passes shared state through an in/out parameter, record that ownership arrangement instead. Two independent instances can still interfere if both are given the same external writable object.

Siemens' parameter transfer documentation makes clear that copy-versus-pointer behaviour depends on parameter and data type. Different optimisation settings can also change the transfer of structured in/out data. Avoid the blanket shortcut that all in/out parameters on both platforms behave identically in every context.

Choose outputs for diagnostics that a caller needs to make a decision. Do not expose internal state solely because it is easy to reach. A stable interface lets you revise an implementation without making every HMI screen or neighbouring block depend on an internal variable whose meaning might change.

03

Worked specification: approach a target by a bounded step

The model uses whole-number values from zero through 100. Current starts at zero. Valid Target values are integers in the same range. Valid Step values are integers from one through 20. Reset is Boolean. These limits are chosen for arithmetic practice, not taken from a Siemens or Rockwell product specification.

Apply rules in this order. First validate the input types. If Reset is not Boolean, report invalid and preserve the state. If Reset is true, set Current to zero and report reset; target and step values are not used on that reset call. Otherwise validate Target and Step. An invalid value preserves the existing current value and returns invalid.

On a valid non-reset call, compare target and current. If target is above current, add the smaller of Step and the remaining difference. If target is below current, subtract the smaller of Step and that difference. If they are equal, leave the value unchanged. Report arrived when the resulting current equals target; otherwise report moving.

This rule prevents overshooting the target. From 20 toward 25 with step 10, the result is 25, not 30. From 25 toward 5 with step 10, the results across two calls are 15 and 5. A signed difference is convenient conceptually, but native data types must be chosen so the intermediate calculation is represented correctly.

Starting current	Target	Step	Reset	Result	Status
0	25	10	false	10	Moving
10	25	10	false	20	Moving
20	25	10	false	25	Arrived
25	5	10	false	15	Moving
15	5	10	false	5	Arrived
5	5	10	false	5	Arrived
5	101	10	false	5	Invalid
5	101	0	true	0	Reset

The final row is intentional: valid reset has priority over unused target and step fields. A different requirement might validate everything first. Neither order should be left to chance; tests must reflect the chosen contract.

Prove that two independent instances remain independent

Create fictional instances A and B, both starting at zero. A receives target 25 and step 10. B receives target 8 and step 3. Call A once and B once during each of three rounds. A's sequence is 10, 20, 25. B's sequence is 3, 6, 8. The state of one does not become the starting value of the other.

Now deliberately use a single shared state, calling A's inputs first and B's inputs second. The first round changes zero to 10 for A, then 10 to 8 for B. The next round changes 8 to 18 and then 18 to 15. The third changes 15 to 25 and then 25 to 22. Neither result history matches the independent-channel requirement.

This is a reproducible state-ownership defect, not evidence that the compiler must reject the call. Reusing an instance can be intentional when calls are meant to operate on the same state in a defined order. It becomes wrong here because the requirement explicitly demands independent histories for A and B.

Reverse the order in the shared-state experiment and the results change again. That sensitivity helps locate the fault: examine instance selection and any shared external writable data before changing the arithmetic. With independent instances and independent inputs, swapping A's and B's call order should not change either channel's result sequence in this model.

04

Multiple calls change progress even when the instance is correct

From zero with target 25 and step 10, one call produces 10. Two consecutive calls on the same instance produce 20. Three produce 25. The model limits movement per call, not per second, and it does not infer elapsed time from the PLC's nominal scan setting.

This distinction is especially important when a learner calls the block in a loop to process other data. The program can advance the same state several times during one outer cycle. If the intended requirement was one update per allocation opportunity, the loop has changed the behaviour even though every arithmetic operation remains valid.

Do not describe this classroom block as a speed controller, acceleration limiter or physical motion profile. Such a design needs units, timing, equipment constraints and a much broader specification. Here the learning objective is to expose the relationship between execution frequency and state change without pretending that a few arithmetic lines validate a real axis.

For an extension, specify an explicit elapsed-time input and derive a separate model before coding it. Decide how to handle zero time, long gaps, fractional changes and accumulated rounding. The new requirement should be reviewed as a new exercise; it is not automatically solved by replacing Step with a value copied from a screen.

Temporary storage and retentive state are different questions

Put per-call scratch calculations in temporary storage when appropriate, but do not use temporary data as the sole home of Current. The required history must be preserved between calls. In a native FB implementation, examine the selected instance and declaration area to verify that the persistent state belongs to the intended channel.

Do not rely on the blanket claim that every Temp variable always begins as zero or always begins undefined. Siemens' V20 parameter-assignment guidance distinguishes standard and optimised access and documents their temporary-data rules. Write each scratch value before reading it where your algorithm requires a value, and check the relevant target documentation.

Retention across a power interruption is a separate test. The classroom initial state of zero says nothing about native retain attributes, memory reset, download changes or restoring a saved value. Record the exact lifecycle event before judging whether a retained value is correct. “It remembered the value yesterday” is not a complete restart requirement.

For assessment, keep two test headings: normal calls and lifecycle events. Normal calls establish the arithmetic and independence properties. Lifecycle tests establish the chosen starting state after a specified event in the actual environment. A successful normal sequence does not prove the second category, and a successful restart does not prove that two channels have separate instances.

05

Build a migration test sheet before copying the implementation

List each source parameter with its meaning, unit, range and ownership. Record whether it is input-only, produced by the block or shared with the caller. Identify every hidden dependency: external tag reads, external writes, call conditions and any special execution routines. Compare those dependencies with the target design rather than translating the visible parameter list alone.

For this exercise, the independent-instance sequence is the first acceptance test. Add rising and falling targets, exact arrival, invalid ranges, fractional input rejection, reset priority and repeated calls. Test target zero and 100, step one and 20, and a remaining difference smaller than the selected step.

An effective defect test changes one condition in the implementation and predicts which result should fail. Remove the final clamp and the 20-to-25 row overshoots. Reinitialise persistent state on every call and A never progresses beyond 10. Reuse the same instance for A and B and their histories interfere. Accept step zero and an unequal target can remain unchanged without being diagnosed invalid.

Keep the actual results alongside expected results. When working in TIA Portal or Studio 5000, identify the project revision, target and test environment. The local worked arithmetic on this page establishes a specification to compare against; it is not evidence that either native project has been compiled, simulated or accepted for production.

Use training time to inspect state, not memorise clicks

A useful practical course lets you open the chosen instance, observe state before and after calls and explain the first divergence from an expected sequence. Ask the instructor to demonstrate the difference between changing an FB definition and changing data for one instance. Also ask how interface edits affect existing instances in the selected software version.

For a first Siemens project, read TIA Portal basics. For an existing older project, use the STEP 7 migration guide before assuming that changing the reusable-block design is the only migration work. Hardware, instructions and external consumers may impose additional constraints.

PLC Structured Text practice can support the comparisons and conditional arithmetic used here. PLC program testing practice supports writing expected results and diagnosing a failed sequence. Keep native engineering training in the learning plan when the job requires native project work.

Training departments can use the brief to compare course assessments across platforms without claiming that certificates are equivalent. Our training-centre evaluation guide focuses on matching practice resources to teaching outcomes. For brand-specific routes and related topics, return to the Siemens PLC learning hub.

06

Questions about AOIs and Siemens FB instances

What is the Siemens equivalent of an Allen-Bradley AOI?

An FB with associated instance data is a useful conceptual counterpart for reusable stateful behaviour. It is not a file-format conversion or a guarantee of identical parameter, execution and lifecycle rules. Compare the required behaviour and data ownership before translating the implementation.

Does every FB call need a separate standalone DB?

No. A multi-instance can hold the child's state within another instance DB. Independent operations still need independent state objects. Count the actual instances and ownership paths, not only the standalone DBs in the project tree.

Is calling the same instance twice always wrong?

No. It means both calls operate on the same state. That can be intentional when the required behaviour defines the order. It fails the two-channel exercise because the channels are specified as independent. Repeated calls also advance this particular model more than once.

Why does my second device change the first device's result?

Check whether the calls use the same instance or share an external writable object. Compare values before and after each call, then reverse call order in an isolated test. The worked shared-state sequence shows why a superficially correct calculation can still produce the wrong device histories.

Does Static mean retained through every restart?

No. Persistence between calls and retention through specific lifecycle events are separate properties. Check the target's configuration and documentation, define the event and test the required initial state. Do not use a normal cyclic test as proof of power-recovery behaviour.

Can a browser exercise replace TIA Portal practice?

It can prepare your reasoning about interfaces, conditions and tests. It does not establish native compilation, project compatibility, downloads or hardware diagnostics. Use the exercise as an assessment specification, then verify a native implementation in the appropriate training environment.