3 Things I Don't Like About PLC Programming in TIA Portal

Ever since TIA Portal first dropped back in 2011, it’s been my trusted software platform for handling industrial automation projects. Overall, STEP 7 does a solid job - it gives you everything you need to develop, run, and troubleshoot even the most complex PLC applications.

But... there are still three things about STEP 7 PLC programming that bug me - big time. And honestly, they've been missing since day one… from version 11 all the way up to the latest version (V20 at the time of writing).

So let’s get into it. These are the 3 things I don’t like about PLC Programming in TIA Portal. Make sure you stick around for the last one, because if Siemens ever fixes this one, it could be a total game changer for us PLC programmers.

1 - No Retain Setting for Individual Structure Tags

In TIA Portal, Retain properties help you keep important variable values even if the system restarts or loses power. By setting a variable’s Retain property, the system saves its value to non-volatile memory, so when it powers back up, everything picks up right where it left off.

Overall, retain properties are pretty well integrated into TIA Portal, but there's one area where Siemens dropped the ball. You can't set retain properties for individual elements within a data structure.

Take a look at the example below - I’ve created six individual structures for an infeed module data structure:

• Infeed_Cfg – Configuration data

• Infeed_Sts – Status data

• Infeed_Cmd – Command data

• Infeed_Par – Parameter data

• Infeed_Srg – Shift register data

• Infeed_Flt – Fault data

You can select the retain property for each individual structure. For example, I’ve enabled the retain property for the Cfg, Par, and Srg structures.

Now, take a look at another example below where I’ve created a single infeed data structure (using a user-defined data type UDT_EM_Infeed).

Here, you can only select the Retain property for the entire structure, not for individual sub-structures (those options are all greyed out).

There’s no reason this shouldn’t be possible. The foundation of creating scalable, maintainable, and easy-to-troubleshoot PLC applications is modular data, where all data related to a specific module can be organized into a structure. If modular design is an essential part of good PLC programming practices, then why are we restricted by not being able to select retain properties for individual elements within a structure?

Due to this limitation, I sometimes have to compromise and use less efficient data structuring solutions just to have control over individual retain settings.

So here's one for the Siemens suggestion box: Please allow us to set retain properties for individual elements in a structure.

2 - Data Block Changes Clear Data After Download

Making online edits and downloads in TIA Portal is pretty simple and user-friendly. One of the things I love is that TIA only downloads the data that’s been changed, not the whole application. It makes everything faster and more efficient.

But there’s one area where TIA Portal could use some improvement: how it handles reinitializing variables in a data block after a download.

Let’s say you add some variables to your datablock during production, and now you want to download those changes. Ideally, you'd want the existing production values in that block to stay the same, right?

Well, by default, TIA Portal will reset all the data in that DB after the download. So if you have a step or sequence variable in your data block, for example, it will be reset (like to zero), which could mess up your production process.

To address this, TIA Portal offers some kind of a workaround by allowing you to set up a memory reserve and retentive memory reserve.

This solution is pretty complicated (very few know how to actually use this) and has one major flaw - it assumes you already know the maximum size of your DB for any future updates. Honestly, this just isn’t practical for PLC programmers. We need something simple and straightforward (K.I.S.S  - Keep It Simple, Stupid).

Why not make sure current data remains unchanged after download by default? That way, every time you make a change online during production, you won’t be holding your breath wondering what happens after you hit the download button.

A solution could be: after you click download, TIA Portal uploads the current online values to a buffer, downloads the updated DB, and then restores those buffered values into the new DB. They could even add an option in the download pop-up, like "Would you like to initialize the data?" for those rare occasions when you actually want to reset everything. 

But let’s be real - 99.9% of the time, you don’t want to clear all your existing data.

3 - Cross-Reference Through FB/FC Block Interfaces Not Possible

One of the most effective tools for troubleshooting a PLC application is cross-referencing. Being able to search where a variable is used, or where a flag gets set or reset can save you tons of time when you're tracking down issues.

But here’s the thing: one of my biggest frustrations with TIA Portal is that you can’t cross-reference through the interface of a function block (FB) or function (FC).

Here's what I mean by that.

Say you’ve got a module structure called Infeed, and inside it there’s a sequence variable like Infeed.Cmd.iSequence. In your main program, maybe Network 9 checks if the sequence is 0 and the machine’s in production - if so, it sets the sequence to 1. Then in Network 10, if the sequence is 1 and the machine faults, it resets it to 0.  Just an example, where I oversimplified the logic for clarity.

Now if you click on iSequence and do a cross-reference, TIA Portal will show you exactly where it’s being used - two times in networks 9 and two times in network 10.  So far so good. 

Now here’s where things start to get problematic.

Let's say you make a function block and pass through the Infeed data structure as an InOut parameter - let’s call it iq_stModule. Inside that FB, you’re working with iq_stModule.Cmd.iSequence, same variable we used earlier in networks 9 and 10, just now being used as a formal parameter inside the block.

Now try running a cross-reference on that variable again. What happens? It only shows you where it’s used inside the FB. All the logic outside - like in Network 9 and 10 - is completely ignored. 

Same if you do it the other way around - search from outside the FB - it won’t show the usage inside the FB.

So the moment your variable passes through an FB or FC interface - whether it’s Input, Output, or InOut - cross-referencing just stops working. And that’s a nightmare when you’re trying to troubleshoot.

And you want to know the ironic part? Siemens actually wants us to write modular code, use structured data, and pass it through FBs and FCs (especially as InOuts for better CPU performance). But when we do things the ‘right’ way, TIA Portal ends up limiting the one tool we rely on most when debugging - cross-referencing.

It makes no sense. We’re doing things by the book, and we’re getting punished for it.

This really needs to get fixed. Being able to find variables across your whole PLC application - regardless of whether they’re used as formal or as actual parameters - should be a no-brainer.  It’s 2025, and we’re still missing this? Come on Siemens, throw us PLC programmers a bone here.

So there you have it - my three main complaints about Step 7 PLC programming in TIA Portal.

Now don’t get me wrong - TIA Portal is still my favorite go-to platform for everything PLC programming. But after working with it since 2011, it’s frustrating to see that these three issues are still around. They really hold back what could otherwise be an even more powerful and efficient all-in-one automation solution.

If Siemens could just fix these three things - being able to set retain properties on individual structure elements, keeping DB data intact after downloads, and making cross-referencing work through FB/FC interfaces - it would make our jobs so much easier (and less stressful) out in the field.

Here’s hoping we get some of these fixes in a future update (anyone from Siemens reading this - I hope you're taking notes! :-) ).

-Hans