Shift Registers in TIA Portal: A Real-Life Bottling Line Example

Let’s talk shift registers.

They’re everywhere on modern production lines, and for good reason. As automation advances and data collection gets smarter, shift registers are becoming essential for tracking each individual item, bottle by bottle or part by part, as it moves through the line.

In this guide, I’ll walk you through how shift registers work in TIA Portal using a real-world bottling line with 7 processing stations.

We're going to cover:

• What a shift register actually is (and the 3 main components that make it work)
• How it fits into a real-life bottling line
• And finally, how to translate all of this into modular, scalable PLC logic in TIA Portal

 

Before we get started, just a quick heads-up: this blog is built around a fully downloadable shift register template I created for TIA Portal. You can download the project, follow along with the detailed step-by-step guide, and explore everything hands-on in TIA Portal.

👉 Get the shift register PLC template

It’s based on my own 20+ years of working with shift registers on complex production lines. It’s tested, error-free, and will save you a ton of time if you want to start integrating shift registers into your own PLC projects. Think of it as your plug-and-play blueprint. Simply copy the library blocks, UDTs and logic to your own application and you’re ready to roll.

Alright, enough with the introduction.  Let’s get structured with shift registers in TIA Portal!

 

---

What is a Shift Register?

---

 A shift register is a method to keep track of items on something like a conveyor belt. In a PLC program, it’s built using an array, filled with data, and periodically shifted to reflect the physical movement of the product.

 

Here’s a breakdown of those three key components.

 

THE ARRAY

A shift register is really just an array, where each element represents a specific position on your production line.

Here’s an easy way to picture it: Imagine your conveyor belt is split into zones. Each zone can either hold a product or be empty. As the conveyor moves, the data in your shift register moves with it, keeping track of what’s in each zone. Think of the array like a digital twin of your conveyor, shifting its contents along as products move from one zone to the next.

Let’s take a simple example. Say your bottling line has seven zones, numbered 0 to 6.

 

Each of these zones matches up with a position in your shift register array - Data[0] to Data[6].

 

 

So if a bottle is sitting in physical zone 1, that’s tracked in array element Data[1]. When it moves to zone 2, the data shifts, and now it’s in array element Data[2], and so on.

It’s a straightforward way to map real-world movement to data inside your PLC application.

 

THE DATA

This is where most people get creative (or messy). While you could use a simple array of integers or reals, the cleanest and most scalable way is to use a User-Defined Data Type (UDT).

A UDT keeps things modular and easy to maintain - change the structure in one place, and it updates everywhere. Perfect if your line grows or changes later on.

The exact contents of your UDT will depend on what your application needs. But from a high-level perspective, the structure of your data should reflect what’s actually happening on your production line.

For example, if your shift register is part of a bottling line with 7 key stations - infeed, cleaning, filling, capping, labelling, inspection, and reject - then it makes sense to build your UDT with those same stations as sub-structures. That way, each array element not only represents a position on the line, but also holds all the relevant info for that stage of the process.

 

  

Each process station usually needs two main types of data:

• Result data: things like whether the process was successful or not, and maybe a timestamp showing when it happened.
• Process-specific data: unique to each station. For example, the infeed might record a bottle’s ID, while the filling station might log fill volume or detect foam.

 

Structuring your data this way makes it easier for the PLC to make decisions in real time. It also sets you up nicely for things like reporting, analytics, or even feeding data into a larger system later on.

Insider Tip: It’s smart to include a general section in your UDT, basic stuff like whether a product is present, if everything has gone smoothly so far, or if a reject code was triggered. This kind of overview data gives you a quick snapshot of each product and is super handy for setting conditions or triggering the next step in your process.

 

THE SHIFT

This is the bit that actually keeps the virtual world in sync with the physical one.  Every time a product moves forward, the register shifts.

There are three common ways to shift a register forward in a PLC: using a virtual position window, triggering it with a hardware sensor, or handling it entirely with software logic.

 

 

Virtual Position Window

Many production lines (think belt conveyors or chains) nowadays use virtual axes. If you’re running something like a 360° cyclic virtual axis, you can configure a position window (e.g. 50 - 80°) - and when the virtual axis hits that window during production, the register shifts.

Hardware Sensor

A physical sensor picks up a recurring marker - like a pin or notch on the belt or chain - and uses that signal to trigger the shift. It’s a dependable option, especially when you want to keep things simple and independent from motion control.

Software Logic

Want full control? You can trigger the shift purely through logic - for example, when the line is running and all processes on a product are done. No extra hardware needed, no virtual axis required, but more error-prone if the logic isn't rock solid.

Now that you’ve got the basics of shift registers, let’s see what this looks like in an actual bottling line.

 

---

Real-World Bottling Line Example

---

Picture a line with 7 stations: infeed, cleaning, filling, capping, labelling, inspection, and reject. As bottles move from one station to the next, the shift register keeps track of every step.

Before we dive into the actual PLC application, let’s quickly look at the real-world setup and see what the shift register is actually doing at each of the 7 stations.

 

 

Module 1 - Infeed Station

This is where it all begins, position 1 in the shift register. The infeed station checks if a bottle is present and, if so, it logs that info along with a unique bottle ID and a timestamp. This becomes the starting point for tracking the bottle as it moves down the line.

Module 2 - Cleaning Station

At position 3, the cleaning station checks the shift register to see if a bottle is actually present (based on what was detected at the infeed). If a bottle’s there, the cleaning process kicks off. Otherwise, nothing happens. After cleaning, it updates the shift register with a status (done or failed), a timestamp, and process-specific data like spray volume, spray temperature, and drying time.
If cleaning fails, a reject reason gets added too so we know exactly why the bottle was marked as bad.

Module 3 - Filling Station

Sitting at position 5, the filling station handles the task of accurately getting the liquid into the bottles. Depending on the product, it could use gravity, pressure, vacuum, or piston filling. Fill levels are monitored carefully to avoid spills, foam, or overfilling.
The filling module checks the shift register to confirm a bottle is present and that cleaning was successful before starting. Once done, it writes back the result (done or failed), a timestamp, and details like filling volume and which valve was used.

Module 4 - Capping Station

Right after filling, the capping station takes over at position 6. It places the cap - whether it’s screw-on, snap-fit, corked, or something else. Torque control ensures it’s tight but not too tight, and sensors double-check that each bottle is sealed properly.
Before starting, it looks at the shift register to make sure everything so far has gone smoothly. After capping, it logs the outcome (done or failed), a timestamp, and details like cap type and applied torque.

Module 5 - Labelling Station

At position 8, labels go on. This module handles all kinds of labels - adhesive, shrink sleeve, glue-based - and makes sure they’re aligned correctly. Like the others stations, it checks if the bottle is present and has passed previous stations before running. After labeling, it logs the result, timestamp, and process details like label type, glue used, and vertical placement.

Module 6 - Inspection Station

Quality control happens at position 11. Vision systems, sensors, and detectors check fill levels, cap fitment, label placement, and overall bottle condition.
Inspection only runs if the bottle has passed all earlier stations. It updates the shift register with the inspection result, timestamp, and info like barcode check, fill level OK, or cap alignment.

Module 7 - Reject Station

Finally, we’ve got the reject station at position 12. If the bottle has failed somewhere along the way, this is where it gets kicked off the line - using a pusher, air blast, or diverter arm.
If a reject bottle is detected, it’s removed and the shift register logs a timestamp to confirm it was dealt with.

 

So that’s the full rundown of all 7 stations. Every station reads from the shift register to figure out whether it should run its process, and after finishing, it writes back status info, timestamps, and process-specific data. This lets us track exactly what happened to each bottle as it moves down the conveyor.

And remember, every time the conveyor moves forward (say, triggered by a virtual position window), the bottles shift one physical position forward, and the data in the PLC’s shift register shifts right along with them.

Ready to see how all this shift register magic looks in a real TIA Portal PLC project? Let’s dive in.

 

---

PLC Application - Shift Logic

---

As mentioned at the start of this post, you can grab the full PLC application of this bottling line example as a downloadable template. It comes with a detailed step-by-step guide that walks you through every part of the shift register setup and how it ties into a bottling line - packed with insider tips and best practices I’ve picked up from real-world projects. 

👉 Download the shift register PLC application 

If we take a closer look at the PLC application, it’s organized into five main sections or groups:

• Machine section: Handles overall machine control, including the state handler, recipe management, and the shift register logic.
• Equipment section: Contains all the process logic for the 7 individual stations.
• Global data section: Stores all the Data Blocks (DBs) used globally throughout the program.
• Library section: Houses all reusable Function Blocks (FBs) for modular programming.
• Organization Blocks: Includes all error handling, startup routines, and interrupt OBs.

 

 

 

These groups help clearly separate the different parts of the application, making it modular and much easier to troubleshoot and scale as needed.

Before we jump into how the shift register fits into the PLC program, it’s important to understand the difference between two main parts:

• Shift register core logic and data: This includes the actual array stored in a Data Block (DB) and the library Function Block (FB) that shifts the data forward or backward. This core logic lives at the machine level, inside the machine section.
• Station-specific logic: This is the code each station uses to read from and write to the shift register. For example, the filling station checks if cleaning was successful before starting. This station-level logic is part of the equipment section, implemented separately for each process module.

In this section, we’ll focus on the core shift register logic and data structure. Then in the next section, we’ll dive into how each station interacts with the shift register through its own specific logic.

 

THE ARRAY

The shift register itself - an array made up of multiple elements all sharing the same user-defined data type - is declared in a global DB “DB - Shift Register”, organized under the Global Data group.

 

 

In this template, I created an array with 21 elements, indexed from 0 to 20, using the user-defined data type UDT_SR_Data. That means the shift register holds 21 positions in total.

 

 

THE DATA

Each element [x] in the array follows the same data structure. This structure includes information for all 7 stations of the bottling line, plus a general sub-structure that tracks overall bottle info, such as whether a bottle is present, a reject flag and code, and a unique bottle ID.

 

 

THE SHIFT

The actual logic that shifts the register forward or backward is packed into a reusable library Function Block (FB), which is called from the machine modules group.

 

 

This shift logic block is stored in the Library section.

 

 

Alongside the main shift control block, there are other useful blocks for re-usable shift register related tasks - like defining the shift register’s array size (great for dynamic-sized arrays) or writing process results (done/failed + timestamp) back into the shift register.

Opening the main control block, “FB Lib - Shift Register”, and checking its interface, you’ll find two key structures:

• iq_stControl: Configuration, command, status, and fault parameters to manage the shift register
• iq_stData: The shift register data array itself

 

 

 

The shift register data is passed as an InOut parameter - this is important for handling larger data efficiently and saving PLC resources. The data type of iq_stData is declared as an Array[*] of UDT_SR_Data, where the asterisk [*] means the array size is dynamic and can be any length.

This dynamic sizing means you don’t have to modify the library block each time your shift register size changes. The block automatically adapts to whatever size array you pass in.

Inside the shift register block, the logic follows this order:

• ARRAY - Retrieve the array size (needed because of the dynamic array)
• COMMAND - Define commands to trigger shifts forward and backward
• SHIFT - Perform the actual forward and backward shifts
• STATUS - Update status signals for the shift in the control structure
• OUTPUT - Provide output signals on the block call for easy troubleshooting

 

 

The first network in the block reads the array size.  For example, if your array runs from Data[0..20], the low limit is 0, the high limit is 20, and the size is 21 elements.

 

 

Networks 3 and 4 handle shifting the array forward (NW3) and backward (NW4).

 

 

The main TIA Portal instruction used here is MOVE_BLK_VARIANT. For a deep dive into this instruction, check out Siemens’ official documentation: Siemens MOVE_BLK_VARIANT Info.

Note: All shift register–specific instructions are explained in detail within the downloadable template.

 

Now, let’s take a look at how these shift register library blocks and logic are used in the individual processes for each of the 7 stations on the bottling line.

 

---

PLC Application - Station Logic

---

As mentioned earlier, the shift register integration consists of two main parts: the core shift register control that handles shifting the array data forward, and the station-specific logic that needs to be added for each process module - in our case, each of the 7 stations.

To quickly recap, the 7 stations on the bottling line are: Infeed, Cleaning, Filling, Capping, Labelling, Inspection, and Reject (if you need a refresher, feel free to scroll back to the start of this article).

All these modules are organized under the Equipment group. To keep the project scalable and modular, each station is programmed using a single dedicated Function Block, making the system easier to maintain and expand.

 

 

 

Each module has its own configuration data, which is initialized in the “CFG - Equipment Modules” block.

 

 

In the configuration screenshot above, you can see that every module is assigned a specific shift register position. For example, the infeed module is at position 1, the cleaning module at position 3, and so on.

This configuration setup provides flexibility, allowing your shift register standard to adapt easily. Different production lines might have different stations assigned to various positions within the shift register.

 

Taking a closer look, you’ll see that each function block follows a similar structure, organized into distinct network sections.
 

 

 

Basically, each processing station function block includes these 5 key parts:

• Sequencing logic
• Fault logic
• Status logic
• Output logic
• Shift register logic

 

Let’s take the function block for the filling station as an example, named “FB - EM Filling” (by the way, I use EM to stand for Equipment Module, while MM is used for Machine Module).

The network layout looks like this:

Every station follows the same basic setup.

SHIFT REGISTER READ LOGIC

The first two networks (Network 1 and Network 2) are primarily responsible for reading data from the shift register at the pre-configured shift register position for that station.

In Network 1, we verify whether the configured shift register position for that station falls within the valid boundaries of the actual shift register array.

 

 

Network 2 defines the shift register conditions required for the station to process a bottle.

 

 

Here, the bottle must be present (bottle present flag = TRUE) and must have passed previous processing steps without rejection (general reject flag = FALSE). Only when both conditions are met can the bottle be processed.

 

SEQUENCING LOGIC

This condition is then used in the station’s sequencing logic to guide the processing steps for the bottle.

 

Each station’s process starts when the basic flags are active, such as start process, module selected from HMI, production line running, no module errors - and the shift register condition to process the bottle is TRUE.

Once a station completes all its steps without any hiccups, meaning it's no longer busy and there's no module error, we set a "process done" flag. This flag is unique to each station and tells the shift register:

"This bottle’s been processed successfully".

 

 

The “process done” flag triggers the shift register write logic for that station.

 

SHIFT REGISTER WRITE LOGIC

The shift register write section of the function block takes care of logging the process status - whether it’s done or failed - at the station’s position in the shift register. Along with that, it also writes a timestamp and any process-specific data for that station.

First, we figure out why a process might have failed. This logic sits in the first network of the write section and sets a fail code.  That code is then used in the next network (writing process results) to calculate the reject code (=why was the bottle rejected).

In this example, we’ve got two possible failure reasons:

1. The station wasn’t selected on the HMI → fail code 1
2. A module error occurred (before or during processing) → fail code 10 to 14 

 

 

If either of these conditions is true, the “process failed” flag is set.

The second network takes care of writing the general process result to the shift register - whether the process finished successfully or failed - along with a timestamp. This write action is triggered by either the Srg.xProcess_Done or Srg.xProcess_Failed signal, and is handled using a reusable, self-contained function block: “FB Lib - Shift Register - Write Result”.

 

 

NOTE - All shift register library blocks are explained in detail inside the downloadable template.

 

The final network in this section writes process-specific data to the shift register, but only if the process completed successfully (Srg.xProcess_Done = TRUE).
Depending on the application, you might also want to log process-specific data even when the process fails, especially if detailed data collection or diagnostics are required.

For example, in the filling station, the following values are written:

• Whether foam was detected
• The actual filling volume
• The valve used for filling

 

 

This structure for writing process data to the shift register keeps the logic consistent across all modules, while still offering the flexibility to handle station-specific details where needed.

 

---

 That concludes this in-depth walkthrough on what shift registers are, how they’re built, and how they integrate as a powerful automation layer on top of an existing TIA Portal application. I hope this article has boosted your confidence and deepened your understanding of shift registers!

DOWNLOAD THE TEMPLATE

Want to explore shift registers in even greater depth and build your own with detailed step-by-step guidance? Then go and download my ready-made shift register template.

Get it RIGHT HERE.

Simply download the TIA Portal project, follow the step-by-step guide, copy the UDTs, library blocks, and logic into your own application, and start building modular, scalable shift registers with proven, reusable blocks - no need to reinvent the wheel.

I hope this guide and the practical bottling line example gave you some valuable insights, and maybe even a few “aha” moments.

Thanks for reading, and I’ll catch you on the next one!

-Hans