brands · South Africa
TIA Portal Basics: Projects, Tags and First Program Tests
Learn TIA Portal basics: project views, devices, tags, blocks, compilation and watch tables, with a worked classification exercise and boundary tests.

TIA Portal basics are easier to learn when you separate the project, the configured device, the program and the values observed during execution. A project can save successfully while containing a logic mistake. A program can compile while using the wrong signal. A simulated output can be correct without proving that a physical terminal is connected as intended.
This beginner guide follows that separation through a small fictional sorting-decision exercise. It covers project orientation, tags, blocks, compilation and a repeatable test table. Siemens V20 documentation was checked on 12 September 2026; use the help supplied with your installed version and selected CPU for exact availability. This is a guided specification, not a claim that a native TIA project has been compiled on this website.
We operate PLC Simulation Software and may benefit from readers choosing it. Its linked learning pages provide supplementary programming practice. They are not TIA Portal, S7-PLCSIM or a licence to Siemens software, and do not establish native project compatibility.
Decide what your first project should demonstrate
A useful first project should have a small requirement that you can explain before opening the editor. For this guide, classify a fictional item's measured width as narrow, standard or wide. If the measurement is unavailable or outside the exercise's domain, produce an invalid status instead of quietly calling it narrow.
The exercise deliberately avoids motor control, physical output testing and live machinery. It lets you practise data flow and boundaries without making a simple program appear to be a commissioned sorting system. The result is a decision displayed in a training project; connecting it to an actuator would require a separate engineering design and supervised validation.
Before selecting software, establish the CPU family and complete device designation required by your course. Do not choose a controller merely because its picture resembles the one in a tutorial. Firmware support, installed engineering options and simulation compatibility can differ. Our S7-1200 and S7-1500 comparison helps structure that enquiry.
Keep a project note containing the software release, target, exercise revision and expected result table. For a South African class using shared computers, include where you may save files and whether you can reopen them after the course. A project stored only in a temporary teaching account is a weak foundation for continuing practice.

Find the project, device and network views
Siemens' documented project-creation procedure starts from creating a named project and then moving into project view. Its illustrated target is a Drive Controller, so use the equivalent supported device selection for your own course rather than copying that hardware choice into an unrelated exercise.
Think of the project tree as the place to locate the objects belonging to the project. The device configuration describes the selected hardware arrangement. The network view helps represent configured network relationships. A program block contains executable logic. These objects are related, but opening one does not mean you have verified the others.
For an initial orientation task, ask the instructor to identify the CPU in the tree, its complete model in the configuration and the block used for the exercise. Then locate the tag declarations and the table that will show test values. Repeat the navigation without editing anything. Being able to find an object is a separate skill from understanding its behaviour.
Avoid universal layout rules such as “all modules go to the left of the CPU.” The supported arrangement depends on the hardware family and component type. Consult the selected device documentation and catalogue constraints. Likewise, do not assume that saving a project proves every hardware relationship and program object has passed a complete compilation.
Use tags to express meaning and check their storage
A name such as MeasuredWidth communicates more than an isolated numeric address, but the name does not make the mapping correct. You must still know the data type, where the value comes from and whether it represents raw data or an engineering value. A readable tag mapped to the wrong source remains wrong.
Siemens' tag guidance distinguishes PLC tags, block-local tags and DB variables. Therefore, do not expect every variable in a project to be declared in a PLC tag table. Choose a declaration location from the value's intended scope and ownership, then use the corresponding symbolic path.
Siemens' addressing reference explicitly documents both symbolic and absolute addressing, including %I16.4, %Q1.0 and %IW4. The claim that TIA Portal universally refuses absolute addresses is incorrect. Prefer descriptive symbols for readability while still inspecting the underlying address where applicable.
For the classroom exercise, keep test inputs in an appropriate training data area instead of assigning arbitrary physical input or output addresses. Decide how the test method supplies values and how the program reads them. Do not copy %Q1.0 from a documentation example and assume that it is an unused terminal on your training equipment.
Write the classification requirement in plain language
The input is a whole-number width in millimetres from zero through 200. MeasurementGood is a Boolean quality indicator. The range is deliberately fictional and does not describe a particular sensor or Siemens analogue module. A native acquisition design would need the actual sensor range, raw representation, scaling and diagnostics.
When the measurement is good and the width is valid, classify widths below 50 as narrow. Classify widths from 50 through 120 inclusive as standard. Classify widths above 120 as wide. Invalid quality, missing input, fractional width or a number outside zero through 200 produces invalid status, with all three category outputs false.
| Input or result | Meaning in this exercise |
|---|---|
| MeasuredWidth | Whole-number millimetres, valid domain 0–200 |
| MeasurementGood | True only when the supplied measurement is accepted as good |
| Narrow | Valid width below 50 |
| Standard | Valid width from 50 to 120 inclusive |
| Wide | Valid width above 120 |
| Invalid | Input cannot be classified under this specification |
This is a combinational decision: the current valid input determines the current category. There is no requirement to remember a previous category when data becomes invalid. If you later add a “last accepted width” display, it must be labelled separately from the current measurement status so the two meanings are not confused.
A Boolean quality flag alone does not establish freshness. The test supplies that flag as an assumption. A real data path may need timestamps, communications status or other checks before it can set the flag. Keep that upstream responsibility explicit rather than claiming that a numeric range test detects every acquisition problem.

Put the decision in a block and make its call visible
For a first classroom project, keep the calculation small enough to inspect in one view. Its essential stages are validation, mutually exclusive classification and assignment of the outputs. Use a language supported by the selected target and course. A ladder representation and an SCL representation must both satisfy the same written requirement.
If you use a reusable calculation block, make its call visible from the program entry used by the exercise. A correctly written block that is never called produces no useful execution result. Include the supplied input values and returned outputs in the test plan so you can distinguish an uncalled block from an incorrect comparison inside it.
The exercise does not require private history across calls. If you choose an FB for teaching purposes, still understand its instance data. For more advanced stateful tasks, the TIA Portal FB and AOI guide explains why independent operations need independent state. Do not add persistent memory simply because a tutorial uses an FB for everything.
Make each output assignment explicit on every classification call. Starting with all categories false and then selecting one valid category is one clear conceptual approach. Other implementations can be correct, but a branch that never clears yesterday's wide flag can leave two categories active after the width changes.
Compile deliberately and read the result
Siemens' compilation guidance distinguishes hardware and software compilation and lists scopes such as changed objects and complete rebuilds. Select the scope appropriate to the work and inspect the messages. Saving an edited file is not the same operation as compiling the relevant project data.
When a compilation error appears, read the object and message before changing code. A type mismatch, unresolved name and unsupported instruction are different problems. Fix the first relevant cause, compile again and check whether dependent errors disappear. Randomly changing several declarations at once makes it harder to understand what resolved the issue.
A clean compile does not prove the threshold values are correct. The compiler may accept a comparison against 121 when the requirement says 120. It also cannot infer that a source named MeasuredWidth was intended to receive millimetres if the programmer supplies another quantity with a compatible type.
Use separate evidence labels in your project notes: saved, compiled, executed in the selected test environment and checked against expected results. Do not combine these into one vague “working” label. This habit is useful when handing an exercise to an instructor or explaining why a project needs more testing before a practical assessment is complete.

Run the boundary table before adding an HMI
The key boundaries are 50 and 120. Test the values immediately below, exactly at and immediately above each boundary. Also test the domain endpoints zero and 200. These cases reveal mistakes that a single middle-of-range value will not show.
| Width | Quality | Expected result | Why it matters |
|---|---|---|---|
| 0 | Good | Narrow | Lower domain endpoint is allowed |
| 49 | Good | Narrow | Immediately below standard |
| 50 | Good | Standard | Lower standard boundary is included |
| 51 | Good | Standard | Immediately inside standard |
| 119 | Good | Standard | Immediately below upper boundary |
| 120 | Good | Standard | Upper standard boundary is included |
| 121 | Good | Wide | Immediately above standard |
| 200 | Good | Wide | Upper domain endpoint is allowed |
| -1 | Good | Invalid | Below the domain |
| 201 | Good | Invalid | Above the domain |
| 50.5 | Good | Invalid | Fractional input is not accepted |
| 80 | Bad | Invalid | Numeric plausibility does not replace quality |
The fractional and missing-input cases belong to the specification's input-validation boundary. A native Int variable cannot itself hold a fractional number or a missing value. If an upstream interface supplies those possibilities, validate them before conversion or carry an explicit validity indication. Do not claim that assigning 50.5 to an integer and observing a converted result tests the same contract.
Across all 201 valid integer widths, there should be 50 narrow values, 71 standard values and 80 wide values. The counts add to 201, and every valid width belongs to exactly one category. This is a useful completeness check for the fictional model, not a statistical claim about items on a real production line.
Use a watch table to follow the whole decision
Siemens' V20 watch-table instructions describe opening the CPU's Watch and force tables folder, adding a watch table and entering names or addresses with suitable display formats. Use that documented route for your installed environment, then follow the course's approved test setup.
Include width, quality and every category output in the same diagnostic view. Watching only Standard can hide an incorrect wide flag that remains true at the same time. Add the invalid status so you can see why a plausible number was rejected. The observation should explain the decision, not merely show one illuminated Boolean.
Keep monitoring separate from modifying values. Monitoring reads the current state; a write changes the test or application state. For this exercise, use only the isolated training data and authorised simulation or trainer procedure. Do not treat force operations as a routine shortcut for making a real process match a desired screenshot.
Apply each test row and record the result after the classification has executed. If the display refresh is slower than the logic, a brief intermediate view may not represent a complete invocation. For this non-timed exercise, use stable input rows and a clear observation point rather than inferring behaviour from a flickering screen.

Diagnose the first incorrect result
If 50 is narrow, inspect whether the narrow comparison includes equality. If 120 is wide, inspect whether the wide comparison includes equality. If both standard and wide are true at 120, look for overlapping conditions or an output that was not cleared. Each failure suggests a specific part of the rule to inspect.
If 201 is wide instead of invalid, the classification may be running before the domain check or bypassing it. If bad-quality 80 is standard, the program may be checking only numeric range. If the output never changes while the inputs do, confirm the block call and its actual supplied variables before rewriting the comparisons.
Now test a transition: width 150 with good quality produces wide; the next row uses width 80 with bad quality and must clear all categories. Then restore good quality at 80 and expect standard only. This three-row sequence detects stale output state that isolated tests with fresh initialisation can miss.
For a deliberate mapping fault, supply another valid test value to the block while watching the original tag. The logic may be perfectly correct for the value it actually receives. Trace the input from declaration to call to calculation and result. The communication troubleshooting guide extends this reasoning when the value crosses a device connection.
Add complexity only after the simple decision is explainable
Once the boundary and transition tests pass, consider a controlled extension: move the upper standard boundary from 120 to 125. Predict the changed cases before editing. Values 121 through 125 move from wide to standard; 120 remains standard and 126 remains wide. The new category counts become 50 narrow, 76 standard and 75 wide.
That extension tests whether the learner understands the requirement or merely recognises the original numbers. Update the specification, test table and implementation together. A document that still says 120 while the program uses 125 is a maintenance defect even if the new comparisons are internally consistent.
An HMI can display the input and result after the calculation is established. Use separate labels for invalid data and a valid narrow classification. The WinCC Unified screen guide develops display and interaction decisions; adding a screen does not remove the need to test the underlying logic.
For analogue work, use the analogue signal guide and data conversion reference before substituting raw module values for width. Scaling, rounding and acquisition diagnostics are additional requirements. The fictional integer range on this page is not a universal Siemens raw-input range.
Build a practice route around evidence you can show
Your first portfolio item can be modest: a requirement, a tag list, a block call diagram, a test table and a short fault explanation. Include the software and target information, and distinguish tests completed in a general model from tests completed in native software. Avoid claiming hardware experience from a screenshot of a conceptual exercise.
PLC data-type practice supports the distinction between Booleans, integers and other representations. PLC program testing practice helps build expected-result and debugging habits. Check the product's current lesson access before choosing a plan for your study schedule.
When comparing South African courses, request the exact TIA version, CPU target, individual practical access and assessment method. Ask whether you will create a project yourself or mostly follow demonstrations. The PLC course price guide helps compare the total offer, while the Siemens learning hub connects the next technical topics.

Questions beginners ask about TIA Portal
Can I learn TIA Portal without a physical PLC?
You can learn project organisation and practise supported simulated tasks with the appropriate software setup. Confirm compatibility for the target and simulation product your course uses. A simulated test does not prove wiring, electrical characteristics or physical I/O behaviour.
Must every variable be in the default PLC tag table?
No. PLC tags, block-local tags and data-block variables have different declaration locations. Choose the location from scope and ownership. A variable used inside a block may therefore be correctly declared outside the default PLC tag table.
Are absolute addresses forbidden?
No. Siemens documents absolute addressing as well as symbolic addressing. Descriptive symbols usually make the intent easier to follow, but the mapping and data type still need checking. A readable name cannot correct a wrong address.
Why does my program compile but classify an item incorrectly?
Compilation checks do not establish that your thresholds match the requirement. Test boundary values, inspect supplied inputs and verify mutually exclusive outputs. A syntactically valid comparison can still implement the wrong rule.
Is the first project supposed to control a motor?
No. A small data decision is enough to practise declarations, calls, compilation and testing. Physical control introduces additional design and practical requirements. Choose the exercise from the learning outcome rather than adding an actuator for appearance.
What should I learn after this exercise?
Add one requirement at a time: a changed boundary, explicit last-good data or a separate HMI display. Then study stateful blocks and communications with their own tests. The next step should expose a new concept while preserving the evidence that the earlier decision still behaves correctly.