Manufacturing Concepts - Edge Devices, PLCs, IPCs & Industrial Automation Software Hardware Architectures

I’ve received an interesting question from a friend of mine - “Is there a way to run Python on a Rockwell Automation PLC?”

Although I know it’s possible on a very specific PLC, I immediately had multiple questions for my friend - Why would you want to do this? Why would you want to run Python specifically? Why would you want to run this within the PLC vs an IPC? Would you be ok to run this on Windows?

Long story short, I believe that there’s a lot of confusion caused by an ever-increasing number of options in our space. Remember - “With great power comes great responsibility.” In other words, just because you can do something doesn’t mean you should. However… When should you?

What is a PLC, and Why Were They Invented?

Computers existed before the first PLC, or Programmable Logic Controller, was created. The invention of the PLC was aimed at several deficiencies - mainly resilience and close ties to control systems. The goal of the PLC has always been to efficiently capture signals, process as fast as possible, and set the right outputs for the process. The PLC was not designed as a system to store vast amounts of data, to spit out reports, to manage recipes, to automate ERP functions, etc.

Why is that important?

Well, as technology advancements have been made to the PLCs, they’re now fully capable of the functions listed above.

So what’s the problem in programming all those applications directly on the PLC?

Well, depending on how it’s done, it can lead to downtime, maintenance challenges, and poor scalability.

Understanding The Downtime

PLCs need to be extremely robust. They thus contain a variety of errors that aren’t common in “standard” programming languages. An unskilled programmer can easily fault out a PLC by setting an out-of-bounds register, by overflowing an integer, by improperly setting an I/O, etc.

This brings me to the first point - Simply because you can now create an application at the PLC that isn’t directly tied to controlling a machine, would you want to incur the downtime that may result from that application?

The short answer is no - You should move that application to a dedicated device (Edge / IPC) so that if / when it fails, the control system can continue to operate independently.

Understanding The Maintenance

I’ve seen my fair share of poorly written code, and I’m certain that we could discuss that for hours. The reality of current control system architectures / environments is that your maintenance teams are “firefighting” 24/7/365. They don’t have the time (and most often the skillset) to learn all the intricacies of what was programmed in every PLC.

This brings me to the second point - There are certain software components that should be obstructed from the “general public.” We often advocate for the end-user to have unilateral access to all software at their facility. Understand the nuance presented here - The end-user should have full access to the software, while simultaneously be able to manage permissions as to whom can access certain software applications (Ex: Engineer, Technician, Manager, etc.)

So what happens in case of a breakdown? Well, technicians are the first “layer” of defense - the simpler the code, the easier it will be for them to address. Have you tried to trace an issue in a PLC that contains hundreds of AOIs, UDTs all for the purpose of a simple machine? - I’m looking at you “Integrators that abuse PackML.”

Understanding The Scalability

When I was a “young” engineer, I remember a project I was tasked with - creating a recipe management system that would let the operator adjust the ingredients for a specific batch, store the recipe, etc.

This solution existed in standard packages, but for some reason (I probably should have spoken up), the team decided it was best to build it on the PLC. the modern PLCs can be programmed to do anything, so we built the recipe management system on the existing PLC.

What was the issue?

Well, this brings me to the third point - There was no issue with this system as long as it was used as the system for that specific process. The issues came as this system needed to be migrated to a few other facilities that weren’t standardized with the same PLCs, process, batching, etc. The software that was built wasn’t scalable to other facilities and systems.

The moral of this story is that software should be built in a way that lends itself to being upgraded, migrated, and augmented within reason. By building software on a PLC, you’re exposing yourself to greater risk and challenges when it comes to these benefits.

What is an IPC, and Why Were They Invented?

An IPC, or Industrial Programmable (Personal?) Computer is just a ruggedized version of what you’ll find at home. They were created as a response to the need to run various applications closer to PLCs. 

Why do we need to run applications closer to the PLC?

Well, it really depends on the architecture - If you’re looking to send a few signals per hour to ensure that the temperature or level of your system meets certain requirements, there’s no need for an IPC. You can store that value and retrieve it into a server that’s on-prem or in the cloud for that matter. However, if you’re looking to process a lot of data related to the process, and you’re looking to do that at scan time (~4usec depending on the PLC), then you’re likely to need an IPC.

What can an IPC do?

Again, an IPC is nothing but a rugged box running Linux, Windows, or another Operating System (OS) that contains various applications. These applications can be as simple as ingesting data from the PLC and displaying them on a local panel, just as they can be made to process data from vision systems using a Machine Learning algorithm to determine the quality of a product. The limit of an IPC is often the size of the enclosure. I personally wouldn’t call a rack-mounted server an IPC, but it really accomplishes the same task if it’s physically located inside or next to a panel.

Why do we need IPCs?

As I’ve discussed above, a PLC is and should be, focused on a single task - controlling the process. This means reading the values from various devices and actuating outputs that lead to material transformations. The functionality of the PLC can be augmented via software that isn’t focused on controlling the process - attainment & metrics, quality control, remote alerts, event logging, etc. All of these tasks are important, but aren’t critical to the process. Furthermore, they don’t need to be (although they could be) programmed via the standard PLC IDE / languages - Ladder Logic, Structured Text, Function Blocks, etc. They’re simply easier to build using other tools - C++, Python, Java, etc.

The reason why we need IPCs is to host these applications separately from a PLC and thus reduce the potential risk of failure tied to the non-critical software.

Edge Devices in Manufacturing and Industrial Automation

If you’ve gone to a trade show or spent some time online in the manufacturing communities, chances are that you’ve heard the terminology of “Edge Devices.’ My opinion is that an edge device is an umbrella term used to describe any hardware that is inside or close to the industrial control panel.

Can a PLC be an edge device? - Yes.

Can an IPC be an edge device? - Yes.

What is the purpose of an edge device?

Depending on the organization, industry, manufacturing facility readiness, etc. you’re going to get different answers as to why you need or don’t need edge devices or systems. Just as I’d tell many of my customers - it depends…

I’ve done a lot of data extraction work which required me to be intimately familiar with a variety of plant floor protocols, network architectures, and processes I was working on. In that specific instance, the edge devices were deployed as “data concentrators.” A data concentrator is more than a simple gateway to syphon out plant floor data. It’s used to aggregate from multiple protocols, it’s used as a converter, it’s used as a buffer, and it’s used as a load optimizer. I won’t get into all of those in this article (reach out if you’re curious), but in short, it’s used to process the data in a way that makes sense, it’s used to add context, and it’s used to optimize the way this data is relayed into the database upstream.

What Should You Use in Your Manufacturing Facility

I often get into conversations with certain manufacturers who are shocked at the price of PLCs and are tempted by the various IPC and software-based control options. My response to that is always as follows: I can save you even more upfront cost by implementing all of your controls using Atmega328P-PU microcontrollers (These are Arduino ICs if you’re familiar). Your hardware costs will be extremely low, but you’ll have other problems - It’s going to take me months to build out this system, It’s going to be highly proprietary which will require me to be on staff until the day I’m retired, and It’s going to be unserviceable by anyone else.

They quickly understand that they should be using an off-the-shelf PLC for their controls.

The non-obvious debate resides between the PLCs and IPCs. I’ve illustrated examples where it’s almost immediately obvious which route to go. However, it’s not always that clear in the field. My general recommendation is that if you’re able to make it work on a PLC, go for it. However, the moment it starts to hinder your productivity, you should look to eliminate this practice as a potential factor. Furthermore, you should be upskilling your engineers and technicians on technologies that support technologies outside of the realm of PLCs. Often, this requires the involvement of IT.

My last point of advice - don't get lost in the options - there are many protocols (ex: MQTT), PLCs, IPCs, edge solutions, etc out there. Unless you have a highly specific application, many of them should be more than capable for the job.

Manufacturing Business Strategy

I’ve discussed business strategy regarding Industry 4.0 in a separate tutorial, which relates to this topic as well. I believe that the choice of control systems, IPCs, and Edge Solutions goes deeper into a technical conversation, but here are a few things to consider:

Understand the OEM You’re Working With

In 2024, nearly every OEM has an IPC solution - Rockwell Automation, Siemens, Opto 22, Phoenix Contact, OnLogic, etc. You’ll notice that I’ve intentionally listed some OEMs that only focus on the IPC / Edge Solution market. The reality of our industry is that the OEM that supplies the control system will often have a much more robust integration into their other devices, as you’d expect. This typically means that if you’re using Siemens, for example, then you’ll be much better positioned to use Siemens IPCs. Similarly, if you’ve got the ControlLogix line across your facility, it’s going to be easier to integrate their devices into your control system.

It’s not all black and white. My recommendation is to complete an assessment of your facility and understand the problem you’re looking to solve. It’s possible that your facility needs the exact opposite of what the control systems OEM is capable of providing you with. Note that there’s also a question of price - what will it cost you to bring in IPCs from the same OEM versus an alternative that might be just as good?

The last point when it comes to working with OEMs is understanding their network and support infrastructure - are systems integrators and distributors available in your area? Do they cover the specific product line you’re looking to add to your facility? What is their expertise in supporting manufacturers utilizing that particular line?

Understand the Technology You’re Using

As I’ve mentioned multiple times in this post, it’s important to understand what the software you’re looking to deploy will do. Furthermore, your technical team should articulate what’s process critical and what isn’t. If you want to minimize risk, have conversations with your teams as to how each software in your stack will affect plant runtime.

Understand the Stakeholders Involved

These projects are complex with many moving parts and stakeholders. You’d typically see your own staff (technicians, engineers, managers) and external resources touching various components of this system - Integrators, Consultants, Contractors, etc. Who has ownership of each system? Who’s ultimately responsible for responding to service and emergency calls? How can you mitigate the risks of outages, equipment shortages, knowledge deficiencies, etc.?

I’ve been in multiple meetings where the companies responsible for a specific technology clearly didn’t have the same vision as the business - You can’t shut down production, even if it means that your database doesn’t get the update until tomorrow morning. It’s important to have a competent IT / OT person that will educate both parties and provide a sanity check for different initiatives that can and will bridge from control systems (PLCs) and IPCs (typically owned by IT).

Going back to the Original Question!

We’ve gone down a fairly long tangent to answer the original question - “Can you run Python on a Rockwell Automation PLC?”

The short answer is - Yes.

The long answer is that there’s a very specific type of PLC that is capable of doing so. That controller comes from the CompactLogix 5480 line and is running Windows 10 IoT Enterprise on top of the regular control system.

The question then becomes - Should you run Python on this PLC?

My general advice, if you’re already using Rockwell Automation products (ControlLogix, CompactLogix, MicroLogix, Micro800) then you should probably stay within the compatible product line. However, I don’t believe that having a Windows-based PLC system is going to be the best approach here. My recommendation would be to use a Rockwell Automation PLC from the ControlLogix or the CompactLogix line for control, paired with an IPC that runs Linux and the Python application on top of it. There are many IPC vendors I’d recommend - Advantech, OnLogic, etc.

The Conclusion

There are always many ways to tackle an engineering problem. You can use PLCs and IPCs fairly interchangeably. However, you must understand where the challenges of doing so lie and what those devices were created for. In short, PLCs are much better suited for control, while IPCs are great for running support applications written in other programming languages. Multiple vendors offer combinations of the two under the same housing, but I’d recommend only adding process-critical apps here.