AOIs and UDTs: When to Use Them, When to Avoid Them, and When They Become a Monstrosity [Q&A]

How's it going everyone, Vlad here and welcome to the next episode in which we continue to discuss some of the most upvoted topics as well as comments in our space which is industrial automation and manufacturing of course. If you have any questions, if you have any asks, if you have any requests on different formats on different things you would like to hear me speak about, whether that's about our industry very specifically, whether that's about career project management, the work that I have done, some of the examples of projects, don't hesitate to leave me a comment either in the YouTube comments section or of course reach out to me either via email or on LinkedIn.

I'm fairly responsive so you shouldn't have a whole lot of trouble getting ahead of me.

A home PLC training rig, and what to add next

That being said, let's dive into this week's question, and the first one comes from the username "coolcurd" and they say "home training rig" so we have a couple of PLCs, HMIs, we'll look at that in just a moment. Any ideas on what to add next? I was thinking about some push buttons but feel free to suggest some ideas. So if we, obviously if we click on the image we can zoom in to some extent, it's not that easy to see but I will very quickly enumerate some of the devices. So we have a power supply on the top left side, we have a, I believe that this is not a switch which immediately I for some reason thought it's an 8 port switch.

We do have some terminal blocks, we have an HMI in the top right hand side, we have the Siemens S7 1200 series PLC so I have shown the G2 series a couple of times. This is the older variation of the same PLC. We have a few contactors that are not wired in in the center of this paddle. We have a variable frequency drive, we have the attached motor to that VFD. We then have the actual switch, this is from what I can tell again without having the actual part number, this is an unmanaged switch.

We have a number of disconnects and of course we have a proper panel disconnect on the bottom right hand side. We also have the same panel when it is fully powered on without any light I guess shining on it and like I said we've already read the comments. So a couple of thoughts so I have built, you have seen some of my older videos on the other side of the office where I have a full electrical basically panel behind me. In this instance I only have a select few couple of pieces of hardware but I do have a couple of comments.

So number one obviously this panel is very Siemens heavy so if you're going to go in the field chances are you will encounter other devices even if you are working in a fully Siemens environment. Most of the time the end user will have at least some other devices. So I would consider learning some other platforms but also working on integrating perhaps using the Siemens PLC as the master and getting some of that data out of the other PLC could be via Modbus, it could be via PROFINET, it could be some protocol conversions.

I think that is always a very good skill set to have as like I've mentioned you will encounter multiple platforms on the plant floor.

Managed switches, Stratix and Moxa on a learning bench

The next item is networking. So networking has been growing quite a bit and as you can see here I have a Moxa managed switch with which I have been playing for a couple of weeks now just testing out the different features making sure that I can configure the switch but a lot of my experience still comes on the Stratix platform. So behind me you can see the Stratix 5700 series switch. There's of course now the new 58 series switch and there's also some variations. There's the 5200 switches so you can go through the documentation and understand the switch, the features so on and so forth.

I would assume that if you're working in the Siemens side you can purchase a SCALANCE switch that could be of managed variety and then understand how you can make the link between some of these devices. So based on the wiring as an example I see that the VFD is connected via an analog signal and obviously I don't know the exact wires maybe it's just a digital start and stop but it is I'm assuming possible to wire in the analog signal conversely should be possible to program it via PROFINET and have it on the same network as the HMI as well as the PLC and at that point you can also play around with a managed switch.

To the same point so I've showcased this already on the channel I have recently been to a site in which there was a number of these network address translation cards which basically allowed them to segment the OT network on a machine to machine basis. So I'm not going to go into the entire theory I have a couple of videos on network address translation already as well as a full course on OT networking fundamentals on Joltek. So I would highly recommend to purchase something that can allow you to work with networks.

Safety circuits you troubleshoot but never design

The next item of course safety circuits and I'm not a huge fan of home brewed safety circuits but I do believe that if you spend enough time in the field you will necessarily need to troubleshoot safety circuit you will not always necessarily design them first hand but you still need to be able to understand dual channel safety. You need to understand muting, you need to understand how to configure safety relays but also safety PLCs in some cases. So what I would also add to the specific build is either a safety PLC, a safety relay or a form of again way to work on some of those safety applications.

Build an IPC or a spare PC to run Ignition and Node-RED

The next step and I'm going to keep this list a little bit short because I know that's already quite a few suggestions is I would start building a computer as a server if you will. So a lot of times in industrial applications nowadays and I have this also on the side here you will start seeing IPCs or industrial PCs which are basically running different software that supplements the control system and that could be your SCADA, that could be your MES. It could have some features and typically maybe links towards an ERP but usually the edge you're not going to see fully fledged ERPs at the plant level.

And so in terms of hardware what that really represents is I would maybe purchase IPC but honestly to save on the cost I would put up a dedicated computer that would be able to run for example ignition. It would be able to run Node-RED. It would be able to run on the Siemens side, IIH, the Industrial Information Hub, which then allows you to deploy and test certain applications, the of course authentications and configurations of which you can download from the Siemens website to augment what you have built again within the control system.

The AOI love hate meme from r/PLC

The next question and slash comment is perhaps one of the most controversial, I would say discussions and our topics in our industry for a variety of different reasons. So we're going to take some time to unpack this comment for those who are maybe not familiar with the concept of AOIs. And so this question slash comment comes from the username kick that poo FactoryTalk but no one listened. My love hate relationship with AOIs and this is a meme which says, excuse me whoever is using AOIs, I think you need to learn how to code.

And then the second image is saying, oh man, I can see this AOI I wrote in so many places. And this is a very common dilemma. So I believe again, as you start working in the industrial automation space and you start programming PLCs, especially so AOIs are a generalized term at this point, but they are really applicable in the Rockwell ecosystem. So if you work with RSLogix 5000 or Studio 5000, you have most likely encountered the feature of AOIs and I'm not going to go into the technical details. Again, I have tutorials and explanations on SolisPLC.

I post regularly about AOIs on LinkedIn. But with that in mind, as you start your career in the industrial automation space, you very quickly start encountering AOIs that are way beyond what you would see yourself creating. And thus you become very intimidated by the, I would say, and also it's not to say that they're necessarily simple. I'm not implying that there are ways to over complicate AOIs. You can nest AOIs, you can create a just, I would say, a ton of AOIs unnecessarily and you can very easily make it so that it is very complex for anyone to troubleshoot.

But this is not unique to the industrial space. AOIs are basically functions, if you will, custom functions that you write within the industrial environments. The reason why they're a little bit complex is just because of the interface. So for those of us that studied, for example, C, C++ or Python or Java in computer programming in university, it is very unusual to go to those structures written in ladder logic or function blocks. And it's also how you navigate them inside of the actual IDEs.

Why an AOI is syntactic sugar

So again, they are nothing but syntactic sugar, which basically means they are a wrapper that doesn't necessarily exist. But once you implement the AOIs, they create this, I would say, confusion mystery, depending on who has implemented them.

When an AOI and UDT pair earns its place

Now, as you progress in your career, and this is what the meme is basically saying, you start realizing that there are very genuine use cases for AOIs. And this is, again, there is no hard rule as to when you should use them or when you should avoid using them. But if you have, for example, a pump or a tank or a valve for which you need to write a specific function, and then you have multiple instances of that specific object, well, it is easier to create an AOI and a UDT.

So UDTs represent the data, AOIs represent the function or the actual execution of code. And so as you pair AOIs with UDTs, you can make your programs a lot more manageable in chunks. And this unlocks a lot of different features, again, that stem out of traditional computer science or software engineering principles. If you read books like Clean Architecture, you will very quickly realize that this is how code has been written for multiple decades. And the reason why it is called computer science is that because there has been a lot of time invested by very smart individuals into understanding how do we structure code better for a variety of different reasons.

And that's why they created certain, again, I would say features in software that are now slowly trickling into the industrial automation space, but are sometimes clunky depending on the IDE, depending on the software, right? It's going to be a little bit different for, for example, in CODESYS, it's going to be a little bit different for TwinCAT because those languages are software based as opposed to primarily catering towards ladder logic, function blocks, so on and so forth. So again, the joke here is that as you progress in your career, you start realizing, hey, I'm going to be using AOIs everywhere.

I'm going to be setting up UDTs, I'm going to be setting up AOIs, and all of us go through this period of excitement where basically you start creating code that is so tightly coupled to AOIs that then you start also witnessing challenges with utilizing too many AOIs.

The AOI bell curve across a career

And so ultimately, and again, there's, there's this meme, which basically contrasts what happens at the beginning of your career, what happens at the end of your career, but then also what happens in the middle. And it's a bell curve for all intents and purposes. And I would say that at the beginning of your career, you realize you are afraid of AOIs, you don't want to see AOIs in the middle of your career, you're seeing AOIs as this magic element and towards the end, right? Like as you become more and more proficient in writing software, you realize that you need to be very careful in using AOIs, because it is very easy to trip over even your own code as you start implementing.

So I certainly have a lot of war stories when it comes to AOIs and UDTs and building software and projects, I have been paid to basically rewrite people's bad code and including AOIs in some instances, including heavily nested AOIs. And so, as I said, I have a lot of experience, but also a lot of opinions when it comes to how they should be used. I would say, in a general sense, as a rule of thumb, you want to avoid using AOIs and UDTs as much as possible until there comes a point where you're replicating your code so much and you're making changes to that code so much that it simply becomes unmanageable for you to go and change every single iteration of that code.

Therefore, you can then create an AOI and a UDT pair. Again, obviously, if it's handling data or not handling data is outside of the conversation, but ultimately, you create the AOI to facilitate that task. But you need to be very careful in how you manage that AOI,

Tank version 1.3, 1.4, 2.7: when it stops being an AOI

A lot of times, what I have seen in the field is that you're going to have an AOI that says tank version 1.3, and then you have tank version 1.4, tank version 2.7, tank version 2.8. And in that instance, it's not really an AOI. At that point, it has become this monstrosity of different versions, and it's not really serving the main purpose of what it was intended to do. So it is very easy to basically go overboard with AOIs. So as you scale your software, be very careful.

Nesting AOIs, and why no test pipeline catches it

Nesting AOIs, again, this is one of my pet peeves. There are reasons to call a function from within a function. But once again, you need to be careful because once the internal function changes, it's very easy to break your code. So unlike the traditional software where you have various tools on the DevOps side that can run iterative tests and make sure that everything compiles correctly, in the industrial space, things are not as easy. So it's very easy to make a change that will break the function of something else if it's not properly implemented, if it's not properly linked.

And if you do not perform any manual tests, because again, performing automated tests thus far has been very challenging. Now, there might be some LLMs now, and there's a few power users, I would say, that are testing these features. But for now, at least, I would be very careful when nesting AOIs, when creating dependencies between AOIs. So just be very cautious and careful as you're implementing.

Converting a 60 year old pipe bender from relays

All right, so we've got a next question, which is very interesting and related to reverse engineering an older system based on schematics. And so this comes from the username LordBroccoli68, and they say, "Can I use schematics like this to exchange the old relay controls to a PLC?" And we have two pages, we'll see this in just a moment. And they also say, "We have roughly a 60 year old pipe bending machine, it's seriously powerful, able to bend 80 millimeter diameter tube with a 10 millimeter wall, and it comes with a huge amount of tooling, so replacing it isn't an option for us.

The problem is that the original control components are wearing out and can't be replaced anymore. We'd like to swap out the relay control for a PLC, I have the full wiring diagrams and the original manuals, which cover almost everything about the machine. My question, can I use relay schematics as a basis and more or less translate them into ladder logic, or is it better to write the PLC program from scratch based on how the machine is supposed to operate?" And I certainly have a ton of opinions on this front, I have reversed engineered a variety of equipment in a number of projects, so if you click on this, obviously we can't see the entire page, but we can zoom in a little bit, we can tell that there's a selector switch of some kind.

What is a little bit, I would say, frustrating in this case is, of course, we don't necessarily have the labels, so we have different switches which have numbers, so 6301, 02345, all the way to 8, that probably toggle different features of these components, and I would assume that this is not the only page, so we have two pages as an example, but there's basically some solenoids that will fire, there's different examples on the positions of those solenoids, so what I would assume is, again, this is a fairly intricate machine, but when I say intricate, it's within reason, and as far as if you have all the schematics and all the information available, and not only at the time I would say of the machine, but also what is currently in place, because a lot of things may have changed and have been undocumented based on the current state, so sometimes what I have found in my experience is that it becomes difficult to an extent prohibitive to work with the schematics that are in the panel, not knowing what has been changed.

The SIMATIC 505, from Texas Instruments to CTI

And so going back to the actual question, and I bring this PLC into frame, just as an example, this is a SIMATIC 505, for those that don't know the history of some of these components, this used to be a Texas Instruments PLC that was then purchased by Siemens and was discontinued, if I'm not mistaken, in the 1990s. And although you can still see a lot of these PLCs in production, a different third-party company called CTI basically took over of the manufacturing of that hardware. So where I'm going with this is that I have had multiple projects basically receiving the drawing, and in most instances not even getting the software of the actual machine, but having to reverse engineer everything from A to Z and move it over to a newer platform, right.

So this specific PLC came out of a case packer that was no longer functioning on the electrical side, basically the PLC had failed, and we swapped it out to a CompactLogix Rockwell Series PLC. Now going back to the question that the user had is, should I start with the schematic? Should I start with just a functional spec, if you will, or basically a description of how the machine should work? So the schematic should provide a ton of detail as to how the machine works, and I would certainly not discount it.

I would spend the time necessarily, and these days I would probably use LLMs and I would give this to Claude Code or perhaps a ChatGPT or OpenAI model, and have it analyze everything and extract all the valuable information. But I would absolutely use that as the starting point.

Why you still talk to the operators

Now I would also supplement that, right. So even in my project when I did the conversion, like I have mentioned, the schematic had not captured everything from the changes side made to that machine over the years. So I needed to go and speak with the operators to understand how they operated the machine. This also allowed us and basically allowed the end user to fine tune some of those processes, right. So with all their equipment, you may have made some assumptions based on the limitation of the hardware at the time as to what needed to be done.

So in that instance, that machine was on a single camshaft and it used basically mechanical positions to actuate certain components. Well with a modern PLC, you can either time a lot of those functions or sequence them based on a sequencer. So we've made some modification as a result of having the conversation with the operators as to what they needed. So to answer the question, I would say more directly, drawings are incredibly important. I would start with implementing that logic, but knowing that once I get to the actual field. So once I put the software into the machine, put the hardware in the machine, you should be doing some fine tuning based on how it operates.

Now again, I have witnessed tremendous equipment that has lasted many, many decades.

A used washer and dryer, and the schematic in the lid

And one even personal anecdote that I have on my side. So when I first relocated to work for Procter & Gamble in Maine, I remember purchasing an older basically used washer and dryer set at the time. I had just completed my degree. So obviously the funds were tight and I wanted to spend a little bit less than on a newer set. So I set in mind that older set had a set of schematics inside of the panel. So if you ever used a washer or dryer set, you'll see that there's like a panel and there's the actual cover.

And so what happened was the cover sensor, which prevents it from starting when the lid is open for safety reasons. So if you have somebody or like an animal that falls in, obviously it would not function and it's a physical latch. So you close the lid, there's a latch that holds it in place and allows the basically washer to function. So I found the schematic and I remember bypassing the sensor at the same time as I had ordered on eBay for replacement. But long story short, it was very easy to understand by reading the schematic, the functionality of the washer.

And I even remember the funny thing was that we sold the washer like three years later after we moved out of that house for more money than we had originally purchased it with the replacement sensor with the schematic. So long story short, a lot of this equipment is very well built. And if it was maintained correctly, should last many, many more decades. Therefore I would start with the schematic. I would move this over to a modern platform. Again, depending on the region, of course, there's the high end or more expensive options like the Rockwells or the Siemens and there's going to be budget friendly options.

And that's going to be anything from like a PLCnext to Opto 22 to perhaps an Omron or Mitsubishi PLC. Again, there's a lot of different options on where this could go.

A 5069 IF8 card and a backplane that sees one slot

All right, next we have a technical question, which comes from the username 300FEDO 300FEDO and they say, "Some help and guidance would be appreciated, thanks." So we have a picture of a CompactLogix Series Rockwell PLC, we'll take a look at that in just a moment. They say, "Friday I installed a brand new IF8 card. On the setup, I opened ControlFLASH Plus to update the firmware. On the card as I was instructed when confirmed my path and opened the backplane, I only saw slot 4 recognized in the backplane. It was weird because every single card after slot 1 had power except that one.

Slot 1 wouldn't turn on at all. It was solid pitch black green LEDs flashing no project had been downloaded to the processor. I verified for voltage on my MOD and SA terminal blocks and we are all good till there. I opened RSLinx to see if maybe I would see any faults in the backplane but nothing and I still only saw slot 4 recognized and the backplane would slot 2 to 10 flashing. I went ahead and verified that slot 1 was seated correctly and it was. Would it be the device issue on slot 1 that is currently causing the rest of the cards not being picked up by the backplane?

I pulled slot 1 off the processor and it didn't see any damaged pins on the card on processor as well. Any troubleshooting suggestions would be appreciated, thanks you all. So we have a couple of images. We have the PLC. We have a screenshot of FactoryTalk Linx network browser which is the new interface and we have the backplane of the 5069 PLC. We have that this is a revision one. So a couple of things that I would start with. So number 1, let's see here, IF8, I believe it's the analog card.

Let's see if we can get that into spot. So there we go. So this is the IF8 which has a light. So to me that would indicate that the card is fine. We have the CPU with the green lights. That is good as well.

Flash the controller first, not the analog module

So the first thing that I would start with. So instead of trying to flash the analog modules, I would start by flashing the PLC. So if the PLC, and I would assume that this is not just the backplane. It's probably the PLC itself. I would flash the PLC firmware before doing anything else. And I haven't tested it. I guess if you, you obviously can see the backplane firmware as well. But let's see here if we have the firmware of the PLC. So we have the, so it looks like it's not recognizing anything at all in the backplane.

And it seems to be that we have the PLC, we have the backplane and nothing beyond that. So number 1, I would make sure that you can go online with this PLC. Number 2. So again, and you've mentioned this a little bit, but the backplanes can be finicky. So these are the CompactLogix series, I have one on the other desk basically, but it is making contact in the back of the PLC when you seat the cards in. We immediately see that there are already some inputs tied, but these modules are also not coming on.

Strip the rack to one card and build back up

So what I would start with is, flash the firmware of the PLC, I would remove the PLC from this entire rack and add only one module, Preferably one that, or it should come up with a green light on the module side. So maybe removing these three again, I'm not sure why they're not coming on, but in this instance I would take the IF8, I would put it in basically the first slot, connect only that to the PLC and see if I can see it via the backplane. Now the other item is, we are connected over USB, I don't know if it's worthwhile going over the network, maybe the backplane is recognized differently, of course this will affect your RSLinx setup, so here we're connected over USB.

It shouldn't be a problem, but again I would just double check to be sure. I will also double check, again these are new PLCs, so you shouldn't have any issues on that front, but I would still double check that you have flashed to a firmware that is basically good without any known issues, especially on the minor revision side. I don't believe that we have any details, let's see here, so only on the cards that he's trying to flash the firmware. But like I said, there's a couple of things going on, so if you're not able to see the cards on the backplane from that PLC in RSLinx, there's already a bigger problem, at least in my experience on that side, so it's not even about trying to understand why only this one is showing up, you should be able to see all of those modules.

So like I said, you have a couple of options, flash the firmware, connect from USB, try to connect over the network, double check that the firmware that you're flashing on that PLC is correct. Can you go online with the PLC using Studio 5000, are you able to add cards that way and see where they are at? It is possible, I have seen this in very rare occasions that you would receive a card that has been either refurbished or basically has a factory defect, therefore I would start by removing all those cards from the rack, putting only one in, again without any attached I/O, we see that there's already some inputs pulling them in, could it cause issues to the backplane, I have not seen that necessarily but maybe something weird or something else is going on, so again with these you should be able to really easily just pop out the inputs, so just remove these front plates, put one single card in with the PLC, make sure it tracks on RSLinx, add the next card, add the next card and build from there.

From industrial electrician to PLC programmer

We have a final question, which is going to be career related. But my background has been, I basically went the university route and I did a full electrical engineering bachelor's out of Montreal, Concordia University, before going into the workforce. I then did a master's in business administration several years after that, so I obviously have a different perspective to offer on the specific question. That being said, I have mentored countless individuals, I have promoted individuals, I have hired individuals in these specific circumstances, so I definitely have a lot of experience as well as knowledge to share with the specific question.

And so this comes from the username ways 312, and they say: "Has anyone here started as a hands-on industrial electrician and successfully transitioned into a full-time PLC programmer? Hi everyone, I'm currently mapping out my long-term career path and looking for some real world perspective on success stories from people who have actually made this jump. Right now I have vocational certification in electrical installation and maintenance with a strong foundation in hardware, three-phase systems, motor control, switch gears and electrical fault finding. My immediate plan is to get hired as a field industrial electrician, maintenance tech on a factory floor, to get solid experience with physical machinery and wiring. While working on the floor, my goal is to heavily self-study PLC programming, focusing on Siemens TIA Portal, ladder logic, troubleshooting, with the ultimate goal of transitioning into a full-time PLC programmer role. For those who started on the tools and moved behind the laptop, did you find that your hands-on electrical troubleshooting background gave you an advantage over pure software engineering graduates? How did you handle the transition logistically? Did you learn on the job during downtime, or did you build a portfolio at home using simulation software? What is the one thing you wish you knew or started studying earlier while you were still just pulling wires and swapping sensors? Would love to hear any advice, pitfalls to avoid, or stories from anyone who successfully crosses the bridge from the tools to the code. Thanks."

So a couple of things before I start giving my thoughts on his specific questions. If you have the drive, the passion and the enthusiasm to work on something in PLCs while you're doing a lot of the industrial electrical type of work, I would be willing to bet that the employer that obviously has those positions and opportunities would be more than happy to have you shadow some of those engineers or technicians, learn some of those control systems, and when the timing is right, obviously give you an opportunity, but hopefully also invest in your career as you're learning some of those concepts.

Tell your employer before you self study alone

So my initial comment would be, don't try to self-study everything on your own. And of course there's some caveats. There's always going to be bad employers, if you will, that couldn't care less about what it is that you would like to do and only care about what it is that you are delivering. So with that aside, I would start making it clear to your employer your intentions. As you start working at the plant level, there is the likelihood of there being engineers, technicians and sometimes managers and directors that came from the plant floor and programmed PLCs. So I would make the ask: hey, I'm looking to learn more PLC programming, I'm going to put in some effort on my own to study Siemens TIA Portal and some of these concepts. Would you be open to giving me some of the opportunities and time to shadow those individuals and perhaps work on some smaller projects?

So what I have seen in the industry myself, having worked for Procter & Gamble, Kraft Heinz, Post Holdings, having been to many, many different plants, there is never a dull moment. There's always something to be solved, there's always something that you can tweak, you can program. There's short term projects, there's long-term projects. There is always something to be done, and therefore there's always also a lack of personnel willing to do the work, whether that's on the electrical side but also on the PLC side. So what I'm trying to say is, if you're willing, if you're forthcoming with your intention, and if you're providing value and are being good at what it is that you do, you will have no issues making that transition.

That being said, I would not expect it to be as drastic as you're describing. I think that the experience that you gain is extremely relevant, and you shouldn't make the shift from just wiring sensors and solving some of the electrical challenges to just sitting behind the laptop. And I would argue that even the work of a PLC programmer, control systems engineer, automation engineer, whatever you want to call it, is not just sitting behind a laptop and programming PLCs. A lot of times it's also going in the field, working alongside electricians, running checks, troubleshooting equipment. So typically you're the second layer of defense. After the technician comes out on this troubleshooting a problem, if he's not able to solve that, the engineering team is going to be called, whether that's on the maintenance side or engineering side, of course, could be a debate. But ultimately engineers do go in the field and help out their teams. So don't think that the transition is going to be as drastic as you may seem to believe.

Does hands on experience beat a software degree

And so let's address the actual questions. I'm going to reread them just so I can better structure my thoughts. Did you find that the hands-on electrical troubleshooting background gave you an advantage over pure software engineering graduates? 100%. So I have worked with many individuals over the years. Those that have spent at least some time in the field working in actual plants are typically better than those that haven't seen the actual hardware, because again, remember that our world lies between the physical and the software. And so if you have spent some time in the physical world and you understand some of those connections, you understand why instrumentation fails, you understand corrosion, for example, in food and beverage environments, you haven't just heard that the signal is 0 to 24 volts or 4 to 20 milliamps. You have lived the problems that can happen with some of that instrumentation. You will be miles ahead of someone who hasn't seen that.

And it's even to the point that at a company like P&G, when I had first started, I was brought in as a band 1 manager. So my official title within the Procter & Gamble ecosystem was managing personnel. I remember the first couple of months I was on the floor, I was helping wire some of the line items, I was running a lot of checks in order to get that exposure that I had not had in my engineering courses. And I hadn't done just pure software, I did electrical engineering, so I had quite a bit of lab experience, but I had not seen plant floor automation the same way as you have with your electrical background. So definitely something that is to be leveraged in your interviews. I would emphasize that you have this experience, your willingness to learn, and of course whichever learning path you decide on to learn PLC programming.

How the transition happens in practice

How did you handle the transition logistically? Did you learn on the job during downtime, or did you build a portfolio at home using simulation software? As I've mentioned a little bit earlier, I have seen many instances where technicians were simply given the opportunity, sometimes sent to training by the company they were at, to then progress to the next level. A lot of the larger conglomerates will have a tiered system where you're a technician 1, technician 2, technician 3, then you can become, for example, an engineer. So in the US versus, let's say, the European states versus Canada, you will have different designations for the title of engineer. The title of engineer is protected in many European countries as well as Canada, but in the US, even if you don't have that bachelor's degree and you're not paying, for example, here it's the Ordre des ingénieurs, to get that, you can progress to the engineering side.

So with that in mind, like I've mentioned, let's say that you're troubleshooting hardware, and maybe you don't have a laptop, you're just using a voltmeter and you're going out there and you're executing certain work orders. At some point you can make the ask: hey, I'd like to learn more on the automation side, I would like to work with robotics, I would like to work with PLCs. You will then be issued a laptop for minor troubleshooting activities. It could be, if it's obviously in Studio 5000 or TIA Portal, maybe you can trace some of the issues and start there. At that point you will probably need to ask for access to PLCs, to be given permission to go and make certain modifications, get the programs, and you will steadily build into that tempo. That's not to say that you will have that immediate transition. You will just be given more and more responsibility, but also hopefully you'll be getting some training, you will be getting some recognition within the company via a different title, via a bump in pay.

But I think the more important thing to re-mention here is that you need to have the drive and you need to make it known. I have worked with engineers that would also, conversely to your point here, tell me very explicitly: Vlad, I want nothing to do with programming, I want to stick to electrical systems only, I want to work on hardware, I want to work on wiring, that's all I know, that's all I care about. So again, they would almost themselves disqualify from then working on PLCs.

What is the one thing you wish you knew or started studying earlier while you were still just pulling wires and swapping sensors? So again, just to give you a little bit of context, when I came into the industrial automation and manufacturing space, I had no prior knowledge of PLCs or HMIs or SCADA systems for that matter. So I had to learn all of that almost on my own, as much as I could outside of work, but also take certain training materials. So what do I wish that I knew? Well, number one, obviously it was very stressful early on. I wish that I spoke a little bit more to some of my peers as well as mentors to understand what is a good learning pace, because I would, and this is just purely my character, put a lot of pressure on myself trying to learn as much as I can, and then be disappointed if things didn't work out. So obviously pace yourself, understand where you stand, because there's a ton of things to learn.

When it comes to what to learn and when to learn it, it also depends on the facility, so depending on the industry, on the vertical, on the environment, but also on the team. It's possible that you could focus on learning SCADA systems because there is no SCADA expert within that specific company. It's possible that you will spend more time on PLCs. It is possible you will become the OT network expert. So there's a lot of different areas that you can focus on. I wish I had those conversations to try and figure out better where my focus should have been in terms of what to start studying. Again, there's a lot of opportunities. I think it's pairing what you enjoy doing, but also pairing with something that is in demand in the field, in demand at the company and in demand with the team.

Why you cannot learn this field without hardware

I also, and this is something that I recommend to almost everyone that comes into our space and asks me for advice, I truly believe that it is very difficult to learn without making the necessary investments, and that's the reason why you see a ton of different hardware behind my back. I spent a lot of money, I would say, well, a lot relatively. I spent money on training opportunities, I try to read as many books as I can, I invest in myself in that sense. So in many cases I see people basically saving money instead of paying someone or paying for a course that might be a little bit more expensive or buying the hardware. They will use either a simulator or they will go on a free version. You can learn quite a bit on YouTube, but at the same time, what I have learned is investing at some point is necessary.

And the reality of our field is that it is very difficult to get true hands-on experience without having the hardware. So for a reason that is also frustrating to me, with the OEMs that dominate our space, you simply cannot simulate, you simply cannot basically build the systems that you would see in the real world via a simulator. So therefore you do need to spend at least a little bit of cash to see how everything works in the real world. So early on in my career I remember buying Cisco switches because I wanted to get my CCNA certification. I remember paying for cloud services at some point because I wanted to get the AWS certification. I remember buying PLCs, I remember buying the licenses, I remember buying the VFD that I wanted to try a few things on because I was frustrated that I didn't have that chance at work. So in any case, there's a lot to learn, there's a lot of learning opportunities. If there's further questions, don't hesitate to reach out. Happy to chat and give you some guidance.