PLC Brand Debate: Rockwell, Siemens, Schneider, or Something Cheaper?

How's it going, everyone? Welcome back to the next installment of our conversation and discussion of the most up-voted posts and comments in our industry. Today, we're gonna be tackling very different topics. As you can see by my background, I am once again traveling, doing some work on site, doing some commissioning work, programming a variety of different systems on Rockwell Omron this week, on Ignition, as well as Red Zone.

So a lot of very interesting exposure. Of course, happy to chat a little bit in private without revealing any customer information. So if you want to reach out, if you want to have a conversation about industrial automation and/or manufacturing, don't hesitate to reach out to me by either

Can you power a Point I/O over PoE?

leaving me a comment or reaching out on LinkedIn. Without any further delay, let's take a look at some of the most up-voted posts that we have this week. And the first one comes from the username 98theclarin98. And the user says, "POE

powered Point I/O bad idea?" We do have an image of the contraption, uh, which is the Point I/O powered over Ethernet. "I'm an IT network administrator learning PLCs after I fixed our OT network for our automation engineer. I figured out I could POE power a Point I/O with a Tycoon Systems 90-watt POE splitter set to 24 volts.

Before I actually hook this up to my PLC as remote I/O, any reasons why this wouldn't work? I'm trying to consume alarm outputs and remotely press the reset button on a Century refrigeration compressor skid remotely from a 5069L320ER. This is the current state waiting for a PLC to connect. My switch reports it's using 4.6 watts."

So the first impression that I have is, of course, this is possible. You can connect a Point I/O as shown in the image over Power over Ethernet.

And for those who are not familiar, what you will typically find is an RJ45 connected cable that you can buy normally in bulk, you can buy on a spool, but it normally carries eight different conductors. There's going to be four twisted pairs. Again, there's going to be different ratings depending on the CAT category of the cable.

For the purposes of Power over Ethernet, one of the pairs is going to carry forty-eight volts, and typically what you will find, the Power over Ethernet hardware is going to allow you to connect a device in the field by running a single cable. So this is extremely practical when you have camera systems, for example.

So if you're going to install cameras in different areas of the building, you run a single cable to the camera, and you're pretty much done. In other instances, if you have, again, in this case, IO, you need to run power and you need to run the Ethernet communication cable, which complicates things. Now, of course, there's some caveats and gotchas when it comes to using Power over Ethernet.

As he mentioned, there is a rating that he took, which was four point six watts. Generally speaking, the conductors that you will find inside of an RJ forty-five or Ethernet cable aren't going to be able to carry a ton of load, which usually means that you will have a switch that is going to be rated for Power over Ethernet, and every single port is only going to have one single device.

As I've mentioned, very applicable in vision systems or cameras, very applicable in access points, for example. So if you have a large area to cover with Wi-Fi access, it is common to have Power over Ethernet access points. It is something that is present in our industry. I have encountered examples of Power over Ethernet when you have highly distributed devices, but also when you have a constraint on the number of conductors that you can carry in any given medium.

And usually, as I mentioned earlier, that's going to be slip rings that allow you to pass current through. So if you have applications where you have motion that will constantly rotate, for example, so you can only send so many conductors, and typically it would be your Ethernet and then your power. And of course, on the other side, you generally can split it back out, but you can leave it on that same single RJ forty-five or Ethernet-based conductor.

It is also very often used in applications in oil and gas where you have very small types of controllers. You typically have one or two devices attached to them, and thus having the controller be a single point of failure without any other hardware makes it a little bit easier to wire in the field.

Why running 24 volts is usually the simpler answer

Now, my general comment when it comes to Point IO, when it comes to general plant hardware, unless I'm missing something, it should not be a heavy constraint to be able to run twenty-four volts along the wire for this specific application. So what he has described is that Let's see here. I could PoE power a Point I/O with a Tycoon systems splitter set to 24 volts.

Again, that's obvious that it can be sent over that wire. I'm trying to consume alarm outputs and remotely press the reset button on a Sentry refrigeration compressor skid remotely from 5069L320ER. So my first question would be, obviously this is fine, 5069 controller is compatible with Point I/O. Does the refrigeration compressor skid not have any voltage available for the Point I/O?

Again, you can power or you can step down the voltage if it's one ten, if it's two twenty, with a very inexpensive field device mounted hopefully next to this compression system or inside of this compression system. The Point I/O module regardless would typically need an enclosure, so you will be already adding this either to a panel or you will be building a system that contains this hardware in which you could also land the power supply.

So to me, this is a really strange question. And again, with someone that's in IT, obviously these devices are a lot more common. It seems to be that we are reinventing the wheel a little bit. And if you truly wanted power over Ethernet I/O, there are solutions on the market that provide this capability. So one example I have played around very recently with the Opto 22 Groov Rio, the new model.

The Opto 22 groov RIO as native PoE I/O

It provides the ability to power the device with power over Ethernet. Not only that, you can also consume the tags and the remote I/O points from that device into an Allen-Bradley PLC. So there's really no need to create this type of a, I would say, Frankenstein monster in this, uh, honest opinion to solve this problem as it has already been solved with perhaps a different piece of hardware

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

Trade school PLC courses vs the electrician route

We've got a very interesting second question. As many of you may know, I have spent many years working on RSLogix 500, and I still believe it is an excellent software to learn PLC programming and industrial automation. And there's a couple of reasons for that. Of course, I've articulated many of them on the, uh, Solace PLC website as well as posts.

But really briefly, RSLogix 500 exposes a lot of very raw approaches to programming. Not everything is typed. You need to understand registers very well. You need to understand addressing very well. You can very easily fault out not only your program, but the hardware as there are no safety limits out of the box.

Therefore, it is an excellent tool to get into our industry and learn how things are still done, but have been done for multiple decades before we got the more modern IDEs from a variety of different vendors. But in any case, this user s- by the name of Involuntary M says, "Route your take, suggestions, and thoughts.

Currently at a trade school and finished a motors class, and following that, a PLC course. Fell in love with the concept more than with the traditional electrician work we've been studying and doing for the last few months. Feels more mentally challenging. Decided to take some advanced PLC courses to continue get more firm grasp on things to eventually work in said field.

Might sound like a dumb question to ask, but would going down this route be something you'd suggest to someone or your past self over a more traditional commercial electrician route?" Now, this is a good question, and I've actually answered and gave my opinions as to would I go into this industry with the knowledge and experience that I have now of over 12 years.

So just a couple of thoughts, and you can read my comment on Reddit. The short answer is, no, I would not. I'm not going to spoil the read. If you go on Reddit and you find my username or if you want to reach out to me and have a conversation about, about that, feel free to, uh, do that as well. But what do I recommend this individual?

So again, you basically have two choices. You can become a residential electrician, or usually you could pursue the PLC programming but become more of an industrial technician, if you will, or automation tech, uh, depending on the title, of course, of the job that you land. So I have a couple of thoughts.

Number one, I truly believe that education is never lost in the sense that the time that you invest in yourself in, uh, life in general is not going to be wasted. So if you do decide to take some of these courses and learn additional skills, even if you decide not to use them or perhaps your first employer does not value them, it doesn't mean that they will go to waste.

It means that you will push yourself further within that class. You will learn a new skill that is maybe unfamiliar but also more challenging, which will allow you to grow, not perhaps, maybe not immediately after joining, like I said, the first company- But it will open up doors to future opportunities.

Master the fundamentals before sequencers and motion

What I will generally recommend is that if you're learning electrical systems, make sure that you learn foundations before moving on to anything else. What I often see is that people get excited by all the different features of control systems that are a lot more advanced, and that would be, for example, sequencers, that could be your P&IDs, it could be your motion control, it could be safety systems, and they could be great puzzles, and you will get there.

That being said, if you don't master the fundamentals, what you will very quickly realize is that in the field, in actual control systems, 90% of the time you are dealing with XICs, you're dealing with XIOs, you're dealing with sometimes more sophisticated Boolean logic. But ultimately, you need to learn how to read not only ladder logic, right?

So ladder logic is just syntactic sugar when it comes to software development, but you need to learn the approach to ladder gates. You need to learn how to approach reading electrical diagrams. You need to learn the fundamental skills of being able to go inside of a panel and understand what is tied into it.

You need to be able to learn how to read documentation, how to extract data sheets, how to work with parameters. You need to learn the basics of control systems. You need to understand feedback loop principles. You need to be able to program. Like I said, focus on learning XICs, XIOs, OTEs. Learn how, the image, as I've mentioned a little bit earlier, is RSLogix 500.

Very important to understand different data types. Basic instructions like moving the registers around, overriding different registers, understanding what happens when you latch and unlatch different bits, but at the same time implement an OTE. Understand what happens when the PLC scans the programs regardless of the language of choice, and thus master the fundamentals before moving to anything else.

And so what I would recommend to take a step back if you are studying in a program that is offering different courses, again, and this is just my opinion, pick the most difficult courses you can find to challenge yourself because you will learn things that may not apply in your first job, but that will push you to understand systems at a deeper level.

Pick the employer and the mentor, not the title

Number two is, in the current market, look for a good employer more so than what you would like to do. And what I generally mean by that is if you find the right employer, if you find the right mentor within that company, they will push you in the right direction. They will give you the right opportunities.

They will show you to an extent where you should be going based on what you are delivering, based on what you're capable of, and based on your growth. Do not necessarily disqualify yourself before you have graduated from some of these opportunities

Why PLC programming gets classed as a maintenance skill

The next question reveals an interesting reality about our industry, and I definitely resonate with what this user is saying. And so the name is Rob Budge, and they say, "Why is programming being classed as a skill?" And this is a very strange title. Again, I don't really know what the title means, but obviously as we read further, it is clear what, uh, the user is saying.

"I'm almost 30 years in this industry as a full-time programmer. I am now considering a change of employment. Virtually every job that's looking for PLC or SCADA is a maintenance or electrician position. It still blows my mind that big companies that are heavily automated don't feel the need for a programmer and that PLC falls under the role of maintenance electrician.

It does make a lot of sense when we have customers requesting we only program in ladder logic and avoid the use of AOIs. Are OEMs going to be the last high-level programmers as facilities and systems integrators just class it as an electrician skill?" And so before we start getting into the discussion of what should an engineer or a programmer versus what should a technician be delivering and doing, the very important point here is that our industry, or manufacturing in general, is looking at PLC programmers, or I would say engineers, as liabilities, right?

And I've had this sentiment for many years as well. I couldn't necessarily articulate it well enough, but what I do commonly see is that it is treated as something that is very fundamental. What I have come to appreciate over the years now, over a decade of experience, is that true programming of automation and control systems is incredibly difficult.

And the difficulty does not lie in just basically mashing on keys and producing ladder logic that is capable of running the machine. The difficulty comes from creating equipment that is structured in a way that is reliable, that is maintainable, and that is expandable and connectable. What I mean by all those acronyms or, or words or buzzwords, if you will, from our industry, is that building true control systems that work for the high-end manufacturers is very difficult.

Reliable, maintainable, expandable: the real difficulty

It is very easy nowadays, through the aid of AI perhaps, to slap some ladder logic together and create a spaghetti monster, if you will, of logic that will work. It is relatively I would say simple to take a small skid with a good enough narrative on how it needs to function and put something general together, and it will run.

The problem in our industry is that you are very often found in front of equipment that was designed that way, and you will very quickly realize that number one, that equipment does not run twenty-four seven, three six five. That equipment is very difficult to troubleshoot, and when you start going into that program, there's going to be tags from the program scope going to the global scope.

There's going to be messages passed to other areas. Very difficult to troubleshoot. Very few rungs are documented. It is very difficult to decipher what the original programmer was thinking, but it's also very difficult to augment that specific control system. The reality and the nature of our work is that inevitably in one, three, five, ten years, someone will need to make changes to that system.

And it's not only replacing the control system, it could be adding a second- component, it could be modifying to meet a different need of the manufacturer, therefore creating something that is thoughtful for the next person is very difficult. And I do share the sentiment that there are a lot of manufacturers that simply don't understand the craft and don't understand the skill and are ultimately paying the price that someone is going to be charging quite a bit more to build out that software.

The technical debt a plant takes on

Now, I have very rarely seen technicians and maintenance personnel that will design programs from scratch. They will make modifications, don't get me wrong. They will go online and some of them will troubleshoot and understand the skills that engineers typically have, but it is very rare for them to carry out larger projects.

They are mer- very much so focused on small system troubleshooting. They will execute certain tasks. And of course, there are going to be exceptions, but I would say that those exceptions are incredibly rare and what normally is going to happen is the facility that neglects the control systems will ultimately pay the price because of the technical debt it is going to incur by not having that key person support and help the plant over the long run.

So again, my general sentiment is I understand where he's coming from. I have experienced the same. I believe that there are companies that truly understand the need for highly skilled programmers, PLC developers, whatever you wanna call them, at their manufacturing plants, but many simply disregard that skill and I believe that many of them are paying the price.

If you show up to a variety of different facilities today, you will find that they have a ton of listings on the technician and maintenance side, but once you start asking questions, you will very quickly realize that the plant is in a very poor state of affairs.

If you had to build a factory tomorrow

The next question is a very fun one. For those that haven't talked to me on one-on-one may not know that there was a time where I was going down the path of purchasing my own manufacturing factory. I am a big, or I guess I am very fond of our industry. I believe that things can be made better. I would love to one day own my own factory so that I could automate in the way that I would like.

And of course, this question is going to be extremely topical, so it comes from the username SeniorGuide2110. And they say, "If you had to build a factory tomorrow... I saw a similar question was asked, and I know it's highly dependent on situation, but if you had to build a factory tomorrow, what controller brand are you going to use?

After a little time in this job, I think I'm picking AutomationDirect, but I'm curious to hear from others." Like I said, very interesting question, and I'm going to maybe pick two paths, right? So I'm going to answer this in two distinct ways, and I'm going to define the variables for both of them. So if I was building a factory tomorrow, as I have mentioned, I probably would be acquiring a small manufacturer and then coming in with the intent to automate said facility beyond what it currently is doing. I had looked at a few factories within the purchase price of $10 to $20 to $30 million, and ultimately all of them lack automation, therefore there is an opportunity to come in, revamp what they are doing, and of course create some automated systems to make the sales or productivity of the plant better.

Now, I haven't pulled the trigger on any of those opportunities. Like I said, some of them went into due diligence and other things were discovered. A business, even a manufacturing business, is not purely based on automation. There's of course a lot of different variables that go into this. But the first question, what would I be using in terms of control systems to automate that facility?

Now, my personal experience has been on Rockwell, has been on Siemens. I know Phoenix Contact, Opto 22, Omron at this point fairly well. I know CODESYS. So I'm comfortable in a variety of different control systems. Obviously, I have not experienced all of them. I know that there's the existence of even FANUC PLCs.

There's going to be a lot of other flavors of controllers that could be cheaper, could potentially be better. Now, the question is, I have a very, let's call it small facility, all things considered. I'm looking to automate the production. So what am I going to choose on the plant floor? It's probably going to be conveyors.

There's probably going to be a lot of signals passed between equipment. So if it's CNC machines, if it's deburring machines, if it's a food production facility, there's probably small machines that are all standalone with either controllers or PLCs or PCBs even, right? So printed circuit boards that are executing some kind of a control system type of a sequence.

Ignition and CODESYS for a small plant you own

So the question is, what would I implement to tie all of that together? Number one, I would absolutely be implementing a SCADA which allows me to understand the overall functionality of the plant floor. And thus, I would be choosing Ignition, by Inductive Automation as the platform of choice because it allows me to connect to a broad spectrum of different devices.

It also allows me to build pages in the web that are very inexpensive, I would say, all things considered. Therefore, I would be deploying a server which, once again, would serve for other purposes. Number two, because it's a relatively small facility, I would be strongly looking at CODESYS as the software of choice and the reason for that, of course, is number one, it's inexpensive; number two, it's easy to work with; and number three, it is relatively intuitive when it comes to developing some of these smaller systems as there wouldn't be requirements of process controls and very complicated motion controls.

Choosing hardware on local support, not spec sheets

Therefore, I think CODESYS would definitely fit very well there. Now, CODESYS can be deployed on a variety of platforms, so of course the next question becomes which hardware manufacturer would I be working with? This is where there's a lot of different opportunities and obviously we can choose WAGO, we can choose Opto 22, we can start choosing PLCnext.

And so now we start to think about who is the supplier of that hardware, and this is where the more difficult conversation becomes as to who do we want to prioritize for our facility. So number one, I would prefer to be as hardware agnostic as I possibly can because I have witnessed the shortages of hardware for a variety of different vendors.

Therefore, I believe by choosing CODESYS It actually opens up the door for me to select any one of those vendors. Would I select one over the other? And if so, which criteria would I use? Number one, I would be working with the local representative as well as reaching out to local systems integrators.

Despite me owning potentially a small manufacturing business, I realize that I cannot be the owner of that manufacturing company as well as the programmer and systems integrator for that manufacturing company. So I would try to reach out to people in the area, understand what they are using, understand what they're recommending, understand what the relationship has been for them with the local distributor as well as the manufacturer of that equipment, and making my decision primarily based on that.

And so what I generally mean is that if there's an overseas company that manufactures controllers but has absolutely no presence in the region that I am in, it would be a very difficult choice for me to make as I know very well that if something does go wrong and I do need to make the phone call because I cannot troubleshoot whatever piece of equipment, it is going to take a little bit of time before it gets resolved, and obviously the lost production would be fairly significant.

I would also be looking at components that are more cyber secure because I would be establishing the IT, so to speak, connection to the OT side relatively quickly for the reasons that I have mentioned before, and I want to make sure that it is done correctly. So I would be prioritizing OT and IT infrastructure very early.

What changes when you advise a C suite

So I would be talking to the OEMs that understand those principles and bridge the gap across the entire ISA stack Now the second answer, and if I were working with a manufacturer that brings me in to the site and a new direction, if I'm talking, for example, to the C-suite, if I'm talking to the VP of engineering or VP of operations, that is a completely different question.

Which platform are we going to choose for our facility? It could be a multi-million dollar plant, it could be a multi-billion dollar company with multiple sites that will be affected by this choice. So of course, my decision is going to be very different depending on going that route versus my own $20 million factory.

And so in this instance, I would be very reluctant not to choose the top players in the industry for a number of reasons. We have the Rockwell, we have the Siemens, both of them have very reliable hardware, both of them have very reliable networks of individuals that can come in and help with the site, but also integrators, distributors, and other parties that will support the equipment.

So I will be looking at what does the process that we're looking to automate look like. I will be considering what is currently in place because it is very rare that you're standing up a completely greenfield site without the prior expertise of any other facilities within your portfolio, and you're going with something completely brand new.

So I would be considering what is currently in place, what is the history of the manufacturer, what is the skill set of the various assets? And when I say assets, I generally mean people that have deployed those systems. Which platforms do they understand? Do they understand Rockwell or Siemens better? Do they come from a completely different background?

Do they come from the... For example, pharma industry is going to be very Delta V heavy. So completely different platforms and selections depending on the industry, the skill set, the background of the company. I would need to understand their appetite for data. What kind of a SCADA platform are they going to use?

What kind of an MES solution are they going to use? So there's going to be a list of different questions, and I would say that the short answer is we would be prioritizing the two or top three platforms that are heavily utilized in our industries, and those of course are gonna be Rockwell, they're gonna be Siemens, they're gonna be Schneider.

Is a two year controls associate degree worth it?

And maybe, again, depending on the size, we may evaluate some of the other platforms with the general consensus that they're probably going to have a little bit less of a say or win as opposed to the top three.

The next question is all about education, and as I've mentioned multiple times, I don't think that education can be a waste of time. You always improve yourself, you're gaining skills, but of course, there's a lot of different options, so we do want to discuss what kind of education we should be getting at what point in time based on our goals.

So this user by the name of FinFan7836 is saying, "Is a two-year robotics controls engineering Associate's degree worth it if I'm already working in the field? My local college offers a two-year associate's in robotics and controls engineering. However, I already work as a facilities operations technician for a FAANG company.

Will this give me a leg up in further progressing in this industry, thinking controls engineer or even chief engineer, or is it a waste of time because I already have a five-plus year of experience in the field? Thanks. So again, this is just my opinion. Number one, companies still favor degrees over experience.

If you go on the majority of listings, even from companies where the CEO or the C-suite executive will claim that they only look at experience, and they look at the resume and try to understand the skills. The reality, at least from my perspective, is that the first gatekeeper is going to be somebody in HR that will automatically scan your resume, and if you don't have that engineering degree, they will reject you.

Of course, if you're going to stay in the same company... And again, I use that a little bit in air quotes because there have been many layoffs inside of FAANG companies even, where individuals with a lot of experience have been laid off. And I would anticipate there still will be a lot of turmoil as a result of AI and data centers and, of course, just general booms and busts, I would say, of the markets.

So with that in mind, I would definitely recommend continuing to educate yourself. If you have the opportunity, if you have the desire, as well as the time to invest, I would be looking at a full engineering degree. I know that the associate's may seem interesting. I do believe that those degrees carry a little bit less weight.

And of course, the engineering degree could be a little bit longer, but if you're willing to commit to the profession and the direction, I do recommend an engineering degree. And there's going to be engineering degrees of different flavors. There's online schools. There's in-person schools. How much do you value all of that, of course, boils down to personal preference and your general life, I would say, as many of us are extremely busy, whether that's with kids, whether that's with hobbies, and you cannot simply have everything. You do need to pick and choose. But I do believe that an engineering degree will give you a leg up in this specific opportunity, probably within your company as well, but ultimately help you advance your skill and hopefully learn something new that you can bring to your employer and thus demonstrate not only a willingness to learn, but also the fact that you're able to provide value in new ways that you previously could not

What iOS app design taught me about HMI design

We've got a last question, a very interesting, maybe slightly technical in nature, but I do enjoy this conversation as well because I have been developing HMIs or UIs, if you will, or UX for many years. And those that don't know, I do want to tell maybe a brief story. So before I joined Kraft Heinz, this was back in 2017, there was a period of time when I was building a lot of iOS applications, and at the time, the Swift language was the...

Basically, it was the language released in addition to Objective C to develop iPhone apps, was new, and therefore, a lot of features were still in relatively, I would say, rough shape. And so a lot of them were borrowed from the Android side. And I still remember that despite coding in Swift, I would be using Google's best practices for designing UI and UX on different screens, even within the iOS or iPhone ecosystem.

And what I'm telling you this is that I have learned the best practices of developing UI and UX that I brought back into the industrial automation side from developing iPhone applications because it has very well explained why you want, for example, buttons of a certain size, why do you want to create shadow effects on buttons, and why you want to remove them after they have been pressed.

All of this has been very well documented in the mobile phone industry because the UI/UX is incredibly important for them, and they take a lot of pride. There's even awards for the best UI and UX and application design on the iOS side. Therefore, I highly recommend those who are doing a lot of HMI development in the industrial automation space to go and look at some of those specs.

Of course, our industry also has different standards

Native HMI graphics vs importing from other software

Some of them have been developed by ISA. There's going to be other publications out there. But in any case, the question that we have in front of us comes from the username CardOK1316. "I have a few questions about HMI design. When designing an HMI, do you usually design the graphics in other software first and then import the image assets into the HMI software?

Also, the ISA101 design standard seems to lean more towards continuous process manufacturing, like production lines. I build standalone machines, so ISA101 doesn't seem quite right for my projects. I mostly just reference it for color schemes. What do you think?" So as I mentioned, I do have a lot of opinions on the side, so let's answer the questions one at a time.

So number one, importing graphics usually, in my experience with a variety of different platforms, tends to lean towards poorer performance. And the reason for that is, of course, it depends on the format of the graphic, but it doesn't scale very well. It becomes distorted. So now you're spending a ton of time designing pixel by pixel in some kind of a different software.

You're importing these large files. You're losing transparency, and it becomes a challenge. So usually, in my experience, once again, creating native graphics to that piece of software is going to yield better results. Of course, the general answer is it depends. So if you need to import a graphic that comes from a drawing, I'm not a huge fan of those, but they can work in certain applications.

But you can take the entire PNG or, uh, vector graphic, import that in certain software. You can, again, if you resize it well, if you keep the constraints locked, it's not going to get very distorted, and those are going to be generally good applications. When it comes to simple For example, if it's buttons, if it's gauges, I prefer to use the native graphics as long as the application doesn't look very tacky.

And you've all seen probably the HMIs where all the graphics that you get in the basic pack are being used and are thrown on the screen. So again, you try to add a little bit of uniqueness to your design, but at the same time, if you start to develop too many graphics in external software, number one, it becomes very tedious; number two, it usually bloats the HMI with the unnecessary files; and like I said, number three, if you start making changes, usually it just doesn't look very good once the graphics start to get distorted.

ISA 101 on standalone machines: adopt it selectively

And the second question is around the ISA 101. So again, for those that don't know, ISA 101 is basically high-performance HMIs. And who said that they are high performance? Of course, ISA assembled a number of individuals who are technical in the field, who understand the requirements of HMI design and SCADA design, have been in the field for many years.

You can probably look up who were the authors of the specific standard. That being said, it is still a standard that is not enforced in our industry. And what that generally means is that you can adopt the standard to the degree of your choosing. You may select certain elements that you enjoy from that standard, and you make that a standard of your design or your company or organization, and you may look at other elements of the same standard and simply decide that they are not applicable for your specific use case.

And I personally, again, I like some of the elements of ISA 101, and I don't like the elements of some of the components of ISA 101, and I'm not going to get into all of the details and nuances as to why, but some of that does relate because it is more process industry leaning as opposed to discrete process, for example.

So if you're building something for a specific machine, you're not as concerned with the piping and the gauges of level and, for example, the pumps, right? So you're not displaying those same P&ID loops. So of course, you need to adapt the HMI requirements to your specific use case. So it is perfectly fine to ignore some of the sections and then enjoy applying some of the other ones to your specific design.

There is absolutely no issue with that, at least on my side And I would encourage you to do the same. I would encourage you, again, within some constraints, develop some of your own preferences and standards. I think that exceptionally well-designed HMIs are not going to be fully restricted by a standard.

They will have a personal touch. And in some of the cases, I don't want to say in many cases, in some of the cases, the manufacturer that receives that piece of equipment, if it is well-designed, will appreciate the UI and UX and of course the extra effort and time that went into that specific design.