Allen-Bradley vs Siemens: Why Plants Pick One PLC Platform and Live With It [Field Q&A]

Welcome to Factory Field Notes, the podcast for manufacturing leaders, engineers, and technical managers who want practical lessons from the plant floor. I'm your host, Vladimir Romanov. In this show, we talk about the systems, projects, and decisions that shape modern manufacturing, automation, control systems, SCADA, MES, OT networks, industrial data, reliability, downtime, and technical leadership.

My goal is to bring you real conversations and field-tested thinking on what works, what fails, and what manufacturers need to understand before they modernize. Let's get into it

How's it going, everyone? Welcome to the next episode. As you can probably tell by my background, I am not in my home office. I am traveling this week at a client site, overseeing a very interesting project, the details of which, unfortunately, I cannot disclose at this time.

That being said, today we're going to tackle, in a similar fashion that we've done before, some of the questions that are the most popular this week when it comes to industrial automation and manufacturing

the first and most popular comment that we have today is going to be the status report of a one-month-old apprentice tech just out of school, and the meme that he has used is that he's got no idea what he is doing. And this is very common in our industry. I often have to coach newer techs and even engineers as they step foot on the manufacturing floor that it's going to take a lot of time and effort to actually understand and get to some comfort level that you are capable at delivering at your specific role.

And the reason, of course, is to an extent obvious, but it's the fact that manufacturing touches many disciplines. You have your electrical or industrial control systems, you have your mechanical, you have your process. Of course, it depends on the industry which way it's going to lean more or less towards.

You have your quality systems, you have your general business systems. In most places, you're going to encounter almost immediately some flavor of Lean Six Sigma or continuous improvement, and all of those disciplines can be a career of their own. So with all of that in mind, it takes quite a bit of time for someone new to manufacturing, new to a specific business to learn the ropes so that they are capable and comfortable of delivering a good job.

And of course, the question often becomes what do I need to focus on as an individual contributor, usually earlier in my career?" And so as a technician, I would assume that you are given tasks to accomplish on a day-to-day basis. I would be willing to bet that the management or the leadership team within your organization generally understands where you are at and is giving you tasks where you can grow as an individual, you can also understand different parts of the process, but at the same time, if you were to fail, would not be too catastrophic for the business.

Of course, as you grow in your career, as you grow in your understanding of the process, they will be giving you more and more challenges that may carry out more risk And so at the beginning of my career, which started back in 2013 after I had graduated, I remember stepping foot on the plant floor as a newly minted electrical engineer, and I had no previous background and/or knowledge of control systems.

I had never seen a PLC. I have never been in electrical cabinets. I had studied a lot more on the embedded system side, how to build electronics. Of course, I have done a lot of theory, but I have not had the opportunity to practice some of those skills. And I still remember that the first week that I entered the facility, they were deploying a new packaging line, and a lot of my tasks were just supporting the engineering team that was checking out IO, that was pulling or testing some of the cables that were being pulled by the electrical team.

It was just going through documentation to understand some of the equipment, but also understand the processes in that kind of a business. So I would not be overwhelmed, and I would not also expect that after a month you have understood the business. I can honestly tell you that even after a decade of experience in manufacturing and industrial controls, there's still a lot of puzzles that I am unaware of.

There's still a lot of things for me to learn, both on the electrical side, just like on the process and mechanical side, as well as the business side. So that aspect never truly goes away. It is important not to get overwhelmed. It is important to understand that there is a fairly steep learning curve, and it is important to keep communicating with your superiors and the leadership team what it is that you're learning, what it is that you're lacking.

And of course, there's going to be a lot of different advice that I can give you, but ultimately, do not get overwhelmed by the amount of information. It is normal to be feeling behind only after a month being on the job.

All right, and so the next question that we have for you comes from a username called Regard Engineer, and he asks, "Why Allen-Bradley? I'm an automation engineer at the maintenance department of a factory in Europe. Our plant is dominated by Siemens 90%, and the rest we have three or four Schneiders that we will also be replacing with Siemens in the future, a VPA and a second place is Allen.

From what I have seen on the sub created me an image of people mainly using Allen-Bradley PLCs. Maybe it is because most of the people here are from US and Canada. My question is why would, in theory, somebody use Allen-Bradley and not Siemens? No hate, it's a genuine question, and I would like to know more."

And so this is a very good question, right? So first and foremost, there's going to be a lot of factors. It is important to understand that as you develop your understanding of not only systems but also people and general business in our industry, you will notice that the decisions are not purely influenced by technology.

So when it comes to deciding on which not only PLC platform in this case, but it's PLCs, it's your HMIs, in a lot of cases it's going to be the peripherals inside of the electrical panels, but also your SCADA and MES systems, it is quite a big decision for a business to standardize on one platform or the other.

And so generally speaking, where does the process begin? And so early in the factory's life cycle, someone probably purchased machines of different kind. If they were not made by the company, they typically came with their own control systems. And as the company grew, as it placed more and more equipment onto the plant floor, it becomes more difficult, or I would say more challenging, to support all the different vendors, and you're also looking for software and hardware that may harmonize a lot of that equipment.

And so you start looking at different vendors. Obviously, you have your Siemens, you have your Rockwell, you have your Schneider, you have your Opto 22s, your Phoenix Contact. There's going to be a lot of different options when it comes to selecting a control system. So number one, you need to consider the currently utilized control systems in your area.

And why, you might ask? Number one, if you're going to be hiring engineers and technicians, one may argue that one can easily go and move their knowledge from, let's say, Rockwell or Siemens, vice versa. The PLC programming is going to be the same on any given platform. However, I would challenge, I would say, that notion because ultimately when we talk about experience, it is not just about knowing what an XIC or XIO instruction is.

It is having worked with a platform for long enough to recognize some of the very small nuances that can bite you in the moment of troubleshooting, and that could be understanding how to get the manuals. It could be seeing how the firmware flash process is performed, something that you're not going to necessarily learn in your first couple of months of using the specific PLC and/or HMI.

The second factor, of course, is once you've hired the people you're looking on the market is going to be your distributors and/or integrators and/or different partners that may help support the manufacturer. So imagine for a moment that you are in the, let's say, the European market, and the majority of deployments are going to be on Siemens or Schneider or a few other variants, and there's not a whole lot of Rockwell.

Imagine if you decide to standardize the entire factory on Rockwell. Are you going to be able to source the hardware easily? Are you going to be able to pick up the phone and find a systems integrator that can come in during a midnight shift and troubleshoot that equipment? And of course, all of those human relationships are going to be very important when it comes to selecting that equipment.

So going back to the original question, historically, different PLC brands captured different regions, and there's a much stronger presence of Rockwell or Allen-Bradley control systems in the North American regions. As it was mentioned, anything in Mexico, USA, and Canada is typically going to be Rockwell leaning because, again, they have the infrastructure, they have the training centers, there's a lot of integrators, there's a lot of individuals that know Rockwell, as opposed to, let's say, the European market where a lot more of the standards are going to be with Siemens.

Similarly, if you look at Asia, they're going to have their own flavors of PLCs. You're going to see a lot more Omron, you're going to see a lot more Mitsubishi, and of course, their own other proprietary control systems. So it is simply the growth of technology over time in specific regions, but it is also the network that has been put in place.

Now, if we take all of that aside, on the technical note, if I were to draw an easy to understand comparison based on my own experience, I would compare Rockwell to Apple, while I would compare a Siemens more to Android. What I generally mean by that because that could be interpreted in many different ways, is that Rockwell is usually easier to use but is a lot more restrictive.

You have to do it the Rockwell way, and you don't have a whole lot of customization options. Whereas when you go with the Siemens route, you have a lot more options when it comes to setting up different variables, programming in a way that makes sense for you. But at the same time, it is a little bit more complex on the engineering side.

What you will normally see is in the Rockwell side, you will almost always see ladder logic being the main language of choice, whereas in the European markets, you have a lot of structured text, and you also have a lot more engineering Capability within the manufacturing environment. So what I mean, again, by that is in the North American regions, you will have typically leaner teams that rely more on external resources when it comes to programming their control systems, whereas Europe has a higher density of highly capable engineers that can program systems that are fairly more complex.

And so there's also some of those challenges and nuances that we can throw in. Now, the last comment I do want to make is, of course, those organizations have a very strong sales presence. And again, this can be tied back to integrators, this could be tied back to distributors, but ultimately, when you have a platform that has already been embedded into a manufacturer at a certain stage, it becomes very difficult to switch, and the salesmen of those organizations will typically come in and offer other products that work very well within the ecosystem.

And of course, we can talk about different drives, we can talk about energy monitors, but ultimately, if you're within the Siemens ecosystem or you're within the Rockwell Automation ecosystem, it is usually easier to integrate their own products inside of either Studio 5000 or TIA Portal. And this could be, again, your VFDs, this could be your servo drives, this could be even your Ethernet switches or anything that lives on top of those systems.

That's not to say it is impossible, but it is very difficult, or I would say abnormal, to see a, let's say, Rockwell PLC with all the Siemens HMI as an example. Once you have the control system, you're typically going to pair that with your HMIs, and then they're going to come in and tell you that you can now use the VFDs, you can use the flow meters within the same system of your choice.

So that is historically why plants usually pick one of the control systems based on the region and then grow into some of the other hardware and/or software offerings.

Hi, my name is Vladimir Romanov. I am the founder of Joltech as well as Solis PLC. With a background in electrical engineering and an MBA, and over a decade of experience leading projects in manufacturing and industrial automation, I help engineers, managers, and manufacturers make smarter technical and business decisions, modernize their operations, and build stronger careers.

If you're serious about manufacturing, automation, and staying ahead in the industry, subscribe and join the community

all right, so here we have a very interesting question when it comes to maintenance and troubleshooting coming from a user by the name of ActualAdvisor8213 and he says, "Do you check logic first or hardware? Had one of those PLC reality checks moments recently. Was working on a Siemens S7 system where a conveyor kept randomly stopping.

Logic looked fine at first glance, no obvious faults. HMI wasn't showing much either. Turned out to be an intermittent prox sensor dropping signal just long enough to trip the logic but not long enough to constantly alarm. Spent hours chasing code before realizing it was a field issue.

Made me realize how often PLC problems aren't actually in the logic but in wiring hardware part, sensors or noise. You can know ladder logic well, but troubleshooting in the real world is a whole different skill. Wanted to know how often others look into this. Do you usually suspect hardware first or the logic?

And this is a very interesting question for a variety of different reasons. I have actually been contemplating putting together a troubleshooting course, again, where I would go over the different hardware, the different software, ways to trend signals, ways to track different data and variables to better analyze what is happening within the system in order to shorten the time to troubleshoot.

But to answer his question, I would generally lean personally towards software. So I'm very comfortable working with PLCs, SCADA systems and MES therefore I normally look at the data. And that of course, after I have had the conversation and understood what the operator has experienced. So if we want to take a step back, the usual process that I typically take when troubleshooting such a problem is number one, I would expect that the operator has the most knowledge of the process and/or system and is capable of explaining what abnormality he is experiencing and/or seeing.

Meaning that the system is not doing what it is expected to do. Ultimately, I'm not the expert in running the machine. The operator, the mechanic or whomever is on the plant floor should know better. So they are capable of explaining what is the normal state and what is the current state that they believe is not not behaving as expected.

The second item is, of course, typically every piece of equipment is going to have some kind of an interface. In most instances today it's going to be an HMI and so that HMI will generally tell you what is the fault code, right? So why was the machine stopped? Again, some equipment is going to have a historical view, some machines are only going to provide you with the current state but at least it gives you an indicator of what to look after and that fault, again, barring not being extremely helpful usually is going to be one of the first leads The second question that he's asking, do you look at the PLC code or do you start troubleshooting the hardware?

The problem that he described as he mentioned himself is very difficult to see with the naked eye. So barring you just looking at sensors from A to Z, you would not have been able to detect that problem. So I would start questioning as to what he looked at when it came to the actual logic, right?

So he said that the problem was intermittent. Was the machine stopping? If the machine is stopping, usually when you go down the rungs of your ladder logic, you're going to have a condition which stops the machine and of course then the question becomes have you implemented any way to capturing what has actually stopped the machine?

Again, there's going to be different ways of writing that logic and creating that program which could be very bad, it could be extremely well-written and the truth is obviously it's going to be somewhere in between if we're talking about a general case. So once we have figured out that the machine is stopping intermittently, there's going to be different ways to diagnose that problem.

Once again, do we know which input or which bit within the stop logic is stopping the machine? Then we can work backwards. What can stop the machine? We can create latches, right? If you have a scenario where you need to come back because you're unable to see the problem, at least you can create some logic where you can capture the different bits that can stop the machine and when they actually trigger either by trending them or capturing them inside of a specific array.

So there's going to be a lot of different approaches. I guess my personal opinion is that I would start looking within the logic first unless the alarm and the description from the operator clearly indicates that this is some kind of a mechanical problem. If default is, for example, that the process is jammed at the exit of the machine, I'm obviously going to start looking at the exit conveyor to see if there's no debris, if there's not something blocking the sensor or if it hasn't been simply knocked by maybe a forklift driver that has inadvertently missed the turn, right?

So that's going to be one example where it's obvious that it's mechanical but for me, again, I can usually remote into the machine, I can connect to the PLCs. I typically would show up with a laptop with the right software so I can connect and start looking at the signals

The next interesting thread that was extremely popular this week is this photo of an HMI that was completely, I would assume, keyed, but maybe just damaged by some other tool. Could have been a screwdriver, of course, could have been a pen. It says, "Lovely photo I just received on a unit that I have had no complaints or issues about in the last few years."

And this is, for those who are not familiar, this is a PanelView Plus. I would assume it's a 1000 series. Again, it could be the plus six or seven version. That being said, this is extremely common in our field. I would say that equipment gets damaged all the time in a general sense. What is a little bit less common is, of course, cases of pure vandalism, right?

So someone must have known that they would damage the screen, and they have scratched the screen to a point where, again, it is probably going to be usable, but it is not something that I would expect in a normal plant environment. Of course, with time, I have seen some of these terminals that have gone for twenty years simply from being pressed so many times.

There will be finger imprints, again from gloves or from just hands with chemical products, for example. But again, something like this is abnormal. How can you fix this problem? There's the human side, right? How do you deal with the operators that maybe have caused a lot of dollars worth of damage?

But ultimately, on the technical side, you can replace those screens. So you can order a touch screen that you can pull off the PanelView one thousand or any other version series, and you can replace the front screen, replug the cable. It's not an easy fix. It's not just plug and play. You need to be really careful on how to get this done, and there's going to be companies that do this as a service.

It is not a cheap terminal to replace. If you're talking about the entire PanelView series, of course, you need to download the program, you need to purchase the terminal. That could be two to five grand, again, depending on the features, depending on whom you're buying from. And then you need to load the program, the configuration.

So it is quite a significant amount of damage that we see in this photo, which is unfortunate for the manufacturer

The final question that we have for you is interesting, and it comes from the username by the name of Himanushu Creative. And the user is asking, "Does every PLC system eventually become harder to modify with time? It feels like a lot of automation systems start off clean and manageable, but after years of updates, quick fixes, production changes, and integrations, they slowly become difficult to troubleshoot or expand safely.

At some point, even small modifications can feel risky because everything is so interconnected. Curious whether people think this is just unavoidable in industrial environments or if good architecture and standards can realistically prevent it long term." And so again, I'm assuming that this was, to an extent, a rhetorical question.

Of course, standards and applications that are built in a scalable fashion are going to make some of the job and software changes a lot more manageable. This is no different than any other environment. We always have what's called scope creep, and ultimately, software becomes more and more difficult to manage as more changes are being made.

This is no different than a web application. This is no different than a mobile application. As it grows in complexity and size, it usually takes longer to make those changes. It takes a lot of time to validate some of those changes against the existing code, and the industrial automation space is no different.

What I would say is a little bit more challenging in the industrial automation space is that broadly speaking, we do not have preexisting standards as you would expect within the software ecosystem. We do not necessarily have clean function definitions. If you're going to write code in ladder logic or structured text, you can generally write however you would like.

There is no encapsulation and general best practices to segment, I would say, certain components of your code that then become reusable as you would see on the web or mobile front. So of course, the challenges are going to be different. Now, of course, there's the added complexity, as I've talked a little bit earlier in this episode, of different disciplines needing to be known in order to make some of those changes.

So usually what happens as you start modifying the system, it is easy to assume that the next person is going to have the same knowledge and understanding of the physical world, of the process world, that they understand the P&IDs that may have gone missing, and thus making changes that are almost impossible to trace back.

And of course, as he alluded to towards the end of that question, the best practices or the best manufacturers are going to, an extent, track some of those changes. They're going to document the changes. They're going to write- implementation procedures that will track what is happening within the facility.

It's also important to understand that the plus side of control systems is that generally speaking, if you're writing in a standard language using a standard platform, it is to an extent easier to trace back and reverse engineer as opposed to the mobile and web applications. We do not have applications that go in the cloud and then send data between different continents that can handle dollar transactions and user logins and need to be cyber secure.

Again, I put that a little bit in air quotes because the hardware does need to be protected, but ultimately when you're programming in ladder logic, usually you can visually see all the components that are interacting within that system, and of course there's going to be applications that need to absorb some of that data in the general sense.

But for the most part, the complexity is going to be contained on that plant floor. And when I talked about segmentation, I was very specific about software segmentation. It is almost always possible to, when you have a line and you're looking to deploy a second line, to take the program from that PLC, put it in the second PLC, and thus you have a separate control system for both of your production lines, and then when you take that site and you move it somewhere else, or you purchase more equipment, once again it is segmented.

So technically the code that controls that specific line is going to only control that line, and although it may have some handshakes to the outside, it should not in theory grow in too much complexity. Usually, when that equipment has lasted for thirty years, forty years, it's going to be thrown away and replaced by something new.

So it is not to say that the complexity is going to grow infinitely when it comes to that specific design. Now of course as you start layering some of the other platforms, we talked about SCADA, we've talked about MES, we've talked about network systems, there is an increased amount of complexity when it comes to those designs and it becomes more and more challenging, I would say in this day and age, to manage that everything communicates properly, all the connections are made.

Hopefully that makes sense. I know that there's a lot to unpack in each one of those questions, and I will see all of you next time