This Obsolete ControlLogix Runs a Whole Line, and Nobody Will Modernize It [PLC Q&A]

How's it going, everyone? Welcome back to the next discussion as it relates to industrial automation, manufacturing, and closely related fields. As we have done in the past, we're going to look at some of the most popular questions, some of the most popular comments on a variety of different mediums when it comes to our industry.

I'm going to be providing you my perspective. Again, happy to have a conversation, a debate. The easiest place to reach me would be on LinkedIn. You can also, if you're watching on YouTube, leave me a comment. I make sure to answer every single one of them, and of course, happy to discuss any other topics that are unrelated to what we're going to be talking today.

That being said, the same format as we've done in the past applies. We're going to look at the five most upvoted questions, and we're going to be answering them one by one. And so the first question comes from the user by the name of Ludwig Ormaar, and he's saying, "My first ever real automation project.

Thoughts on UI/user experience?" And he said, "Made this panel for our farm So the context here is very important because he mentions that this is basically a p- potentially a family farm or maybe his farm, and this is what I would call more of a DIY project as opposed to large industry which is going to follow certain standards where it's going to be a pre-established systems integrator.

So of course the bar and the general expectations of UI are going to be different. And so as we scroll through the screens, I'm going to leave a couple of comments. I'm just going to zoom in a little bit. We have the first screen which is the ventilation, and we can immediately-- I speak French, so we can immediately notice that a lot of the labels are going to be in French in this instance.

It says réglage température température de pièce. So it is basically temperature control and the current temperature of the room. I can obviously read through all of this, but what I'm immediately noticing and what stands out to me on this screen is of course the right side area where we see a lot of green, we see a little bit of red, and for some reason we see a little bit of blue.

And again if I squint well enough, we can notice that it is in auto. And so my initial impression is that there is quite a bit of color, and if you look at the ISA, I believe it's 101 where you have minimalistic HMI or modern design standards, I don't necessarily agree with all of them but I do agree with the premise that we need to reduce the amount of objects as well as colors that aren't requiring our immediate attention.

And this to me immediately screams when you have very bright green and especially red colors that something is perhaps wrong or different in the system. And of course there's nothing wrong. This-- I prefer this much less brighter other shade of green. That being said, of course it's easy to understand what needs to happen.

You press the start button, the system starts. You press the stop button, the system is going to stop. And there is some kind of an auto/manual operation where you can change the function of the screen. Let's look at all the screens for just a moment. So it looks like we have three motors. I am unclear what a soigneur is.

I will have to research the actual translation. However, we immediately see the start and stop push buttons as well as indicators, and I'll make a comment on that in just a moment. We have a third screen which says statistics in French on the top. And last but not least, we have a picture of the panel in which the PLC as well as the HMI are installed.

So we can immediately see that there's a CLICK PLC, and for those that haven't noticed the screen on the previous picture, it is an AutomationDirect system. So of course, immediately, I have worked personally on Rockwell, I have worked on Siemens, I have done a lot of work with Ignition. This is going to be a price-sensitive or price-conscious application where you're looking to make the system run.

You're not necessarily looking to leverage the tools and the faceplates, whatever it is provided to you. You're just making sure that the equipment operates as expected. So once again, there's going to be some compromises with these different tools. That being said, if we look at the second screen, the first thing that immediately stood out to me is the fact that you have the push buttons, and right next to those push buttons you have the status of the motor.

I've explained this on this channel already in the past. I prefer to have more statuses for my motors. And so again, obviously I haven't looked at the panel, I haven't looked at the drawings. I'm assuming he's using contactors perhaps instead of VFDs, but I like to have more status indicators for the motor.

And what I mean by that, generally speaking, is it's not only running or stopped, it could also be accelerating, it could be decelerating, it could be faulted, it could be paused. there's going to be a variety of different statuses. Therefore, I never or rarely use just pure LED indicators for a specific motor unless it's a high-level screen, meaning there's just a very small motor drawing.

I can have maybe the color be either green or red just at a first glance. But here, if we're starting, if we're stopping, I believe that there's an opportunity to show a little bit more as to what the motor is doing. I'm assuming that there's no speed regulation. I haven't seen any analog fields on either side, either as an input or an output.

So again, my assumption is that is fine in this application because it's only starting and stopping the motor. That being said, again, I really dislike this UI where you have four buttons and it almost feels like one is a button, the other one's an LED. You have to really pay attention as to where you press.

I would recommend having the start and stop next to each other and then having the motor light up as green or light up as red and underneath say either running or stopped or faulted if there is a system fault. And he also has status lights in line with all of this. So once again, I'm not exactly sure why there's, for example, two duplicate indicators.

And maybe this is the entire system versus this is the motor. So again, interesting design on the side. And it looks like this is for the status for the entire line. So again, maybe if all three of them are running, then it is in good condition. Maybe if two out of three, maybe if one out of three. That is, of course, based on the logic that he has written.

And the last comment we have is about the statistics page. So number one, I immediately am confused by what is happening. It looks like it's some kind of a screw conveyor, and maybe it moves in, or the motor gets closer into the fan area. So that's why maybe the first one is already further ahead than the other ones.

Again, it's a little bit difficult to understand. If I'm calling a screen that is statistical, to me, it implies some kind of data, maybe some kind of graph, maybe a bar chart. It is not very clear without further explanation as to what it is exactly that we are looking for. The comment that I will make on the navigation side, simply because I noticed that his menu button is on the top left on this screen, as opposed to being on the bottom left on every other screen.

And to me, again, this is part of good UI design. Usually, I like to select a navigation scheme for the entire project, meaning that if you're going to be able to change screens between any of them, you're going to have the same feel for navigation. And it's either going to be on the bottom or it's going to be on the left-hand side, but it's going to be very familiar.

The same buttons that are going to be, for example, going back to the main screen, the statistics screen, and maybe the system screen, are going to be in the exact same positions. What I also like doing is, again, if you have three screens as part of your design, and let's say you're now on the main system.

In this case, the way he set it up is that the main screen which is I'm assuming maybe this is not even the main screen, right? But there's a ventilation screen, and then for some reason you can go back into the menu or you can go back, I'm assuming is to the previous screen. To me, that is a little bit unintuitive.

So usually, the way I like to set up navigation is you have your main screen, then you have, let's say, your fan screen, your system screen, your setting screens, and based on where you are located, that button is pressed in. And there's going to be different ways of how you can do that in different software tools, but that way it is not confusing to the user as to what screen they are on and which other screens they can navigate to.

It also allows for a much easier design for security, right? So for example, if you have a system settings screen, it can be locked out if you're not logged in at the right permission level, and it can be unlocked if you are, right? So again, it is very difficult to illustrate without specific examples, but again, I would change up the navigation screen as it is presented currently in his specific application.

Like I said, I don't like the fact that you're navigating always at the bottom and there's one separate screen where for some reason you have to push all the way on the top left corner

The second most popular post this week comes from a user by the name of Bogus Dolphin, and he says, "My nightmare cabinet. This dusty box runs our whole mold line. Power supply failed on the back plane last night, and when I took it out after being down for an hour, the thing was still hot to the touch.

Not to mention the box is ten feet up, and this picture was taken from the top of the ladder." And so again, if you look at the picture I know that some of you are only listening to this in audio form. It is basically a picture of the Control Logix chassis, and I can only imagine how much trouble it was to troubleshoot this cabinet.

And I can already imagine the poor engineer or technician working on this thing and the line has been down more than half an hour. Everyone is pissed off. Everyone is pointing fingers. There's obviously conversations around revamping this thing and, just chopping off all of the conduit, rerunning it, making it clean, and of course, none of that is gonna go through.

I can almost guarantee that this line is going to continue running for the next decade. It's going to experience multiple failures. I'm sure that he has already made the case for this needing a better solution, but of course, we cannot take the downtime. It's very difficult to afford new control systems.

We cannot replace this. We cannot bring in a contractor or consultant or systems integrator that will help us solve this problem. And again, I've been to many of these conversations. We even see that he unplugged the module. I can't even read what's on the top here, and it's again, very difficult to see what the label is, but it looks like it took a lot of effort to troubleshoot this cabinet.

And I believe that sometimes our industry, or industrial automation in general, is underappreciated in these facilities until a failure occurs. And we are very quick to forget how much effort it took and how much, I would say, downtime was incurred in this instance as a result of improperly managing and investing in some of this architecture.

I can immediately tell you that the control logics that's inside of this chassis is obsolete and has been obsolete for over a decade because of how frequently I look at parts, at least in the world of Rockwell Automation. And this controller, if you go today on eBay, which is, I would say pretty much the only place-- obviously you can go to Radwell, but it's one of the only places that you can get it, is worth fifty dollars.

So basically, this control system that is running what I would assume is a multimillion-dollar production line that probably incurred a ton of downtime and costs associated with this failure, is running on a control system that, again, if it were purchased second-hand, would be worth Maybe $500, maybe $1,000, right?

So the point that I'm trying to make here is that you need to invest in your control systems. The other thing that you immediately notice is he's connecting over RS232, and I don't know if that's on-- yeah, so we can see the switch right there, right? So the switch is connected through a variety of different parallel equipments.

Again, maybe there's VFDs that are connected to this line. It's very difficult to say, of course. There's going to be a Data Highway+ card. There's a single, again, very old Ethernet IP card, which is also obsolete, by the way. You can see the IP address at the top, but that's pretty much it. And so there's just a lot of wrong, and I can feel his pain.

I am sure that he's going to tell his manager, either on the maintenance or engineering side, that we need to invest some capital into this specific enclosure. And what is he going to get as an answer? " We don't have the downtime. We don't have the capital. The line has been running, so why modernize?" And again, I could make a lot of comments.

I work on a variety of these different projects. I try my best to negotiate and help others understand why it is important to modernize, and I could start listing things, right? So again, if we talk about this specific PLC, for those who are not familiar, the ControlLogix line is going to have different versions of PLCs.

It was released multiple decades ago in the early 2000s, but it has gone through multiple revisions. Late last year, Rockwell has actually released the L9 series This is what is considered the L6 series, which is the Logix fifty-five sixty-two. Again, it's the second basically variation of the L6 processor.

So you have the L6, you have the L7, you have the L8, and now you have the L9. I'm not sure if the L9 is actually sold to the end customers. I have seen it at a couple of trade shows. Now, what I'm getting at here is that this specific line of controllers only goes up to version RSLogix twenty.

You cannot flash the firmware up to Studio five thousand, which basically means a couple of things. Number one, you do not store any of the comments inside of the PLC. So if this person walked up to this specific rack without context, probably having not troubleshot this line and this specific PLC in the past, you connect to it, you upload the program to your machine, to your computer, you have zero comments inside of your logic.

Number two, the support for this hardware, like I said, ended more than a decade ago, and actually it might be two thousand and seventeen, if I'm not mistaken, so almost a decade ago. Which means that if the PLC were to fail because of the heat, you could not even purchase one. Number three is, of course, we have Data Highway+, unsupported protocol.

All of that needs to be migrated to Ethernet IP. If anything else were to fail, not specifically within this rack, but the Data Highway+ card and whatever peripherals are attached to it, you are going to incur incredible loss due to downtime. It's not going to be only replacing the power supply that, again, he mentioned took about an hour to complete.

You will potentially be down, depending on how many spares you have, four weeks, or you will have to figure out how to perform that migration during the downtime, as opposed to lining this up somewhere on a test bench, making sure that everything is addressed, making sure that all of your peripherals are upgraded, and then running the changes to your specific rack.

So again, there's a little bit of science, there's a little bit of art as to what should and shouldn't be migrated. In this case, I just feel bad for the electrician or engineer that has to work on this rack that is probably understaffed, that probably has zero support from management to modernize all of this equipment.

I've been in many of these conversations. So again, happy to provide further advice. If you have anything of this nature, don't hesitate to reach out.

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 thread is with regards to a training kit, so to speak. So someone has built a PLC lab setup and has or is looking for project ideas for a Siemens S7-313C and KTP 700 series panel. And this is by the username of CuriousBarnacle781, and it says, "Hi everyone. I've recently put together a small PLC training setup, and I'd appreciate some feedback and project ideas.

Current hardware, Siemens S7-313C CPU, Siemens KTP 700 HMI, 24 VDC power supply, two breadboards, six push buttons, two potentiometers, eight LEDs, MPI programming cable. The setup is intended for learning industrial automation and PLC programming at home. What I would like feedback on, what do you think about the setup?

Is there anything important I'm missing? What skills could I realistically develop with this hardware? If you were in my position, what project would you build first? Some projects ideas..." He lists a bunch of projects, and I'm actually the number one commenter on this specific post, so I can, read my first comments.

So it doesn't make sense to me that include components that cost thousands of dollars and throw in five cent push buttons instead of the industrial ones. It just makes the overall experience seem cheap. Is there anything important I'm missing? I'd add some networking gear as it is important even on the simple setup and provides an opportunity to explore IP addresses, subnet masks, et cetera.

What skills could I realistically develop using this hardware? PLC programming, HMI development. And if you were in my position, what project would you build first? So let's go step by step. First and foremost, initial impressions. So as I've mentioned in my reply, it doesn't seem to make a lot of sense when you're going to go out and purchase industrial hardware, the licenses that are needed to program some of these devices.

Again, maybe as a student, he has downloaded some dubious versions and is using that for free. That being said, I do believe if you're going to build a kit that not only you can practice on, but also maybe you can bring into an interview, it makes a lot of sense to spend a little bit extra and add the industrialized buttons.

And again, those don't have to be expensive. You can go on AliExpress. You don't need to use the proper industrial panel-rated push buttons. You can get those buttons for a couple of dollars, but they look much nicer when presented. And of course, it makes even the design seem a little bit more premium.

And the reason why I mention this is that I have interviewed in the past technicians and engineers right out of school or right out of technical programs where they have brought their setup as part of the interview, and I would ask them questions, "Could you show me what kind of a demo you had built?"

And of course- the more impressive the demo, not only from a technical standpoint, but also from the craftsmanship standpoint. Especially if you're looking for some of the technician-level roles, it is important to have the skill of putting things together as opposed to, again, maybe if you're an engineer, you're purely focused on programming, it could be a different story.

But it is important to have some good hardware that goes along with your PLC and HMI in this case. His second question was about what am I missing What should I be adding to the setup? So of course, I have a couple of thoughts on this front. I have built many trainers, including discussing some of what I would add to different trainers on this specific channel.

So number one, I applaud for to anyone who has put the time and effort into building something of this caliber. I am giving him advice based purely on what I see out in the industry and what skills I believe that are important. That being said, you can learn a ton of valuable skills with just what he has already presented without even changing out the push buttons.

I can even make an argument as to why you probably don't need the push buttons because you can virtualize them on the HMI screen, but that's beside the point. Number one, I would add a networking switch or router. So I've talked about this in many other episodes, but a lot of devices nowadays will need to be connected to the OT network and in many instances to the IT side, and a lot of those responsibilities will fall on the technicians and engineers on the OT side because at a bare minimum they need to be able to set IP addresses, they need to be able to set subnet masks, they need to understand what a default gateway is, they need to be able to establish communication between those peripherals as well as many others such as servo drives, VFDs, load cells, so on and so forth.

What skills could I realistically develop with this hardware? Again, I jokingly said PLC programming and HMI development. I think that's a little bit obvious. This is a question that is to an extent rhetorical, but you can obviously develop a lot more than that. You can also develop your electrical skills.

If you need to troubleshoot some of the systems, you will develop your troubleshooting capabilities. You can of course program a system that you can use or pitch in the real world, so perhaps you can design something that is complete and allows you to then land jobs and practice some of those skills.

So interviewing skills as well, and the list goes on, but again, fundamentally of course a lot of the emphasis is going to be on PLC and HMI development, but ultimately the world is yours, so to speak. And the last question, if you were in my position, what project would you build first? And of course, again- I am of the opinion that you should build something that you truly enjoy.

So if you have maybe another hobby, I would definitely focus on that. Number two, the other comment that I always make is that many individuals try to jump steps to projects that are very complex. So nowadays, if you go and you open up ChatGPT or any LLM, you could ask for a functional spec of an oil and gas facility, or you can go and ask for a pharma plant, and it will give you a pretty good design specification of the entire process.

The problem with that is if you're going to design a system for a very narrow scenario, when you're going to be applying for jobs or when you're going to be presenting this demo to someone who's unfamiliar with that specific industry as much as you have been because you've done the project, it's going to be difficult to convey those nuances.

And so instead of highlighting the demo, you're going to be explaining the use case, and you're going to be explaining the process more so what you have created as the PLC programmer and HMI designer. So all that to say is I would pick a use case that is very well understood by everyone, and this could be, for example, an elevator system.

And a lot of times the comment that I would get is what's complicated about an elevator?" And the answer to that is you can make it as difficult as you would like to or as you desire. There's going to be elevator systems with multiple floors. On every floor, you have a check for open doors, for positioning.

You have analog sensing for what's happening inside of the elevator. You have different recall functionalities. But everybody understands what an elevator is supposed to do. So when you open up your system and you show the HMI screen that has different floors, and you can, for example, press a button to recall the elevator to a specific floor, it is very well understood what the system should be doing, so you will be focused on explaining what you have built as the individual, the technician or the engineer, as opposed to some very obscure process that may be fascinating but distracts from the demo.

And of course, elevators is just one simple example. It could be an application of a crane. It could be a pump station. It could be even something as simple as a pool that gets filtered, that gets cleaned, that gets pumped out, right? That's going to utilize a simple control system process that could be showcased fairly easily but also have many different intricacies of PID loops flow meters it could be turbidity measurements, it could be your totalizers, right?

So you can take it to a whole other level by having an application of statistics, graphs, trends, so on and so forth

The next question we have for you comes from the username by the name of DryGolf5000, and he says, "What was the most exciting PLC project you worked on so far?" As the title says What is a fun, awesome, or cool PLC project that you are proud of or something you will remember for the rest of your life? And this probably warrants an entire video.

I will at some point share and explain a project that is no longer under NDA. I will give a couple of details in this specific post. I want to dig up a couple of pictures, not from the specifics of the project, but the generalities of the systems integration. And so for me, this project took place around the year of 2018, and this was a peanut butter facility.

So they grind the peanuts. They have a lot of different storage tanks. They send it through an entire processing plant, and then they jar the peanuts, or they can basically add crushed peanuts to make it chunky, or they send it in pure liquid form. Again, it depends on, of course, the temperature of what the peanut butter looks like.

So a lot of process design, but also packaging. There's gonna be jars, there's going to be lids, there's going to be sealers, there's checkweighers, there's vision systems, barcodes, you name it. And so I was in charge of taking that existing plant and creating an entirely new replica with all of the equipment that has been modernized.

And I had to program not the small components of equipment, but all the large pieces, as well as tying the entire plant together. Everything from networks to HMIs to VFDs. There were hundreds upon hundreds of different conveyors, different rotary valves that would allow the peanuts to flow out of these massive tanks.

There were different conveyors with pucks that would bring peanuts from one area to the next. There was a massive roaster which the-- it was programmed by the OEM but was interfaced by the plant system to regulate some of the recipes based on how cooked or how raw you wanted the peanuts. Of course, those settings are usually set by the operations team, but all of that needs to be managed via the HMI, the PLC, and of course, needs to be conveyed from the plant floor via remote IO into the main control system.

So for me, that project was extremely exciting because it allowed me to be very creative, but at the same time, needed to balance a lot of very technical details. So I still remember selecting the Stratix switches that we needed inside of every panel. I needed to select all the IO points that we needed inside of every panel.

I had these whiteboarding sessions with the engineering director at the plant discussing the tanks, what kind of sensors were they going to ship with, what kind of safety do we need, what kind of guards do we need, what kind of again, analog level measure sensors do we need?

And a lot of those questions were very ambiguous, mostly surprisingly, not only for me, but also for the team. They were not, or they had not built a peanut butter facility from scratch in the past, so of course there was a lot of design back and forth. They wanted to improve on what was already established, but they also wanted to keep some of the learning points as to how they have ran the process in the past.

So for me, that was a very exciting project. It took close to a year, I would say about eight months to completion. It was a very tedious... I still remember the three weeks of commissioning all equipment. I had all the IO listed. I had to climb on multiple ladders. I had to validate pretty much everything. I had to work with the OEMs, basically the manufacturers that brought in certain pieces of equipment.

So I've mentioned already the roasters. I remember there were the blanchers, which basically looked at peanuts falling down, and using vision systems, would reject the peanuts that were either too raw or were not de-shelled. Meaning that if you have a peanut inside of its shell, if the shell was not removed, the peanut would get rejected and then either re-roasted or discarded out of the system.

They would use it for stock feed. And I still remember designing the HMI screens, and I remember, and this is a funny side story of this specific project, that the most impressive part for the operators wasn't the backend of the system. It wasn't the logic. It wasn't how I laid out the PLC program.

It was the fact that on the HMI, you had this little bar as the tank filled, and I had made that little bar basically in peanuts. So what you could see is, and again, this is an effect that you make in FactoryTalk View ME for that Standalone local HMI. They had transitioned to FactoryTalk View SC the year later for cost-saving purposes.

But it was basically a bar that was sliding up and revealing peanuts as the tank filled, and I still remember operators being extremely impressed by that specific feature other than anything else inside of that system. And for me personally, I still remember the batch handling for that specific system being a very critical component.

For me, keeping track of the batch as it came through the roaster into a specific tank, then you had different register points, and then you could basically take different quantities of different batches. You could mix and match and send that to the process line for a different cookedness, if you will, of the peanut.

So you could roast them to different levels, and then you can mix and match different peanuts based on the system. To me, that was the most impressive part. But again, very interesting project because I had a lot of creativity and a lot of leeway as to which hardware as well as which software we were going to use for the entire facility, but also tying in all the key components for different vendors together.

And seeing all of that come to life was absolutely incredible

All right, we have a very interesting final question in front of us, and it comes from the username curiousbarnacle781, and I have a feeling I've read this name in the past. Some of these questions, again, it's hard to say if they're coming from real users or from people that are using ChatGPT to generate engagement and basically ask questions that are rhetorical in nature.

But in any case, he says, "Hi everyone. I posted my training setup the other day and got a lot of mixed feelings on the, in the community. I plan on documenting my journey here and updating everyone who is interested in my progress. Will try to do updates every two, three days. I'm a beginner in the industrial automation."

And that's where I recognized the name. I just read one of his questions with the trainer. "I'm a beginner in industrial automation, currently learning Siemens S7 PLC programming in TIA Portal. I have access to the PLC and HMI we just saw, basic Arduino kit for simulation purposes. I've started building a portfolio project, a hydraulic press with pneumatic in-injector simulation, and I'm learning a lot, but I feel like I'm missing the bigger picture.

A few questions for more experienced folks here. Project structure, how do you typically structure? So let's just answer these one by one. Again, we already have the full context. He's describing some kind of a hydraulic press with pneumatic ejector simulation and so he's missing the, quote-unquote, bigger picture.

How do you typically structure your PLC programs, OB, FC, FB, DB hierarchy? And so again, these-- some of these acronyms are of course Siemens specific. If you come from the Rockwell world, this is going to be a little bit different. This is your programs, your routines, but also how you describe maybe your functions, your blocks that are go- you're going to be reusing in your program.

This is a very broad question, right? So how do you structure a program? And those of you who have seen many different applications know very well that there is no single answer to this question. That being said, having done projects completely from scratch without being able to use anything else, I do like to spend some time analyzing the system that will be controlled by my specific equipment.

And the reason for that, of course, is you want to break down the individual chunks of the system as opposed to trying to break down software that doesn't exist yet. So generally speaking, I will start segmenting the different logic areas when it comes to the actual real-world scenario. And this can be, again, different depending on your level of comfort, but also the level of software and understanding required to program that system.

So I will give you an example. If you have some kind of a batching operation, right? So you're looking to cook something, to mix something, and maybe to ferment something inside of a tank, maybe you can have that as a wrapper as being one simple system. The next system is going to be the second tank in that process.

Again, that could be a storage tank. And so each one of the tanks is going to contain sub-elements. Those could be your pumps, those could be your infeed or ingredients, it could be your totalizers, again, for the batch processing, it could be your load cells, right? So each one of your systems is going to have a subsystem.

And so the way I like to structure a project is I start to think my entire project is a system. What kind of subsystem does it contain? Then each one of those systems, what kind of subsystems does it contain? And I try to break this down as far as I can without going to, into instrumentation, right?

So for me, just a single analog sensor is not necessarily-- You could call it a system, but I don't think of that as a system. So for example, if I have a pump that has a VFD, but it may also have a inlet or discharge valve, it may also have a couple of sensors, so that is a system, but the individual sensor is not going to be.

Of course, does the tank contain the valve system or the pump system? Again, it's up to debate on how you segment that. But hopefully that provides some clarity on how I think of larger projects and how I will create PLC programs. Of course, there's going to be some auxiliary programs and routines or function blocks And that's going to be, for example, your IO, right?

So your inputs, your outputs, your analog scaling, your PID instructions. Those are going to have separate function blocks built for them. Do you always use the Hungarian notation for variable naming? I am not familiar with what that is, so I do not always use the Hungarian notation for variable naming.

I believe I had this conversation on a separate thread as to how I like to organize my variables, and a lot of that reason is driven because I've done a lot of different data work, so I understand the memory efficiency, and I would allocate, let's say in the world of Rockwell, a 32 Boolean array to different varial- variables as opposed to creating one alias for each individual tag, like a lot of programmers that came from the RSLogix 5000 series era like to do.

Is S7 Graph SFC standard in industry or do most people stick to ladder and function block? Again, this depends on the region and depends on the application. I will make the comment that in North America it is a lot more common to see function blocks or more specifically ladder logic, and then followed by all the other languages.

In Europe, I would say it is a lot more common to see structure text followed by function blocks and then followed, of course, by ladder logic. And again, this is based on my experience. It of course depends on the industry, it depends on the size of the company, it depends on their comfort level, and it depends on the platform for the control system of choice.

Industry practices, what's the standard approach for alarm management in a real project? The reality is-- there are some standards, but I would say that they are far and few in between. Typically, the way I like to implement alarms is I would separate into two categories. So those are going to be your alarms/faults, or they will be warnings/alerts.

And the big difference is that a warning will not shut down a process. A fault or an alarm is something that will prevent the process or a component of a process from running. Of course, both of them need to have a action step for the operator to take. What I have witnessed very frequently in our industry is that a lot of warnings and alarms get created and basically overused to the point that the operator is going to see a list of different alarms, and they're going to start ignoring them Which obviously is dangerous because when a real threatening alarm is going to be shown, they will simply not react adequately because they're so trained to mute the alarms via the system or of course just in their mind.

The other best practice that I will mention is that a lot of the alarm management tools inside of the OEM equipment are not going to be optimal. And what I mean by that is every HMI system, whether on the Siemens side, on the Rockwell side, on Ignition, on many other different platforms, if it's AutomationDirect, they will have their own way of you sending the alarms from the PLC into the HMI, and they will be fairly restrictive in my opinion.

So what I like to do is I like to build out my own arrays of alarms that can also log other variables when the alarm comes up. It can also log the username that was maybe registered at the time of the alarm, and it gives me a little bit of a data buffer so I can also go back and troubleshoot the alarm.

Now of course, this is going to be a little bit more challenging than just taking the out-of-the-box solution and pushing, for example, an integer as well as a message. I believe it's worth the effort depending, of course, on the specific system you're looking to implement. And if you're doing this for practice, I would experiment first of all with what's given to you by the native tools and then think of ways that you could augment that.

I believe that it really showcases extremely well in especially in interviews. How important is HMI design in real industrial environments? Extremely important. I believe that too many machine builders and SI, SIs, systems integrators, don't put enu-enough emphasis on HMI design. And so when you show up to the industry, you will see, I wanna say very poorly designed screens, massive buttons, different colors, illegible operations, very unintuitive navigation screens, and I believe that more thought needs to be put into designing the HMI.

Now, of course, there's going to be more critical elements, right? Some of the things that are of a bit more importance than, let's say, the color scheme or maybe even the shape of the buttons. If you have slightly rounded corners or if you have sharp edges, it doesn't particularly matter, right? That's going to be more of a design choice.

But if you're going to have strange navigation screens or experiences, that becomes detrimental to how the HMI is actually used in the field. Do companies expect you to know SCADA as well as HMI? Again, expect is a very strong word. Depending on the project, you can build a quote-unquote SCADA or you can build an HMI.

I've discussed this in multiple videos. There's going to be a number of, I'm assuming, referred videos if you're watching this on YouTube, but I've discussed the main differences between HMIs and SCADAs. And very briefly, your HMI is going to be controlling a local piece of equipment, is going to have a limited amount of data.

There's obviously ways to trend data on an HMI. Usually a SCADA is going to be a distributed environment, is going to collect and store and present a lot more data, so it's going to be a lot more analytics-focused, but it also will allow you to visualize and start and stop a substantial amount of pieces of equipment as opposed to a single machine.

In terms of resources, what resources do you use to go beyond the basics? Books, courses, YouTube. I had to learn a lot of this in the field personally, but I had hobbies that helped me quite a bit. So I, during my years at Procter & Gamble, which was late 2013 to 2016 or so, I remember I used to develop iOS applications, and I still remember how building iOS applications on my Mac really helped me understand better design when it comes to HMIs.

Because there you had no choice but to make really good design choices, and you had a lot of elements, again, maybe because it was the nature of the Swift language paired with the very nice UI editor for iPhones and iPads specifically that allowed me to, to an extent, see the light of best practices.

They had a lot of guidelines as to the size of the button. They had a lot of guidelines as to what it meant to actually press the button and having that tactile feel that the button is being pressed in and then pressed out that you don't normally see in industrial applications. So I personally took away a lot of those lessons specifically for the HMI when it comes to iPhone on iOS and iPad design in general.

When it comes to general systems, I learn a lot by whiteboarding with senior architects. So I would have a lot of conversations and ask them questions about the P&IDs that they have designed, about the different process steps, about how to, get unstuck when you're looking at the high-level picture and it's very difficult for at least my brain to understand and wrap my head around how to program this entire monstrosity or plant, and then how to segment that into smaller segments.

So it just came from a lot of conversations with people who have done the implementation before. " Is there a good reference for IEC 61131-3 standard that is beginner-friendly?" So this of course refers to the programming languages. Again, I have a lot of tutorials on YouTube. I have a lot of tutorials on the solisplc.com YouTube channel.

I now have a ton of different tutorials on the Joeltek website as well as the channel. So feel free to ask questions. I don't know any other resources. There's going to be a couple of books that you can probably find on Amazon Or online. Any Siemens specific resources you'd recommend? I have gone through a couple of the training materials that Siemens has put out.

I've looked at some of the videos that RealPars has put out. My general opinion is that there's still a lack of materials in our space: training videos, hands-on tutorials, labs, showcases of different equipment. And what's important to recognize, it's very rarely just about the PLC and the HMI. I have a lot of projects that involve the ET 200SP I/O series.

I have a lot of projects that involve scale and switches from Siemens. I have projects that involve PowerFlex drives and G 120 drives, right? So it's important to see a lot of those peripherals. So obviously, there are some on YouTube, but there aren't, to be honest with you, that many. I'm self-teaching and building this portfolio to land my first job in automation.

Any advice on what employers actually look for? I've talked about this many different times. I believe that if you express interest, and you can showcase something even much more basic than what he has designed, you do have a chance at a job. And typically, if they do call you in for an interview, it means that they're trying to evaluate the fit for the team, which means that you have the prerequisites necessary to land that specific position.

If anyone has good projects ideas, I'm open to suggestions. Again, you have already picked a project. Until you have completed this project, I would not switch to something else. I will take the time and design this hydraulic press with the pneumatic injector simulation. For whatever reason he decided to go that route, I would finish that project before moving on to something else so that you could learn and improve and get feedback.

Again, I don't think that there's a need to publicize every two to three days because a lot of the progress will take a little bit more time, in my opinion, than that. Maybe giving an update every other week makes a little bit more sense. But again, I think a lot of this is interesting, and we'll see where this continues to go if it gets upvoted again within the community.

Thank you everyone so much for watching and/or listening, if you're listening to this in podcast form. It will be released on a fairly regular schedule. I plan on doing this every single week. There's always different ideas and different comments to discuss. If you have anything to add to the conversation, would really appreciate you leaving me a comment, asking a question, or otherwise.

Of course, if you could share, truly appreciate it, and I will see you next time.