Industrial Automation Q&A: From Generalist to Specialist Without Regret [Career Strategy Episode]

How's it going, everyone? Welcome back to the next episode in which we're going to be answering some of your top questions as they relate to industrial automation in manufacturing. We have a lot of interesting viewpoints, a lot of questions, a lot of different comments to discuss. If you disagree with any of my takes, I do want you to leave me a comment and reach out if you have a different thought.

Always open to having a conversation. But without any further delay, let's jump into the first one

So the most popular post this week was made by Engineer K, and he says, "Home lab project interview worthy." And he uploaded a couple of images. So we have a factory IO image. We have some kind of an, a layout designed in a SCADA/HMI screen. We have a couple of different screens. We have lo- we have logic, which is written in CODESYS.

We have a lot of different alarms. This sort of looks like Ignition, but I could be wrong. And we have a couple of different screens, layouts. Again, it looks like some kind of a pallet storage operation. So we have a different warehousing space that can route to different locations from the looks of it.

And he says, "Hi, I have been working on this project for the past month and figured I'll share to see if it's worth mentioning or demonstrating at interviews. It is a virtualized material handling system with a PnP stacking pallets and four cranes loading and unloading said pallets programmed almost entirely in structured text using CODESYS.

I used Ignition for the visualization, exactly as I thought, controls and logging. Set up an architecture PC one Ethernet IP." So he talks about IP addresses and how he basically deployed some of these applications. He's talking about OPC UA protocols, how he's getting and passing data from the CODESYS instance and Ignition, I'm assuming.

He talks about the architecture tablet connected to PC one over Wi-Fi via my home router. Tablet web browser is used to-- as a client for Ignition perspective session. Users will log in and have different viewing experiences depending on role. They're auto and manual mode. Please let me know what information I need to provide or offer guidance as to what to add/remove to make this worthy.

Here are some screenshots and a video of the warehouse in action. Let's see if there is a video. I guess for some reason I'm seeing all of these as an image. But in any case- This is a very thorough demonstration. I personally have hired many engineers, technicians, and even interviewed engineering managers for a variety of different roles in our space, and I have not once seen this level of detail for a project.

So a couple of comments I would make is, obviously, this is something that adds the most to your interview when you're talking to the right person. So if you're interviewing with the initial phone screen with HR, it's probably going to be difficult to convey what you have built. They will simply not place enough value onto your system, and telling them that you've used, for example, structured text on CODESYS when they have ladder logic on Allen-Bradley or Siemens is not going to be very beneficial to your interview process.

That being said, once you have gotten past the initial screens and maybe even talking to some of the junior guys, sometimes engineers would do a pre-screen of candidates just to make sure that everything is okay. I do believe that this is something worth showcasing. Of course, if you only mention it in passing, it's very difficult to showcase the complexity of what you have achieved.

So if I were in the shoes of this person, during the interview, I would bring this up, but I would also be prepared to have loaded some of these systems on a small computer. I would pull up either a phone or a tablet. He mentioned that he probably ran this on some kind of an iPad You can bring a router with you if you need to make those connections, but I would demonstrate the application.

As I said, it is important to have context of the company that you're interviewing for. What I have found in our industry, at least, is that some individuals will make the connection that because you are proficient in CODESYS, you can easily reapply that knowledge onto, again, Allen Bradley, Siemens, Omron, Mitsubishi, or other PLCs.

And other individuals will simply overlook you because they don't believe that you have the experience on the platform that the factory currently uses. So again, I would do some research and I would be cognizant of the fact that the improvement that maybe that would be recommended is spend some time on implementing this in RSLogix 500, 5000, in TIA Portal.

I believe that if you're going for those type of companies, it will certainly add a lot of weight. The Ignition demonstration is phenomenal, right? So I understand what he has done with the database in terms of storing some of these SKUs. So I definitely recommend mentioning this because it not only demonstrates your OT knowledge, but also your capability of designing systems that cross the bridge into the IT space.

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

The next question, or I would say more so comment, comes from a post of a PLC 5 screenshot or photo of a panel. So what is interesting here is that this individual called Remote Substantial 978 writes before and after of a PLC 5 running a lumber sorter in a very old sawmill. So you have two screenshots, the before and then you have the after.

As you can see, he installed all these very nice wireway covers back into place. Of course, made sure that the wires were neatly placed inside of them. I do believe that there's maybe some cards that were added. I'm not sure. It seems that there's some slots missing, and even that the PLC is quite a bit smaller than what I'm seeing in the second screenshot.

So maybe they made some changes to the actual configuration of the PLC or something else. Maybe he took a different picture of a different panel, which to me, again, this seems to be way smaller than what we're seeing in the second screenshot. And I wanted to give some of my thoughts. So obviously, all he wrote on this post is clean up the panel after apparent years of neglect.

So my general thoughts, when you're going and are going to spend the time to basically revamp the panel of a very old system, it almost starts a question as to why you did not migrate this to a PLC that if failed, would be more beneficial and a lot cheaper for the end customer than simply cleaning up an old PLC 5.

And I'm not the one that is going to push upgrades on customers, but the reality is that Rockwell Automation or Allen Bradley, if you're looking at the line of PLCs, have discontinued the PLC 5s for many years and now actually decades. So what that generally means is that if this customer is or if they are to lose some of these I/O cards, for example, they're going to have to buy them on the aftermarket, meaning on eBay, on part auctions, or reach out to perhaps some distributors or integrators that still have them in stock.

That being said, they're going to be a lot more expensive than even if you were to buy Allen Bradley or Rockwell Automation parts brand new for a recent system. So for me, it doesn't make a whole lot of sense to clean up the panel and spend all of those engineering and labor hours to basically revamp what's currently in there if we're not going to go ahead and ensure that there is no obsolescence risk for this specific business.

And if we want to get Down into those details, what does it take to take out a PLC-5? Obviously, it depends a little bit on the system. Generally speaking, it is not extremely difficult to migrate. Some of the cards on the 110 VAC input or output sides are going to be a little bit more troublesome because the newer systems prefer 24 volts DC, but the cards are still available, so it's possible to get them.

The specialty modules, right? So if you had any high-speed counters, if you had any connections over Data Highway Plus, for example, if you had any remnants of different protocols like DeviceNet or ControlNet is a little bit trickier. But generally speaking, this migration is fairly straightforward for a skilled systems integrator or internal engineer from within this company.

So my general comment is that this is something I would expect to be migrated to a newer either CompactLogix or ControlLogix platform instead of being left on PLC-5.

The next question and perhaps comment is very interesting. So recently I started looking at CNC machines and naturally a couple of robotics. I personally don't spend as much time on robotics as I do with traditional control systems, SCADA and MES. So it was interesting for me to find out that is actually not that difficult to reverse engineer some of the motors that you would normally see, for example, in a Fanuc or KUKA or ABB application because they use very similar rectifiers or H-bridges to run those larger servos as you would find in smaller or consumer-grade electronics.

Of course, power engineering is a discipline of its own. So we have an interesting question from the user by the name of frangree7, and it says, "Rewiring a robotic arm from nineteen ninety-one." And it is just a couple of years after I was born, and so he's got a picture of what seems to be a controller or some kind of a converter of basically, again, to perhaps a stepper motor or servo motor of that arm.

And he says, "Hello, everybody. First time posting here. I'm helping out a family business where several years ago we acquired a three-axis secondhand robotic arm together with a die casting machine. We were mainly concerned that the die casting machine was working and never paid attention to the robotic arm.

And now we've decided to turn it on, but we realized that every wire was removed. I can only rely on some terminals who still are numbered since there's no wiring diagram. I was thinking that some components could be replaced, such as the transformer that seems to be used to reduce the voltage to power the control signals on the PLC or replace the relays with more compact models.

Since it also needs to run independently of the machine, I might have to do some re-engineering of the program. However, I was thinking this is a good opportunity to replace the PLC with a more modern one, used a screen-- use a screen for graphical interface on HMI. I could also replace the VFD, but I think just need to test them independently.

I'm fairly new to this area as I've only worked with software and simulations before. However, I worked with simple AC motors in high school and in the mechatronics degree. I can also read wiring diagrams, and I know about electricity and electronics. I just don't know the correct way to proceed. Should I simply wire where the numbers match as it was supposed to work initially, or would it be worth upgrading the hardware right away given the effort it might take?"

And there's a lot of questions and a lot of different disciplines that are involved in answering this type of a concern or request So if I was put in front of a customer that basically had a machine in here, now that he mentioned this, I can see a little bit better that some of the terminals you'll notice basically have a cutout.

So you'll see here there's just a cutout from the wire. So what-- whomever removed this machine or this robotic cell did basically stripped it all of all cabling. Usually this is done because some of the guys, again, I don't know who exactly did this job, wanted to probably sell it for its copper value, so they stripped it out of all cable.

Is it possible to match the labels? It looks like some of the labels are still okay, but for the most part, they are not extremely legible. So his first question is, should I just wire it as is and just land the wires where they need to be? That is not where I would start. So I would start by, first of all, figuring out all of the major parts that are part of the system.

So in this case, we have a PLC. I'm not even sure what model of a PLC this is. It looks like it is a SIMATIC, so it looks like it's some kind of an older maybe version of a Siemens PLC. I would then-- Obviously, a transformer should not be extremely complicated. It's probably going from three phase down to a hundred and ten.

And then we have this drive, which is looking incredible because it is all through hole components. As you can see here by the label, it's a SCW Eurodrive type of a system. So I would start by collecting the part numbers of the largest components. In this case, it's going to be your PLC, it's going to be your VFD, and whatever is driving the robot, of course, and the robot itself and some of the peripherals on that robot.

So he mentioned it's a three-axis robot, so I would start there. I would then look for manuals as well as OEMs, so the manufacturers of that equipment, and I would start figuring out, since he's already looking into the migration, what does that look like? Is it str-- is it easy enough to migrate, or is it going to require a lot of effort?

Now, looking at the PLC, again, having never seen this specific model before, my general gut feel is that it's going to be easier to purchase a newer model of a PLC. If it's a family business, you're probably wanting to integrate some lower cost type of systems it looks like it's all digital io anyway so should be relatively simple to figure out however before you do that you should be able to retrieve the program and again that could be based on some online references that could be making a phone call to the manufacturer and trying to understand what are some of the options but also some of the migration options and of course that goes as well for the vfd and if it's just a vfd it shouldn't be too complicated if it's more than that then it might be problematic but most important point here get the manuals first make sure that you back up the entire system make sure that you understand what is the status of some of these families of hardware and what is the migration path like i said a very worthwhile to call the manufacturer perhaps talk to a local distributor or integrator that might be able to if not do the work at least point you in the right direction of what it's going to take he's talking about being very new to this area having done a lot of software and simulations but having worked with ac motors in high school and having done a mechatronics degree so what i can tell you from personal experience is that obviously this is a family business but you need to figure out where is your time best spent so if you were to continue to work at your job or if you're working as a consultant perhaps on such a project this could be a huge time sink right this could take three months this could take six months if you're working on it part-time a couple of years how valuable is this equipment to the business and how valuable is your time so if you have purchased a robotic arm that has again in this text he says several years ago if it hasn't been running first of all maybe it's worth buying something maybe less old but in a functional state than to spend another several years and obviously a lot of labor a lot of expenses to try and revamp something that simply wasn't worth it up until now and probably could wait for quite a bit of time so my general recommendation is despite you thinking that you have the knowledge and experience these projects are going to take much longer than what you originally anticipate and believe me i like to tinker on electronics i like to tinker on different automation projects but sometimes if you have an actual business that depends or needs this equipment it may not be worth your time and money

The next question is very interesting because I wrestle with this myself. I currently have about twelve years basically of experience in the industrial automation and manufacturing sector. I have done engineering, maintenance, and other type of also leadership roles across the board for different verticals, and I still believe that there's so much to learn in our space.

So the question is brought by the user by the name of Objective Primary six nine seven. " Two years in automation, and I feel like the more I learn, the more I realize how little I know. Is being a polymath actually realistic in this field, or should I just specialize? So I've been lurking here for a while, finally decided to post because I honestly need some perspective from people who have been in the trenches.

Quick background, graduated, went straight in an automation engineer role in a manufacturing company. Been doing this for two years. My scope is wild. I cover utilities, process, and packaging side, so basically the int-integrality of the plant, maintenance-focused, but also help my manager with some OT cybersecurity stuff on the side.

And man, I love this field, but also stri-- slowly driving me insane. Here's the thing. You start the job. The lead engineer's "If you don't understand the process, you're not a real engineer." Okay, fair enough. You start reading about fluid mechanics, thermodynamics, heat transfer. Cool, cool. But then you realize you- your actual scope of work is like eight different careers duct taped together."

And this is a general meme in industrial automation and manufacturing. "So field instrumentation, PLC troubleshooting, advanced programming, PID tuning, control theory, electrical stuff, pneumatics, industrial networking." He lists a few protocols, "PROFINET, Modbus, Ethernet IP, et cetera, OT cybersecurity, and probably ten other things I'm forgetting right now.

Like every single one of those could be a full career on its own, and then every time I go deep on one thing, I realize there's a whole rabbit hole underneath it. It's exciting, don't get me wrong, but it also paralyzes you. What ends up happening is that hyper-focus a thing. Lately, I've been going hard on programming side, and it eats up all of my mental bandwidth.

Like generally, after work, I have nothing left. Can't study instrumentation, can't touch the networking stuff, nothing. And the guilt of not covering everything just adds to it. Then I stumbled onto the ISA, CCST, and CAP certification and looked at the body of knowledge, and honestly, who knows all of that deep level simultaneously?

Is that even a real human being, or is it just a myth? So I guess my questions are, one, is it realistic to expect automation engineer to be a true polymath across these domains, or is that just a fantasy that gets sold to juniors? Two, if specialization is the move, how do you people pick?" How do you go deep on programming SCADA or IT cybersecurity?

And I generally feel a bit lost and would appreciate honest takes from people who have been doing this five, 10, 20 years. Did you specialize? Do you regret it? Was a T-shaped approach actually achievable? Anyway, sorry for the long post. Need to get this off my chest. So I have a lot of thoughts on this, and I'm going to do my very best to structure them as best as I can.

I have not prepared to answer such a long series of questions, so let's tackle them one at a time. Is it possible to know all of these disciplines all at once across all the domains? I would say no. It is extremely difficult. I have experienced the exact same challenges at-- as he has described two years into my career, five years into my career, 10 years, and I'm still now learning a lot of different concepts, right?

So he talked about different certifications. He talked about cybersecurity. Speaking for myself, I'm always trying to learn. There's always gaps. I understand what I don't know more so than I understand what I actually know. And in a lot of conversations, you need to be honest with yourself as well as your colleagues and your management as to what you can take on and what you can push back on.

Meaning that if you're not an OT cybersecurity expert, right? And of course it's hard to say, but for me, if you've only been two years in automation, I would assume you have not set up a whole lot of new networks. So when you make comments, "I also help my manager with some OT cybersecurity stuff on the side," it diminishes your credibility, right?

So when I'm asked about different topics that I am not familiar with, I typically refrain from saying I dabble in that anyways, and I can-- probably I can-- I know more than the, Complete beginner, but at the same time, you don't want to portray yourself as someone that knows all of these disciplines, where in reality you're just doing that on the side.

And instead of being an OT cybersecurity professional, maybe you have configured a couple of ports on a switch maybe six months ago, right? So I would be very careful on that front. It is impossible to be an expert in all of these fields. I have, again, interviewed, as I've mentioned a little bit earlier, engineers, technicians, and the more items they will put as knowledgeable in on their resume, the more of a red flag it's going to be.

So generally speaking, even if we narrow this down to PLC programming, if you tell me that Rockwell, Siemens, Omron, CODESYS, that is a red flag. You can build an entire career of knowing a single one of those platforms for the next and for the past thirty years. And the knowledge of the platform, and again, the knowledge of any of these disciplines, is not just understanding that it exists and having done, once again, some simple project where you have touched or you have seen a PLC inside of your facility.

To me, the-- you need to demonstrate that you can connect to it, you can program it, you can deal with some of the faults, you're able to specify the system. And of course, this goes across the board when he's talking about field instrumentation, PLC troubleshooting and advanced programming, PID tuning and control theory, electrical stuff, VFDs, circuits and panels, pneumatics, industrial networking, right?

So each one of these is a discipline. Now, the second question, of course, is how do you pick one of these disciplines to stick with? I have always been of the opinion that what's worth to solve are the hardest problems within an organization. What I mean by that is if you're going to maybe list out these disciplines and ten other things that you could be doing in your day or in your job, let's say over the next six months to a couple of years, where do you believe you add the most value?

Is it in troubleshooting the systems? Is it building new programs from scratch? Is it PI-- tuning the PIDs, right? I'm not sure why you maybe need to retune the PIDs. Maybe there were some new systems coming in. Is it working with VFDs? Is it specifying pneumatics? Is it industrial networking? And it's possible that you dabble in different projects as your business executes them, but you need to think of yourself at the end of the day as much as the organization because you need to build your knowledge in a space that will be to an extent protected.

And I don't mean protected by the sense that, you're creating the illusion that you are needed within the company, but you're building a skill set that is a little bit more unique, is paid more than some of the other skill sets, and ultimately brings you joy and fulfillment over the long run.

So if we talk about field instrumentation, for example, this means usually specifying sensors, troubleshooting sensors, configuring sensors. To me, that is a very manual and I would say less stimulating exercise than, for example, advanced programming than OT cybersecurity. So when I start looking for different projects within the company, but also as a consultant or a contractor, I will typically stay away from areas that at least I have less interest in and more towards areas that I personally enjoy and see more value in.

I also, like I've mentioned, I pay attention to what is the hourly rate of an OT cybersecurity consultant over someone who comes in and, for example, troubleshoots the system, someone who's going to handle field instrumentation, someone who's going to work with VFDs, circuits, and design panels for example, in electrical CAD.

And it's not to diminish the work. The work needs to be done, but sometimes you can pass on the work to a different person that enjoys that a lot more than you do, and that is also a lot more focused and knowledgeable in that area than you are. Now, the last comment that I will make here is that You don't necessarily, if you are a jack of all trades to an extent within the space, you can also pursue the management route.

And depending of what your desires are, depending on which organization you are in, those careers can be completely separated, right? So I worked originally for Procter & Gamble earlier in my career, and you had a highly technical track, which meant that you still led teams. You were still a manager at some point.

You could get to the director level. You could get to the VP level, but you're still focused on technology versus you can go into project management and then you're overseeing a lot of the projects where you're going to have experts underneath you that understand each one of these areas. Now, if you have built a skill set that is sufficient to manage those individuals, it could also be highly valuable, but also understand that you will not be at the same level as someone who has spent 20 years or even 10 or 5 years only working in OT cybersecurity.

All right, so we have a very interesting next question. As all of you probably know, I run both Joltech as well as Solis PLC, and some of the most requested content that we've always had is PLC troubleshooting. And of course, everyone's trying to understand, should I be focused more on designing new systems or troubleshooting existing ones?

So here we have a question from the user by the name of Ranger-New-5346, and he says: At what point does PLC troubleshooting become more important than programming? Feels a lot of automation discussions focus on writing logic, but in real projects, the harder part often seems to be diagnosing issues once everything is connected and running live, especially with networking HMIs, drive sensors, and older systems all interacting together.

Curious if experienced people here spend more time programming new logic or troubleshooting existing systems day to day. And I obviously, again, I have a lot of opinions on the side. I think the short answer is it depends on the organization, it depends on the team, and it depends on the scope of work that you have.

Speaking for myself, so I began my career at Procter & Gamble within the engineering organization, and the goal of the engineering organization was always to bring enhancement to existing lines or bring in new equipment to the facility. So some of the largest projects or multi-million dollar projects that I have personally ran were basically bringing in new equipment into the facility.

So the scope, generally speaking, was always on, number one, making sure the-- sure that the design of that equipment was correct. It was programming new features into the production line, and then it was also deploying the line and then troubleshooting or helping operations get that line up to speed via a variety of different, again, troubleshooting, maintenance activities, and engineering work, right?

And so what I would describe that kind of role as is eighty percent was new system design and twenty percent was helping out, again, operations. It could also be calls where the technicians or the maintenance personnel and engineers could not figure it out. The engineering organization would then get either a ticket or just a request for help, in which case we would step in for troubleshooting activities.

So to answer the question, at what point does PLC troubleshooting become more important than programming, is that if you make the switch into maintenance. So maintenance typically sits within operations and is- extremely critical when it comes to making sure that everything runs as expected. So if you've been on the plant floor, I would assume in most indust-industries you have seen the metric called OEE or Overall Equipment Effectiveness, which basically boils down to we need to make sure that the lines run as efficiently as possible.

Of course, even the most advanced organizations are never going to hit one hundred percent, but everyone is trying to make as much product as possible inside of their automated facility. So it comes down to if you're part of a team that is running new projects or if you're part of the team that is going to handle maintenance first and foremost.

Of course, there's going to be some overlap. The engineering team is going to ask for feedback from the maintenance organization when they design and bring in new equipment, just like the maintenance team will ask for the engineering support, as I've mentioned a little bit earlier, when it comes to some of the larger outages.

So is it important to learn PLC troubleshooting? Is it more important to learn PLC programming? Again, the answer is it depends. I personally believe that without a decent foundation of just sitting down in a classroom, connecting to a PLC, being able to program at least the very basics, it becomes very difficult to just be put in a situation where you're trying to troubleshoot on the fly.

If you don't understand the basics of networks, if you don't understand the basics of PLCs versus HMIs if you don't understand different brands that you may be utilizing, such as Rockwell, Siemens, Omron, Mitsubishi, CODESYS, it becomes very difficult to just quote unquote, "start troubleshooting." So I believe that you almost always want to have a foundation in programming and writing logic, but also seeing how to navigate the different IDEs.

So the way you set up, for example, trends inside of TIA Portal is very different than if you're setting them up inside of Studio five thousand. So until you have spent a little bit of time just learning, it becomes difficult to troubleshoot by simply random action. And of course, you can get there. You can-- in the time of pressure, you can go and read different forums, you can figure it out, but it becomes extremely difficult.

So at what point PLC troubleshooting becomes more important? Again- It depends on the organization. So if you join as a technician or as an engineer within the automation department, chances are they will put you on smaller projects at first so you can get familiar with the equipment, so you can get familiar with the process.

And as you grow your body of knowledge, you will be asked to help out on different outages. And of course, depending on how you do, you might be given more responsibility. You might be given a little bit less. It depends on your management and of course the people you're working with. But I believe you will slowly build that, not necessarily dependence, but basically that skill set that allows you, that allows others to depend on your ability to troubleshoot more so than program new systems if that is not the requirement of your department.

Hopefully that answers the question. I don't believe there's an easy answer here. It will depend on you, what you're pushing for, what comfort level you build with the organization, and ultimately what kind of projects you get and push for internally.

All right, and so we do have a last question. I wanted to keep it to five, but it was just way too interesting to pass up. So this week we're going to be answering six questions, and if I can change my view to the subreddit, so this person by the name NoChoice9450 is asking, "What are the most important skills in order to be a PLC technician?

I know it's probably a broad question, varies depending on place, but to be specific, I am transitioning careers to hopefully be a PLC tech, control tech. I have a background in programming, so the PLC programming doesn't seem too difficult to me. However, the more hands-on portion such as wiring and hardware configuration seems to be more difficult. How proficient in all of this are you expected to be as a new PLC tech? I hope to finish my degree and move up to engineer level, but I just want to get my foot in the door. Also, I bought some hardware to get hands-on, but I realize now that I will probably need a lot more hardware, and it is adding up.

Would anyone recommend any online simulators?" So really good question, right? And so to give you a little bit of context, I have personally started my career as an engineer out of university. I've got my bachelor's in electrical engineering back in two thousand and thirteen, and immediately stepped into an engineering role.

That being said, I have hired, I have interviewed, I have talked to, and I have mentored countless technicians either that ended up doing PLC work or automation work in a general sense, that worked in engineering and maintenance. So I do have a bit of a perspective on this front. So number one, when you come into an interview, the first expectation that I at least have and have always had is you need to demonstrate safety practices with these electrical systems.

And what I mean by that is when you talk to someone in an interview or on the phone when it's an early screen, you need to understand that one of their concerns is that you will be in front of systems that can very easily harm you, harm other individuals around you, not only on the physical side that is very visible, but also on the electrical side that many people, in my experience outside of our world, take for granted.

So if I'm going to let you loose on the plant floor, obviously, usually at the beginning you will be paired with somebody else, but I need to make sure that you're not going to be going in- unauthorized spaces. You're not going to be touching any high voltage cables. You will be safe when working with transformers, MCCs.

And I'm not saying that you will immediately be put on those tasks, but you will be in an environment that is extremely dangerous to you and those around you. And if you demonstrate any behaviors that are unsafe during the interview or during a planned walkthrough, it illustrates to me that not only do you not care, but you also do not care about those around you.

And that's where I typically draw the line because I want to go back home safe, and it is very important that everyone is on the same page. We're going to respect the lockout/tagout best practices. We're going to respect PPE best practices, right? And I can give you an entire lecture on the organizational side of things, but at the end of the day, if you are not protecting yourself, it means that you're going to put my life at risk.

And I would say that is one of the most foundational requirements when it comes to just being inside of a facility, but even more so when it comes to working with electrical systems. In terms of actual skills again, there's a distinction between programming PLCs and probably troubleshooting existing systems.

And in most cases, when you're just getting started, you will be given smaller projects where you need to basically accomplish tasks on existing systems, whether that's making them better, troubleshooting certain outages. You will usually be given a set of work orders which you can work through, and it could be something as simple as go and clean out the panels, right?

If you're just the new guy, maybe you're just doing some routine maintenance on some of the panels. You're making sure that everything is okay. I would say that also when you mix PLC technician, usually you're going to touch some of the other areas of automation. A lot of it is gonna be with motors, conveyor systems, and Typically, I don't have high expectations if you're just getting started in the profession.

I think it's your general understanding of if you can at least explain different types of maybe VFDs, PLCs, right? So different components used in automation. If you can talk about some of the brands that the company has, I believe it is sufficient. If you can, of course, demonstrate that you have programmed PLCs and you can troubleshoot PLCs, in most companies, that is going to be a level above not just a starting PLC technician, right?

So a PLC technician or automation technician in most facilities is at the lowest level going to do a lot of the maintenance routine tasks just to understand the process, understand the business, understand the different systems. But you don't need to demonstrate any deep knowledge in PLCs, HMIs, or troubleshooting in a very broad sense.

If you do want to get some time with actual, I would say learning materials and hardware. So like I said, number one, I would just spend some time watching videos on general hardware that you will find in the industrial setting, right? So understand schematics of control panels, understand just the different wiring schemes of PLCs, VFDs.

You don't need to be an expert. You don't need to wire your own VFD through a contactor and a fuse block to spend a little bit of time watching some of the NEC videos, watching perhaps some AutoCAD videos, understand how to read different schematics. I think that is always beneficial. Once you start asking I bought some hardware to get my hands on, realize now I probably need a lot more hardware, and it's adding up."

So again, depending on your region, I would choose either Rockwell Automation Or Siemens, or if you're in Asia, it's going to be your Omron, Mitsubishi, or maybe if you're just passionate about CODESYS, for example, or Beckhoff and B&R, maybe choose one platform, purchase the lowest-end PLC that they offer.

And I say that a little bit cautiously because do not purchase some of the lowest-end PLCs that are going to use a different software. But look at the job postings, look at what you're looking to join in term of, in terms of vertical, right? So it could be oil and gas, it could be food and bev, it could be pharma.

Usually, they will list, "We want someone with experience with Rockwell Automation, Studio 5000. We want someone with Siemens, TIA Portal." Purchase the lowest-end PLC. I would argue, again, figure out a way on how to do it on the cheap. You can go on eBay, you can find some auction houses. Do not buy it directly from the manufacturer just for learning purposes.

Save that for the actual facilities that run multi-million, multi-billion dollar businesses. Once you're on the job, you will learn a lot more, but for now, save a little bit of of money. It is worth investing in purchasing the lower-end PLC and then finding a way to program it on, again, on your specific budget.

So if you do want to practice, like I said, purchase something on eBay, hook up to it via an Ethernet cable from your computer, get the software going. Master the basics first. I cannot stress this enough. A lot of individuals skip the XIC, XIO instructions thinking that I want to learn PID loops, I want to learn different networking protocols.

The reality of most ladder logic or even structured text and just normal programming is that it is state machine-based. So when you have a control system, most of the conditions are going to execute if this, do something, if this, do something, if this, do something. So a lot of it is just ladder logic basics when it comes to building those rungs, when it's executing the logical conditions.

A lot of it is logic gates. You can watch a video on this. In terms of simulators, again, I'm not a huge fan because it seems that simulators are not great at figuring this out so i said i would invest in a plc but there's definitely tools out there i see that the community is posting a lot of vibe coded applications where you could go and practice building your own motor starter for example i'm assuming you can get it to a point where you've built an entire application using some of those tools how well that's going to translate to the actual job of course is the it depends but i said it is really up to you so to summarize you don't need as many skills as you believe you need to become a plc technician or at least get your foot in the door you need to be safe you need to demonstrate some excitement for the profession you need to make sure that you come enthusiastic for your interview make sure that you talk about some of the interesting projects maybe you're working on in your degree maybe you're excited about demonstrate that you will be the person that can help some of the or solve some of the problems that they're currently experiencing