AI in Industrial Automation: Where It Actually Works and Where It Fails on the Plant Floor

How's it going, everyone? Vlad here, and today I wanted to talk about AI in the industrial automation setting. Now, I don't want this to be a high-level video. I know there's plenty of information out there for you to get started and to get a general sense around AI. I wanted to talk about my experiences specifically when it comes to industrial automation, building applications, deploying applications, troubleshooting in the field on the actual plant floor, and discuss the advantages in some situations where AI truly shines and the LLMs actually come through, and talk about some of the fallbacks or the disadvantages of using AI in certain situations.

I'm gonna be also sharing a couple of stories, again, in a general sense, of course, not revealing customer information, where AI truly helped solve specific problems. I'll be giving some tips and hints for engineers, systems architects that are working in these environments as to what might work and what may not work, and of course, how you should be preparing and probably utilizing AI in your specific workflow.

Which model, and why software engineers converge on one

So without any further delay, the first question that needs to be answered in almost all conversations around AI is which models are you actually using? And if you talk to a variety of different experts in this field, they're going to give you different answers, but you will find that software engineers and those that actually program systems will converge towards Claude Code.

And of course, as you experiment with the models, and I would encourage you to purchase And pay for either the subscriptions or the tokens, you will realize that Claude Code is fairly better than anything else out there. And very quickly, at least in my experience, I remember using ChatGPT in the early days, and I still have the basic subscription because I have some context, even on the personal side, that I don't want to lose.

Two workflows: a desktop context store and the phone in the field

But ultimately, I should be migrating everything over to Claude Code. But it truly shines when it comes to some of these more technical applications. The second question is which version or how are you using Claude Code? And I basically have two workflows. So on my home machine, I have VS Code built up in which I have a ton of different context, and this is anything from automation, but also my conversations, meeting logs, branding.

So it takes a wide range of information about the entire Joltech business and allows me to structure context the way I want. So the advantage there is the massive array of different context as well as different workflows that I can call upon for specific situations. And to give you an example, if I'm working on a very specific platform and I'm working on this specific application, I can go and execute a workflow that will only look at specific manuals and then create the best answer possible within that context.

Now, I also use Claude Desktop and Claude Mobile by that extension, which are the applications that you can download from Claude and basically run them either in the browser, you can run them on the desktop, or you can run them on your mobile phone. And where that truly shines is, number one, it has a little bit less context, so you can obviously load the manuals and you can give it the same type of information, but it's structured very differently than what I have set up in VS Code.

But conversely, it's really good in the field. So when you're troubleshooting, you don't always have your laptop with you, so you can take a picture with your phone. You can very easily load it into Claude Code. So it makes it much simpler, I would say, in those scenarios. But if you're looking to do something a bit more advanced, VS Code is the way to go. So when it comes to, LLMs, my preference is Claude Code. I still have a basic subscription to ChatGPT, but for all intents and purposes, it is somewhat irrelevant.

What the subscription actually costs

I have found and I have tested Copilot from Microsoft with, again, not the best results. Obviously, it gets the job done in certain settings. I do not know where I would fit a second model in terms of the workflow. So take that however you'd like. I would highly recommend that you purchase a subscription to Claude.

And again, on my side, I remember buying the $20 per month subscription, and I used to run out of tokens within two to three hours on a daily basis. So the way it works, if you're new to this, you pay the subscription, you're going to have a set amount of tokens. If you run out, they will replenish the next day.

The times vary, and again, this may have changed since I had used it. But basically at I would say in April or March of this year, so two thousand and twenty six, I started running out very quickly of the tokens. So I had to upgrade to the max plan, which is two hundred dollars per month. So take it with, again, if it makes sense for you to spend, I would highly recommend that you purchase the twenty dollar subscription.

Where it helps first: defining a vague problem

If you start seeing yourself utilizing AI more and more, upgrade to the next plan. So let's talk about the specifics as to where it truly shines. Again, this is based on my experience, based on my opinion. So when it comes to industrial automation programming, as you know, we typically take a lot of time to solve the problem before we start the implementation.

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

And the problem-- I would say the nature of the problem can vary. Sometimes you can be asked to troubleshoot PLC systems that have a very specific fault code. So you can simply take the fault code, give it to AI, and allow it to find what that fault code actually means for your specific system. Similarly, there are greater problems or more complex problems where you want to implement something on the motion side, on the safety side.

You want to create a data application probably within your PLC, and that is a little bit more intricate and requires a lot of thought, or at least it requires me a lot of thought to put something concrete together before I can start building out the logic, whether that's in structured text or ladder logic.

We'll come into that in just a moment. So number one, problem definition. In many instances, as the systems architect or a consultant, you will be given a very vague statement when it comes to the problem. You will be asked, "Well, we would like to do XYZ, and we believe that this is the best approach that would work for us."

So AI is really good at conducting research and giving you some other counterpoints when it comes to building out those systems. As I've said, I obviously have the experience, but in many cases I go to different industries I'm unfamiliar with. I go into environments where I might not have as much visibility as somebody else And so it's important for me to take the time and put that problem into the LLM and allow it to basically find some points where it may fail, where it's going to be important questions to ask the customer that's suggesting a specific solution so that we can go back and forth and come to a solution that actually makes sense.

So that is one area where it is very good. And of course, there is going to be some learning curve on the prompting side if you've never prompted before. You need to give it as much detail as possible without giving it too much detail to overwhelm the answer. But it is really good at, we have this specific problem, this is what we're thinking as the solution, what do you think in terms of potential failures of doing it that way?

And that can start really good conversations with the customer, start maybe going back and forth and refining that problem. When it comes to actual code implementation, it shines in a-- I find in a very different way. So I have found that if you simply give it a prompt, I would like to build system with XYZ features, it struggles quite a bit.

The palletizer example: decompose before you prompt

So you as the engineer or the systems architect or the consultant need to break that problem down into manageable chunks. So when it comes to actual PLC code, let's take an example of a palletizing system. So a palletizer that we all should hopefully understand takes some boxes on the infeed conveyor, then it's going to either utilize a robot or it's going to utilize some kind of a pusher system to place those boxes onto a pallet.

In a broader sense, that's all the palletizer accomplishes. But from a technical standpoint, a palletizer is multiple subsystems within that larger system. And the subsystems could be the infeed section, how the packages are managed coming into the palletizer. You have stop stations, you have photo eyes that will detect some of those boxes.

The second area is the pickup area. So the boxes need to be staged, sometimes rotated before they get picked up by if it's a robot, it's going to be an end of arm tool that's going to clamp the boxes and transfer them onto the pallet. That entire area has multiple applications. It has first and foremost the orientation of the boxes, right?

So that's the physical IO that's handling the layout. But the end of arm tool needs to obviously do some checks as well. There's going to be sensors usually when it's closed, when it's open, when it sees the boxes. So it also handles some logic. You also have some backend logic that's going to handle the recipe of the palletizer.

So for example, it's going to manage the layers of the pallet. It's also going to manage the different SKUs for that specific product, and it thus carries some expertise to build that logic out. So what I'm trying to go back to, if I were to summarize my previous point is that instead of telling AI, "I would like to build the entire palletizer," from which you will get some information, it may break it down to you into those subsystems.

What I have found most useful is you as the architect tell it which subsystems are going to be part of your system, and then you work on the implementation of those simpler or smaller applications that you then apply inside of your code and test. And once they are basically built separately, you connect all together.

So I have found, once again, just at a very high level, unless you give it all of the information for that palletizer, and I have not tested this personally, but if you give it the mechanical designs, if you give it the electrical designs, if you don't have all of that, it will struggle to solve your specific problem.

A real request: an hourly productivity screen

And that is one example, like I said, of an area I have found really good use cases when it comes to, for example, data applications. So one of the requests I had last week was to create a simple screen that would allow us to track the productivity of a given asset. And as you can imagine, you want to do that on an hourly basis, and you want to give different KPIs to that team.

So of course, it is unable to just one-shot that application. If you simply give it, "This is what we're looking for. I want you to build this in ladder logic or structured text," there's going to be quite a few mistakes. What you need to do is break that down. We would like to aggregate this specific data in these registers, and that is where it truly shines.

Could I could you have done it without AI? Absolutely. Absolutely. So you can build a lot of these applications and solutions without AI. But in my experience, this workflow significantly accelerates your ability to build out these applications for the customers. And ultimately, this is what we're all looking for, to be as productive as we can, to be able to address different issues, and to provide value for the manufacturing environment

Carrying context across Rockwell, Siemens, Omron and Opto 22

Let me give you another example. The majority of my experience has been at very large enterprise. I'm now starting to do a lot of work with small and medium-sized manufacturers, and therefore, the platforms are fairly different. So my experience has been on Rockwell, on Siemens, on Omron, on Mitsubishi, on PLCnext, on Opto 22.

It is impossible for me to remember and memorize every single piece of context of those platforms. So as you encounter the larger platforms and then multiple months later you transition to another platform, it becomes very difficult for, I would say, the human brain in general, but at least for myself, to keep all of that context.

And this is where AI truly shines. If you ask it for implementations of functions that you have done so in the past and you understand very well, it is very good at creating the scaffolding or the initial code needed for that specific program. And we all know that the general PLC programming should be the same across platforms, but there's always different little nuances.

In certain platforms, you cannot use bitwise operations the same way. You cannot utilize DINTs or BOOLS in the similar fashion. There is going to be some differences between how structured text is written and even the visual side, the way you link some of the rungs can be difficult or different. And so you can prompt your way to building out entire applications.

Now, of course, in our space, there has been a couple of releases where there's an embedded or an MCP provided for you or an embedded AI. I have not tested those to be completely honest with you. I've had some conversations on the very positive side when it comes to Siemens. I know that Rockwell is releasing something as well.

I have found or I have been very successful When it comes to using just Cloud Code and then basically giving it, the prompts that I needed and building out the logic either in ladder logic or structured text, depending on the application, based on its recommendations. Where do the challenges start?

Where it breaks: less common platforms and firmware revisions

And this is, again, this is going back to some of my comments that I've made, uh, not too long ago, but it does struggle, number one, with platforms that are less utilized, right? So we all know that the biggest platforms in our space are going to be Rockwell and Siemens, and there's a lot more documentation when it comes to those platforms.

There's a lot more tutorials, there's a lot more videos. So I'm assuming that the models have been trained on how code is done within those platforms. So if you're building applications in something outside of those two, there will be issues. And those issues can range from it's going to give you, for example, the structure of the rung or the text that you need to build, and it is simply not going to work in your specific IDE to it being completely wrong on some of the instructions that it wants you to use that are not applicable to your IDE.

There are further compounded issues when it comes to working with different firmware. And again, if you've been in the Rockwell ecosystem, you know that over the years, quite a few changes have been made between RSLogix 5, RSLogix 500, RSLogix 5000 and Studio 5000. And although the changes are not major, you sometimes need to feed the context back to AI, and it will still tell you that you can use this specific instruction set when it has been deprecated back in RSLogix 500 era.

And of course, a lot of it is applicable, and if you know enough of the said platform and if you're a good enough engineer, you will be able to change some of those nuances and prompt your way to the right revision. But you need to be extremely careful. If you don't have the experience, if you don't have the knowledge, it is very easy to make mistakes.

And of course, if you're running with, working systems, it becomes incredibly dangerous, I would say, depending on what it is that you're doing, if you're fully trusting AI. Some of the other issues that I've encountered is that AI is a lot better on the structured text side, and this was to be expected.

Why structured text works better than ladder logic

So I'm assuming the way the models are working under the hood is that they've ingested, first and foremost, the context from our industry, of which there is substantially less than some of the other software best practices. And I believe that there's going to be a lot of information pooled on how to build these applications when it comes to assembly, when it comes to C.

So languages outside of our industry where some of these best practices are applicable, and it is simply trying to identify some of those patterns and give the best answers when you do issue a prompt on the industrial automation side. When it comes to ladder logic, there's a lot less examples. So if you surf the web, you can generally find information about a specific instruction, but you will very rarely find advanced examples on how to build, for example, a totalizer.

So you have the instruction that is the totalizer, but how to apply that in a pharma setting, there's no one that has generally shared that information. The same goes for sequencers. So if you're looking to work with sequencers, someone will explain the instruction, and I do have some videos on it on Solis PLC, but very rarely will you find a resource that goes into depth when it comes to the sequencer implementation in the real setting Now let's talk about not only developing applications, but also troubleshooting.

Troubleshooting: turning a vague complaint into a direction

So I know that a lot of plant engineers or corporate engineers, those that come into plants are not only building new applications, they're trying to understand what is wrong with the current ones. They're trying to troubleshoot. They're trying to make equipment better. And of course, again, just as a reminder, we're not talking about continuous improvement and CI initiatives.

We are focused on industrial automation in this specific conversation because I want to restrict ourselves to building applications and solving technical problems. AI can also be applied to other initiatives, so that is going to be a little bit of an aside. So going back to troubleshooting, where have I found really good advantages?

Number one, when you show up to be given a very vague piece of information, once again, we've all been there. The operator or the supervisor or maybe the maintenance manager will tell you, "We had an issue with this line because of XYZ." And how well-defined that XYZ is of course the problem. Usually, the problem statement is going to be relatively vague, and it is up to you to find the context.

Now, obviously, the first step is talking to the actual people, understand what the problem is, where are they stuck, and what have they tried. Number two, once you have those pieces of information, you can very easily feed that into AI, into the LLM of your choosing and get some additional context as to what you might need to troubleshoot this problem.

And this is particularly useful, especially for those that haven't been on the plant floor long enough and may not know what to look out for when it comes to troubleshooting these systems. So for example, if you look at an HMI system and you have some obscure fault code Well, the next step for you is to look on the PLC side, understand the fault code.

And so you can feed the fault code number into AI, and it will generally, right, I say generally because there have been issues that I have witnessed, it will give you an answer as to what that fault code means. So it does save a lot of time when it comes to troubleshooting, and it will tell you, for example, I have this specific PLC, maybe you've never connected with that system before, that's sending this data to Ignition.

It has faulted on error code 3781. If you just feed it the error code, it may not know, it may not have the context, but you can tell it, "I have this specific PLC. I have this specific instance of Ignition in s- in, in that specific example. I have this gateway that's running this application. Can you build me out the context which may have caused this specific issue?"

And that is where it becomes extremely interesting as, again, if you haven't seen that specific system, it will provide you with some context, but it will also give you some steps on where you should look. Are those steps always 100% accurate? No. Right? So it will make mistakes, and it is up to you as the competent a consultant or systems architect to figure out where the issues are.

But it gives you some things to think about immediately, which might lead you very quickly to the solution. So what have I witnessed when it comes to the drawbacks of troubleshooting? So I have done, uh, multiple exercises, anything from troubleshooting hardware to troubleshooting software systems to troubleshooting, as I've explained, these different chains of data systems for manufacturers.

So when it comes to just getting the part number of the hardware and then getting context on the fault code, it is relatively accurate, right? And when I say relatively accurate, and I, I would say it's pretty good. When it does have issues, right, and what it struggles with is the differences and nuances in some of the part numbers.

The PowerFlex problem: fault codes differ across drive families

So again, I work with a lot of Rockwell systems, and what you will know is that the PowerFlex line is going to have a lot of different drives. You have the older PowerFlex 4 series, you have the 40 series. Now you have the five twenty-five, five twenty-three, five twenty-seven. You have the safe torque off or the hoist series of PowerFlex.

So if you simply tell it, "I have a PowerFlex fault that is E, uh, one oh six," for example, it will struggle because the fault definition is different between the drives of families. And this is where you can get into a lot of trouble, because if you don't go back to the actual manual, you might be giving it a fault, and it assumes you have a completely different system, and with full confidence will tell you, "This is what you need to do.

These are the next steps," where in reality, your specific family, that fault number is a completely different issue. So I would be very careful about that. Obviously, we also have the challenge of firmware. So if your drive or PLC or any other hardware is on a different firmware revision, usually there's gonna be some different manuals, different documentation.

The IDE is going to be a little bit different. So make sure to pay very close attention and provide LLMs as much context as possible. For example, I have a PowerFlex five twenty-five series, for example, firmware six. With this specific part number, I'm working with this drive. Again, there's going to be different drives, but usually you can see it on the on the side, right?

So I have a PowerFlex series drive here. You can provide it with either a picture of this entire faceplate, or you can just give it the part number. Usually it's going to be fairly good. So again, just go through that learning process and understand where it's better and where it is worse. The next item is troubleshooting applications, and this is absolutely incredible.

Reading code you have never seen, in a language you do not speak

I could not have had better results on this front that I've had over the last multiple months when it comes to coming into environments where I don't understand the process, I don't understand their code, and there's usually a very steep learning curve into troubleshooting any piece of equipment.

So the general workflow that I have adopted is once you go online with the system, obviously if there is a fault, it is, I would say, a lot easier to try and understand what is going on. In many cases, in manufacturing environments, as I've mentioned a little bit earlier, you will be given a vague statement.

So for example, we have a scenario where the conveyor does not necessarily start. We expect it to start, but for some reason we don't understand why it is failing to start in these specific sets of conditions. And you, as the systems architect or the consultant, need to go online with the controller, and you need to find the reason why.

And in many instances, some other group has written that code. You have no access to that group, so you cannot just pick up the phone, make the call and ask your questions, what you do have is the implementation for that system. So what you will normally do is you would spend a lot of time trying to understand the code, go in maybe routine by routine, rung by rung to try and find the logic.

These days, you can simply take the screenshot of the routines, you can put it inside of an LLM, and it can analyze where the logic is likely for that specific problem. So you give it the context of the problem, you give it the context of the logic, and it will very quickly point you in the right direction.

This also applies-- what I found very interestingly is that a lot of equipment that I have worked on is going to come from overseas, therefore, all the comments are in German or Italian, and therefore, LLMs are exceptionally good at, at picking up that context. And if you tell it, usually it doesn't always do it by default, it can even translate the rungs and the comments preemptively for you as you're searching for that problem.

Why you are still the last line of defence

The next step is, of course, solving the problem, right? Not just identifying the rungs, but you need to provide some implementation. So as you work on solving the problem, it will give you quite a few steps into the right direction. And I want to say, be careful, right? If you are working on a live system, you're working with a customer that's expecting the system to run, you need to still be the last line of defense, and you need to make sure that the solution that the AI is giving you is indeed accurate.

Remember that in our environments, you can cause a lot of damage not only to the equipment, but to the people working on said equipment. So you need to be very careful in simply giving it all the context, allowing it to create, let's say, five rungs, and then copy-pasting them inside of the PLC without any further checks.

You need to be very careful. It makes mistakes. Some of the smaller mistakes are going to be just registers. But in some instances, it will be plainly wrong, and it will tell you with full confidence that this is the solution. Now, of course, like I said, it's not entirely, i-i-it's not to say that it's not useful.

It is incredibly useful at solving the problems. You just need to prompt, re-prompt, re-prompt, and re-prompt again to get to the result that you're looking for, and of course, test the logic that you have created using AI To summarize all of this, I believe that we live in an unprecedented opportunity where we are driving efficiency on the plant floor from the industrial automation side at an incredible pace.

The learning curve nobody wants to pay

I think that if you're not using Claude Code or any other LLM, again, maybe you prefer some of the other ones, that's perfectly fine. I would highly recommend that you invest the time and the effort to utilize them in some of your initiatives. I don't have anything to gain. I think that this is something that provides value in all sorts of different areas of not only industrial automation, I have mentioned continuous improvement, quality control, so on and so forth, but it provides opportunities and value in very different ways.

So I would want you to try out the basic subscription to any one of the models, see if it works out for you. But also keep in mind that there is a learning curve. Do not get discouraged by simply giving it a loose prompt and not getting the answer that you would like. Make sure that you go through, you re-prompt.

And I'm not talking about prompt engineering, right? So that's been a bit of a cliché. You need to be a prompt engineer, and you need a PhD in prompting. No, it's just give it more context and then see what kind of an answer you get. Give it an image, give it a text prompt, give it the manual, and see what kind of results you get by using that.

Understand that you will probably spend more time upfront to then become more efficient, but without that initial learning curve, you will never have those, quote-unquote, gains when it comes to productivity. In any case, I'm curious to hear about other people's examples and maybe use cases and workflows, or if you have any questions for myself, if you would like to discuss, if you'd like to see the actual workflow that I have used in Claude Code, don't hesitate to reach out.

Always happy to help and have a conversation around industrial automation and manufacturing.