HMI SCADA Platform to Learn in 2026, Plus a Flooded PLC That Now Plays Street Fighter

How's it going, everyone? Welcome back to the next video in which we discuss and answer some of the questions that have been the most upvoted and most popular in our industry, which is the industrial automation and of course, manufacturing. Before we dive in, I do want to make a very brief announcement.

I will be at ICC or the Ignition Community Conference later in September, and the first week of, October, I will be at the ISA conference in Florida. So if you're going to be at either one of those, if you would like to have a conversation around technology, around manufacturing, around different solutions, don't hesitate to reach out.

The best place, of course, is to leave me a comment in the YouTube section. You can also find me on LinkedIn. Send me a message that way and definitely would be more than happy to find some time to chat. That being said, let's get into our first question, which is a very interesting implementation of a PLC as well as an arcade game/ controller for a console

Flooded Siemens PLC rebuilt into a Street Fighter arcade controller

And so this was written by the username Hobodozer and they say, "Am I doing this right?" There's the video we'll watch in just a second. They say, "This is a legitimate use case for this," right? "I got this PLC from a scrap panel that went swimming, cleaned all the dirt and mud out of it with an ultrasonic cleaner one PCB at a time, and it seems to have come around Just fine with no errors.

It'll never be deployed again, so I guess it plays games now. This works over Modbus with a custom bridge program trying to vJoy to behave as a 60-button controller with four axes. There's also an HMI that works over the same Modbus and program with SimHub to show PC and game telemetry. So if we play the video, and again, this is a very unique, I would say, and interesting application.

We've got a Siemens PLC that is tied to some, what looks like digital inputs, and I'm assuming there's obviously digital inputs as well as maybe some outputs, or it's just inputs from his side at this point. And we see him play, Street Fighter. I don't play a lot of fighting games, so I'm not exactly sure which version or which console this is being played on, but a very interesting use case.

So a couple of comments. Obviously, PLCs are extremely robust. The fact that you can pull them out out of a panel that, quote-unquote, "went swimming," I don't know if it was hosed down in an FDA environment, or it went completely underwater for whatever other reason. Maybe there was a flooding at the facility it was in.

That being said, if you worked enough with PLCs, you'll know that a lot of their PCBs are going to be conformally coated, meaning that there's a protective layer over the electronics. So generally speaking, if it was not, let's say, some kind of a fuse at the infeed, if it was not some kind of a short circuit because something got fried on that board, they will survive just fine.

So as long as you clean the electronics. And again, in some instances, it's gonna be unadvisable to pull out the boards and basically th- there's a lot of, I would say, cautionary tales as to what you should and shouldn't do when you're manipulating those. But ultimately, just like most other electronics, if you put them in some kind of a dryer and you take care of them, you wipe off any, dust or debris that came with the flooding, they should be more than fine.

Now, the actual application is very interesting. I would say there, there's a couple of parts to this build. It's relatively easy to tie in the push buttons and the switches from this controller back to the PLC. I would assume, and again, it's a little bit difficult to see where the wires actually land, but the push buttons are gonna be digital inputs and the joysticks.

The ones that he's actuating to move up, down, left, right, are going to be potentiometers, so you're reading analog signals. And then as it was mentioned, it's sent over Modbus to whichever console. I would assume that the original controller of that console was modified and basically tied into whatever this system looks like.

Now, for me, that would be the challenge. The Modbus communication back to the console is a challenge, and of course, displaying the... I don't know if this is the same driver. He's-- They mentioned that there's an HMI in this entire system, so I'm not sure if that's the HMI or there's a normal screen.

This is just a regular TV fed by the console, and the console is only receiving the, digital and analog signal. So anyways, it's a very interesting build. I would say it is definitely unusual. It got a ton of upvotes because it is fun to see. I know that a lot of different game systems, not necessarily consoles, are used or made by PLCs, but you will find PLCs inside of golf courses.

You will, in some instances, find them in arcades. Definitely a really cool build that is unexpected in our industry.

Device level ring explained on a real Stratix switch

The second comment, and this is very expected if you've been long enough in our industry, if you have commissioned equipment, whether that's at your own facility or if you've flown out to a different environment to basically work on control systems, you will very quickly learn that industrial panels aren't going to have the necessary seating, I would say, in front of them to accommodate engineering work.

And it's a bit of a challenge, but at the same time, again, some of us have adapted, I would say, better than others. And as you age or advance in your career, you start to ask more and more of the site because you know that you will be a lot more productive having a laptop on a proper table with a proper chair.

And I typically ask for a second monitor as much as possible Now, the author of this post is Cosmic with a one, and they say, "Don't want to brag myself, but this is a throne. Debugging some DLR fault at a Stratix." So a couple of comments, I guess DLR, device level ring, which will... If we switch over to my full screen camera, and if I can pull out the Stratix.

So for those of you who are not familiar, and again, this is a entry-level fifty-seven hundred type of a series switch. I've got a couple of other ones on the lab. So this one does not have DLR, but basically DLR means that you're going from device to device to device to device, and then coming back into the secondary port of the switch to, create a system that is a little bit more redundant than the star topology.

So if you have a switch going out to four different nodes separately, as an example, then if one of those connections fails, that specific node is going to be kicked off the network. By using DLR, you're basically having two paths. Because it's a ring. If one of the connections fails, then the traffic can go the other way.

Obviously, you will get a notification. It is a very commonly used architecture, especially in systems that require redundancy. But even so, it is relatively inexpensive to implement. So nowadays, if you're going with the Stratix, it is recommended to use DLR. There's other advantages of course, but ultimately simple and important to implement Going back to the actual post. We do have a nice panel, and the comment, of course, and again, like I said, if you've been in our industry long enough, you'll see that this is a joke. He got some kind of a very strange stool. Maybe he's kneeling down and then putting his laptop on the stool.

It's hard to say exactly what is happening here, but that's the joke. The plant is going to give you whatever is there to be able to program the equipment. We see that the laptop is currently on the side. Obviously, it's-- I just noticed that there's, uh, help written in a fingerprint based on the amount of dust that we have inside of the panel, which again, I have a couple of comments.

I have been in very... Or I have been very fortunate to have been in environments that take a lot of pride in their panels. So obviously, I do have some thoughts around that side. It looks like he's got the new model. So this is the fifty-eight hundred series of a Stratix PLC. We also have the Rockwell. Of course, we have the EtherNet/IP module.

We have the... We don't have the PLC here, so this is a remote rack. Or maybe this is... No, this is some kind of a safety module. So we don't have a PLC in this rack. So this is a remote IO rack that is communicating with the specific device. We have a converter from Ethernet to fiber optic, which is very interesting and sometimes unusual to see in these RAIO applications.

And then we have just a bunch of nodes coming off the input and output cards of the Rockwell chassis. So in any case, it's an interesting panel. I don't think there's a whole lot of complexity as far as the IO goes. But of course, the Stratix needs to be set up properly for DLR. I'm assuming that one of these cables may have failed.

At first glance, everything looks okay. Actually, how is this a DLR application? It looks like it's just going one-to-one. So maybe he's just configuring the DLR that will be deployed at the end of this job. Because in this case, we're only seeing a single, uh, cable going into the Stratix.

And then for some reason, I guess the fiber optics cables coming out of this device have not been landed in the switch as well. So in any way, maybe we will get an update, maybe not. But the joke here is, of course, the seating arrangement that you have from within this panel. The pro tip. If you are in this situation, travel with a much longer cable.

As you can see here, there's not a whole lot of room to bring this cable outside and maybe sit at a desk that might be multiple feet away from the specific panel. So I very often carry a one hundred foot cable, or I ask the IT guy, usually at the plant that will, uh, lend me one so I can connect and like I said, sit a bit further away where the seating is much nicer.

Of course, you can walk and see the cables if you need to access the panel physically

Hi, my name is Vladimir Romanov. I am the founder of Joltek as well as SolisPLC. 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

Ice cream wash down panel teardown: Kinetix servos and ABB VFDs

All right, we've got yet another panel. Panels, again, are always interesting to look at, and for me, it's not just the craftsmanship of the panel itself, it's not just the build, it is also the selection of components. It's also seeing the differences between various industries. Of course, a panel that's going into an explosive environment versus an food and bev environment versus a general type of an application versus maybe a smaller machine is extremely interesting.

But also depending on the region, if the panel has been built for Asia, if it was built for Europe or North America, there's gonna be differences not only in terms of the components, but also in terms of standards, how things are laid out, how things are touch safe, et cetera, et cetera

So if we switch over to this post, it was made by the username Daps27, and they say, "Rate my cabinet." We'll look at the pictures in just a moment. They say, "Here's one for all the wash down lads. This is for an ice cream specialty machine." And that's the impression that I had gotten immediately as well.

There's a couple of seals that we'll see in just a moment, but this is a panel for a wash down environment. If we can open this up a little bit better, I don't think there's a way to zoom in, but we have the panel, which is standing very tall and narrow for all intents and purposes. And we've got multiple pictures. We're just going to scroll through them really quickly. We've got side view. We've got the, Rockwell PLC. We've got a Moxa device with a wireless connectivity as well as a couple of ports. I, as I have mentioned in a couple of episodes ago, have recently received a Moxa device, which I'm looking to spend some more time on.

I'm on a crunch for the next events, but will be making a couple of comments on that side, of course. We do have a CompactLogix, which is a safety variation, as we can very clearly tell by the red color. Very interesting to see that there's nothing landed on the IO yet and everything is going to the safety side.

They must be conducting some kind of a validation to get started. It also doesn't seem like there's a whole lot of safety going on, so I'm surprised that they went with the safety PLC because I know those are quite expensive. So unless you're doing a ton of different safety devices, usually not worth the capital.

But again, it depends, of course, on the standards for this specific customer. I'm sure that there was a reason for it. We have, more Rockwell devices as well as an Omron. This looks like a power supply, and I'm not sure what this-- this is also maybe a power supply. Again, it's hard to tell by just looking like that without any context of those part numbers.

We do have a Allen-Bradley contactor as well as a bunch of fuse blocks. So that makes sense. Let's see what else we have. We have a side view of the panel. So again, in wash down environments, you will know that any openings on the panel are extremely sensitive to-- when we say wash down, this is food and bev.

So typically what they do is they, pressure wash, the equipment. Sometimes it's gonna be hot, steamed, and of course, it depends on the industry and the specific of the plant. But you'll notice that all of the knockouts and the connectors are properly equipped with plugs that will prevent or do their best to prevent any moisture from leaking in.

And usually what I've seen for- my experience is that these things will degrade over time. Obviously, you have rubber on the inside of this gasket, and if not replaced in five to 10 years, there's going to be problems within this panel. And the-- we have the other side as well. Looks like we also have a couple of connectors.

The panel itself looks really good. I wonder what are those units on the side. So it's probably just regular ventilation. I can't imagine they need AC inside of an ice cream plant. I think it's just a regular fan. So if we go back to the original picture, we have multiple servo drives. I believe it's the Kinetix series.

I can't zoom in more than that, but it is the distributor, so you have the bus bar at the top. So this is doing some kind of a motion application. We have a set of different drives at the top. So again, not sure why we didn't utilize all the same drives for motion control. There must have been a reason for it.

And actually, I stand corrected. So these are without any face plates. Once we scroll to the second image, we can see that these are the servo drives, and then we have VFDs on the ABB side. Again, why not PowerFlex is probably the question that will come up and, I don't have an answer. Um, honestly, I prefer-- And this is just the general quirks of our industry.

It is generally easier to integrate components from the same vendor as opposed to having a mix and match of different hardware. And of course, it's possible. I'm assuming that all the parameters from the ABB drive would come back over EtherNet/IP into the CompactLogix PLC that we have at the bottom.

The question as to why it probably goes down to price and whatever the integrator wanted to sell them for this specific build. My initial comment. The PLC is all the way at the bottom. These drives are all the way at the top. I'm a little bit concerned that if there's any moisture, any water that gets in, obviously, you're going to have other problems, but your PLC that's sitting down there is probably worth at least twenty grand.

That's just a ballpark figure. Don't quote me on that specific number. It could be more because of the safety, but also the motion side. While your VFDs that are probably around six hundred to a thousand dollars USD are more protected than the PLC. So I probably-- and I guess I typically see a lot of the control components sitting all the way at the top with the VFDs at the bottom.

But again, maybe there was some thought put into this, maybe there wasn't. I think it's, uh, good either way. In terms of connections, we see that everything has been crimped correctly. We have wire labels on every single cable, so that looks good. We have terminals where I would assume a lot of the cables are going to land to be a little bit more fixated.

The general build of the panel is solid as well. I'm not sure what this connector is. Maybe there's gonna be some conduit. Usually, it's not going to be of that shape. Again, um, interesting to see where the mains are going to come in. I would assume it's right here in the side of the panel. But We don't have any more information other than that.

So from the looks of it, none of the field I/O, has been landed yet, but that's sure to come. It looks like it's very interesting to me to see how little I/O there is in this specific system with this many servo drives. So for basically what amounts to, um, seven drives as well as three VFDs, we only have a very small amount of what I would assume sensors coming in.

But for this size of an application and equipment, maybe they're going into some kind of a remote panel with just an Ethernet connection going from this main Rockwell PLC into, uh, something else. So again, curious to see if there's gonna be any updates on the build. Looks great. I don't think, uh, there's any other comments I would make on this panel

Imposter syndrome and advice for a new automation technician

All right, so next we have a career question and of course I love answering these. I believe that our industry generally speaking does not provide enough support to control systems engineers, technicians and it's not a question of unwillingness to do so. I think it's just the, the nature of work is such that there's going to be 20 mechanical guys to maybe one or two electrical guys.

So it's very difficult to find a mentor, someone to talk to, especially in a plant environment where you can very easily lose credibility if you discuss things in the open, so to speak

And so we have the question by the user fluidscholar1527, "Lost at a new job. I am a recently graduated automation eng-engineer, 21 years old, and I just got my full-time job in the field as an automation technician. Pay is decent, but I'm feeling pretty overwhelmed by all the new things I'm having to learn.

I did relatively well in school, but scope of tasks at this new job is huge. I work at a machining plant and their automation department is tiny, one guy except for me, who will quit soon. I need to learn how to program a new PLC plus make robots and also be able to do somewhat plan and participate in installation of new automation solution.

This first three weeks, I've just been following my colleague around, asking questions and doing some courses when he's not available. I'm learning a lot doing this, but also feel kind of useless since I'm not getting any work done on my own. Basically, all production is continuous, and I get very nervous about messing up when I need to do troubleshooting or install new components due to the potential consequences/costs for the production.

Do you guys have any advice for how to handle fear of messing up imposter syndrome as a freshie so that I can actually get some work done?" So as I said, I have a ton of comments on this front. I have been in this exact same situation. I remember when I had first landed my job as a control systems engineer at Procter & Gamble.

This was in 2014 in early April. I knew absolutely nothing as far as industrial automation goes. I had not even heard of PLCs. I have not heard of HMIs or SCADA systems. I studied electrical engineering from a very traditional sense. I studied control systems as I studied renewable energy systems and power systems.

And so I had a lot of book knowledge. I had never actually seen control systems at a plant level in person. And needless to say, the first, I would say, couple of years is where you learn the skills necessary for the future of work. That being said, being over a decade in, I still learn all the time. I know certain control platforms and I know a lot less on some of the others.

I know the principles, but I couldn't, for example, uh, go online with, let's say, a Mitsubishi controller without looking up the documentation, without looking at some videos. So all that to say, it's perfectly fine to feel overwhelmed, especially when you're starting out. I think that the important thing to demonstrate to your peers and to probably the management of the plant that you are doing your best with the, uh, available knowledge and skills, and obviously are researching and following your colleagues and are learning as much as possible.

I still get nervous when I go on site and I'm working with a new customer, and obviously if I'm making bigger changes, I don't want to shut down production because of course it's going to look bad on you. But ultimately, at some point you do need to take the leap. I've been on projects where we had a very finite timeline of two days or three days because downtime is very difficult to access.

And in some cases, I needed to explain why we're taking longer than we needed for the specific downtime. So as you grow in your career, you will also develop your interpersonal skills that when you're, for example, feeling stressed or overwhelmed by making changes, you will then mitigate said risk by explaining to perhaps your manager or someone at the plant, "Well, look, this is what we're gonna do There is some risk involved.

I would like to schedule some downtime for this activity." And as you do it more and more, you will gain confidence, but you will also build relationships with the people on the plant floor so that they know that you're actually doing something that is valuable. They don't take necessarily what you do for granted, and at every occasion that you make-- you do make a mistake, it's only a matter of time, they will basically look over your shoulder and blame you for any of those issues.

So there is this, I would say, skill that you need to develop in speaking with people at the plant, building the relationship with the operators, with the supervisors, with the managers, and conveying that the tasks that you're undertaking are going to be challenging, there is risk involved, and of course, you will be there to make sure that they are supported if there is unforeseen downtime I would say that it is unfortunate that someone is leaving or, you know, one guy except for me who will quit soon.

This is a scenario that I see all the time. So in many instances, either for retirement reasons or simply getting fed up getting calls at 2 AM from the plant, people are leaving our industry. And there's usually very little transition from the guys who are leaving to the younger guys. There's obviously no time.

Nobody wants to pay for documentation. That's just the unfortunate reality. So people keep a lot of the information in their head. It takes a long time to ramp up some of these new people at these different plants. And therefore, I can only appreciate that this is going to be a problem. The other item that I will mention, the expectations can be quite high. And so if you had someone at the plant for twenty-plus years that has been handling some of these tasks, I would assume to varying degrees of success, it is unreasonable to expect a brand new person within a couple of weeks to be able to make changes to PLCs, HMIs, SCADA programs, robotics.

All of those or each one of those could be a career on its own. You also need to make sure that you advocate to your bosses and or management in a way that makes sense that you need more training, you need more tools. Whether that's getting the right like laptop in place, getting the right VMs in place to be able to access some of this equipment.

But ultimately, it takes a lot of time to build up to those skills of knowing all of these systems. And they should expect, hopefully they understand this as well, that once this person leaves, it will take some extra time to figure these things out. But again, my advice is as long as you're spending the time diligently, you're not gone on two-hour lunches as an example, they will understand that you're doing your best, you're learning.

The time to repair some of these issues will hopefully diminish and that as long as you keep applying yourself, I have absolutely no reason to believe that things will not improve.

Which HMI and SCADA platform to learn in 2026

All right, we got a next question on the learning/technical/career path maybe side. Very interesting to discuss the visualization components of our industry

And so this user by the name Des Mateo is asking which HMI and SCADA platform is worth learning in 2026? Hi everyone, which HMI SCADA platform would you recommend learning in 2026? I often work with Win, Wintek and Siemens, but I'm realizing that they can be somewhat limiting when it comes to more demanding applications.

I'd like to learn a platform with a rich set of graphical libraries, modern UI components, advanced visualization capabilities, etc. There's an increasing demand for highly advanced and sophisticated HMI screens, and I'd like to understand which platform would be worth focusing my time and energy on.

PC-based solutions are absolutely fine too. I also develop more general purpose software, so I'm comfortable working with web technologies and similar environments. What would you recommend and why? And I'm actually-- I'm curious what people are saying. So Ignition is good and free. That's what I was going to recommend.

It's like a thirty-five-hour course on their website. You can download it with a two-hour trial. Uh, infinitely resettable two-hour trial. Yes, seconded. Ignition is great. Uh, just start with Ignition. How can I download? Have you a link for that? Ignition for sure. So it looks like many people have already made the recommendation.

There's a couple of points to be made. So I want to share, I would say, like my experience and general opinion on this what I would recommend, or I guess what I would ask this person is why are you looking to learn these platforms, right? And they mentioned that I would like to, um, experience something that is a bit more advanced, a bit more cutting edge.

I would argue that it is not the right reason to learn something just because it's more advanced. I would start by figuring out what are your customers asking for and have deployed in their facilities if you were to learn this new platform. You can go ahead and watch the videos at, uh, Inductive University.

I would recommend that, right? Because it's free. But ultimately, if there's no means for you to go and practice some of those deployments in real environment, it becomes, I would say a waste of effort. And it's not generally wasted because obviously, hopefully you would have picked up some items that are applicable to whatever it is that you're doing.

But in the ideal scenario, you can, having a lot of experience already with HMI and SCADA, land a project that lends itself into learning this new platform. Because I can tell you, if you're capable of developing systems on Wintek and Siemens, you should have absolutely no trouble transferring those skills to Ignition, to the Rockwell suite, to AVEVA, and then there's going to be a ton of other different platforms that may be more modern.

But once again, if you just learn sort of in the textbook format, may not nee- may not meet your need to work with a specific customer. So there's an increasing demand for highly advanced and sophisticated HMI screens, and I'd like to understand which platform would be worth focusing my time and energy on.

This is a very revealing, I would say, piece of information as well. So I believe that with AI, the actual UI components. You say modern UI components, this has been commoditized. I think that AI and people in general have been and will be building the actual UI and visualization a lot better because now you can ingest best practices from the web and software side.

Where I think the challenge still lies is in the back end. Typically, when you talk about HMI and SCADA systems, you have historians, you have networks that are a big component of that as well, but you ultimately need to build a back end that solves a problem for that customer. And whether that's a batching system, whether that's a system that tracks the throughput or maybe OEE type of metrics.

So you're starting to think as to how to build out those database components. You're starting to think about how do you organize the actual database. Is it the traditional type and MySQL, for example? as opposed to relational databases that have been making a resurgence. So I would also spend some time I think that if you're looking to just have a nicer screen, you will find that in most modern packages, and you probably can very easily go towards Ignition or like I said, many other brands will have a web-based, if you will, development suite at this point.

Even Rockwell has, uh, Optix at this point. That being said, I think that the actual skill set and the challenge is not going to be on the UI side. It's really going to be in developing really solid backends. So I guess to answer the question a little bit more bluntly, I would definitely do the free training from Inductive Automation to learn Ignition.

I would look at a few other platforms. I would definitely consider looking at Rockwell as the alternative since you know Siemens already. Maybe it will be an opportunity for you. AVEVA has been pushing their platform, I would say, more aggressively than in the past years, so something for sure to consider.

But ultimately, I would really spend my time trying to figure out if there's an alignment for a next project where you can utilize the platform that you're looking to learn.

Ladder logic vs structured text vs function block diagrams

All right, so the last question for this episode and this week, goes back to the programming language debate that we've had multiple times, and I think I've even answered this, I would say at least a dozen times publicly as well as on video. But of course, maybe there's some nuances and some new interesting items that we can talk about And so this question comes from the username Zernak, and they say, "What PLC programming language is actually best/most used in industry right now?

I'm studying automation engineering, and so far we've mainly been taught ladder and function block diagrams. I'm about to start an internship at a company where they use almost exclusively structured text, which surprised me a bit. Because of that, I've started learning and practicing ST, structured text, in my free time, so I'm better prepared when I start.

I always thought ladder function block diagrams were preferred in industry because they're easier for electricians and maintenance technicians to troubleshoot. But I've also heard that structured text is becoming more common, especially for larger or more complex programs. For those of you working with PLCs, what do you mainly used, uh, what do you mainly use?

Is structured text becoming more common, or does it depend on the industry and company? And if you were starting your career today, which language would you focus on mastering?" So once again, I've answered this question multiple times. I want to scroll down and see what people are saying. "Always the one that fits the logic best."

This is really a, a terrible answer, and I hate the fact that it has been so upvoted because as I've mentioned in the past, you can use almost any PLC programming language to create the logic for, I would say, generally speaking, broadly speaking, eighty percent of the tasks. So there is no "the best one that fits the logic."

Um, you can use any language, so it's really up to you to figure out what makes sense. Some languages, granted, will fit better in terms of how readable they become for the human, but it's not to say that they are technically better for that task in terms of the actual underlying function. The language itself or the visualization of the language is just a visual representation.

It all compiles back to binary, so it doesn't necessarily impact the function. "For the last time, you need to learn everything. There's no such thing as useless stuff in the field. You will eventually work on equipment that's older than you and equipment that came out of the market after you graduate." I, I guess, sure, that is a point.

Obviously, the question for that person is trying to understand what to make a priority. "Master programming in general, and suddenly all the languages are perfectly fine to use." That's good advice. "Depending on the industry PLC platform and where you're based, ladder is still very common and is many companies' preference.

Some companies, especially in tech-adjacent sectors or startups, are almost exclusively structured text. Some PLC platforms like Beckhoff really shine in structured text." So let's scroll back up, and I'll give you my thoughts.

So when I graduated, I had studied electrical engineering and I had extensive courses on assembly as well as C or embedded systems programming. So when I graduated and went into control systems on the industrial side, I had no knowledge of ladder, of structured text, of function block diagrams. And for me, it was not a natural transition going from again, embedded systems.

I did a lot of Arduino and Raspberry Pis, as you can probably see by the channel in some of the early days, into ladder logic. So ladder logic never came intuitively for me up until, I would say, five years into the career. And the way it didn't- it wasn't intuitive is in my head, I would always do the conversion that this is what I would create and see, therefore, here's the equivalent in ladder logic.

So obviously speaking, for me, structured text was a little bit more intuitive. However, I worked for employers that were very strict on the implementation side when it came to PLC programs and only wanted things done in ladder logic. So it took me a little bit of time to make the adjustment. Again, it's not rocket science.

Once you start realizing how things fit together, it becomes quite simple. So my general opinion is you will be probably in a position where you're not going to be able to select the language that you would want for a specific application. In almost all cases, it will be dictated by the customer. You can probably ask a senior engineer what the customer would prefer, and typically that will be your reference as to what you should be implementing in.

I've very rarely seen environments or had the opportunity to just blatantly implement the logic the way I wanted, even though you'd have the IDE access and obviously you can build in whatever. The second comment is it does depend on the company and industry. So if you're going to the process side, if you have a lot of P&ID diagrams, you will find a similarity in, at least in the visuals, how that relates to function block diagrams.

Therefore, it's very common to see PID loops, for example, from flow meters going back into pumps be built in function block diagrams. So anything that's on the chemical side, anything that's batching in food and bev, anything that's pharma related will be heavily implemented in function block diagrams.

That's not to say that you cannot build it in ladder logic or structured text. It is just visually easier for you to see those transitions and thus troubleshoot in the field. Similarly, as you have mentioned, ladder logic is known to be easier to visualize, especially in discrete environments. So I've already expanded on this historical piece But basically in the past, you had electrical diagrams that were built in a ladder. Even today, you have a lot of companies still doing that, but you had conditions where, let's say, if this relay is made, you can expect this valve to basically toggle. Therefore, if you're going to transition that into a PLC. Instead of having the relay, now you have the PLC output that goes into a valve, you can make that same ladder representation very easily.

And so when you look at the diagrams and then you look at the PLC program, it becomes very intuitive to see those applications. You can build the same condition in structured text, and it is also very easy to implement in structured text. There's no question about that specific example could be built in all languages and will accomplish from the technical standpoint the exact same outcome.

Like I said, it will boil down to someone is looking into that program and is looking to understand what was done. In ladder logic, it is, I would say, more challenging to create complexity than it is in structured text. And what I mean by that is in most instances, when you're building ladder logic rungs, they will be visually sequential and sometimes in parallel, right, if you have branches.

But in structured text, you can make fairly challenging calls. You can create functions, which you can also create in ladder, but are more difficult to create in ladder, that will confuse anyone that comes after. Therefore, it's not necessarily that ladder is easier to troubleshoot, it's that it is easier to make simpler because of the restrictions on the visualization in ladder.

And conversely, it is easier to make things more complex in structured text. Therefore, I would say for general purpose applications, it has been utilized less. There was a comment left when it comes to other systems. This also goes back into some historical discussions, but some of these smaller PLC manufacturers and, you know, Beckhoff was mentioned.

And when I say smaller, it's not necessarily that the company is small, they're also multi-billion dollar giants. They have a smaller market share in certain markets, therefore they go after more niche or more specific applications that are going to be high speed, that are going to be designed in a way that I would say involves highly complex functions as opposed to just general state machines.

Therefore, a lot of the developers in those platforms don't have a choice and make it easier for themselves to use structured text as opposed to ladder logic. And again, we can get into some specific examples, but it boils down to that industry and those niche applications do shine with structured text.

There's thus more momentum, there's more documentation, there's more people sharing documents. So if you work with those platforms, what you will find is if you go online, there's more documentation on structured text as opposed to ladder logic. And similarly, if you work, for example, in Rockwell, especially in North America, you will find that there's a lot more information on ladder logic as opposed to structured text or some of the other languages.

So you also need to be cognizant of that. What I would be learning, as someone mentioned, I think it's a good idea to have a general understanding of all the languages, but more importantly, you need to master the foundations of good programming. You need to understand how the logic flows, how it gets executed.

Basic, I would say, don't even start to try and master, let's say, motion commands or batching processes. Start to understand the basics and fundamentals of your PLC programs, and then any language will be a lot more intuitive. If you're going to start with this employer, obviously you don't have a choice.

You're gonna be going and implementing in structured text. So do your best to learn as much as you can, but make sure not to forget your knowledge that you have acquired on the ladder logic side. Maybe it will come in handy at some point in time in your career. I think it's always good to have a balance and just as they, uh, give you advice in your career, so go deep in one subject and then be, I would say, a generalist in others.

In this case, you have the opportunity to master structured text. You will probably be exposed to a lot of previous programs, but also be cognizant of other languages in the PLC programming world. So hopefully that answers the question. Again, it really, it depends. I think that you have a good opportunity to master structured text, which is what I would focus on.

But ultimately, also ask questions as to why, uh, this was implemented in such a way, and make your own reasoning as to how you would do it in ladder logic or function block diagrams.