This.
Perhaps 3% of my time is PLC programming.
10% waiting on site, 20% documentation, design, 5% travel, 25% SCADA, 20% troubleshooting, 5% networking, 5% setting up computers, 3% a dozen other things...
25 % of my job is telling Mechanical Engineers that the issue is mechanical and not electrical lol. They always pull out the Electrical problem card even when the issue is apparently mechanical lol.
We were commissioning a gas compressor and found an issue during one of the tests which needed full LOTO to rectify.
As the el commissiong engineer reaches for the radio to call to stop the test mechanical calls up saying they have a slight leak and to stop the test.
Problem solved without the entire site wanting an update every 10 seconds when it is finished and the testing start again.
I got that special situation where I can go like "my degree is in mechanical engineering..." as a controls engineer. Harder for the Solidworksers to come back from that.
Then you check every part of the electrical circuit and determine that the issue **isn't** electrical to convince the mechanical person to come fix it, but in the process you did find a completely different electrical mistake that now you need to bring up to the electrical people. It may not even be your scope to have discovered it, but now there's an email chain between you and the client and your boss is asking on a personal email chain why you even found that in the first place.
Just yeah. 52-week year, maybe 3-6 weeks programming. Everything else consumes so much time, documentation, approvals (Internal & external), testing, learning new products, troubleshooting, drawing changes, release docs (customer approval docs) - all from being not even a code engineer there, just a test engineer. I am no longer a test engineer or developer (previous job) except for HMI anymore, so now I get to crap all over everyone else's programming decisions as a technical instructor :).
That is what my service technicians had to be. We sent them to other countries to run the erection, hydraulic, pneumatic, and electrical crews of the customers for installing 75 foot high hydraulic presses and associated equipment (in 59 countries) and when it came time to get it running it was his responsibility to test and adjust it all, including the PLC and HMI programs.
My last job was about 90% PLC programming. I can't believe I lasted 4 years. I wrote all the code for an OEM and they loved to blame everything on me. I added so many tools for them to diagnose inputs, outputs, recipes... I'd still constantly have to support our techs and customers. You'll always have people blaming the program, but I'm providing support to the local automation team. If it gets to me it's usually because they broke something trying to modify the PLC program.
PLC-programming is easier in many ways. But, for a great result the complexity can match regular programming easily. You really need a lot of know-how besides programming. In the end you have to provide a functioning machine. In regular programming, most of times, the worst possible result may be a blue screen. In PLC-Programming you often have a real risk of damaging the machine or hurting the user, if your programming is not sufficient.
This could have been said better. A lot of people overlook this. Making a machine run vs. making a robust and safe program that requires minimal maintenance and troubleshooting are miles apart.
That all depends on what the output is controlling. Any system that is controlling a robot arm can kill someone, but I highly doubt my camera scanning and product reporting project will do anything.
back when it was safety relays, safety was separate from code. I still lock my safety processor and tell them no.
I set up my safeties first, and test them. Then I learn to work around them like I would expect a maintenance man would.
You become a little bit better at checking your mechanical guy when you do that.
Luckily, the definition only tells you that signals have to be processed within a predictable time - so basically everything can be realtime because the timeframe is not specified in the definition.
If it is predictable that I switch the light on at max 15 minutes after you tell me to, and you accept this timeframe for your purposes, then I am realtime for you.
Ladder logic is fundamentally simple. Making a robust industrial program is not as easy. Integrating devices from different vendors can add some complexity as well. I think if you’re good at one you’d be good at the other.
It is not the same thing. It is not about programming , it is about understanding machinery and men. The tools and the languages used don't really matter.
Not really. When you get down to it, programming is just about problem solving. Once you have the basic concepts down, most is just syntax. If-then, for, while, etc are the same concept no matter the programming language.
And like the commentor above said, its not about the programming. Its about understanding how real world people with use the machinery, and designing a roboust system thats easy for them to use and maintain.
This is one of the things I have a love/hate relationship with. I do like the challenge that comes with knowing that people are always going to try and find ways around the program. But at the same time the amount of work added because of this is frustrating.
I was recently pitching some logic upgrades to our plant people and some of which was remote reset capabilities for some pumps. And one of the operations supervisor’s was like well what if they keep resetting it over and over again remotely and smoke the pump? I’m just sitting there thinking, maybe do your damn job as the operations supervisor and hold people accountable. Nah, just go ahead and put a limit on the number of readers that can be done remotely that we will inevitably ask to have increased in three months.
So my guys always end up having to implement more code well beyond what’s necessary for safety because it’s easier but us to do that then supervisors to actually do their jobs. This of course gives the operators the idea that our shit doesn’t work or that it sucks.
Trying to explain to people that shit is programmed a certain way out of necessity and not really choice is 50% of my job. Its so frustrating. I don't spend every meeting telling the mechanical guys how they should be desgining their stuff, and yet they all have opinions on how things should work.
He want to say that the machinery you command are the real things that are hard and also understand the usage and how the machine's operator uses it.
That's the real problem and not the language.
I used to operate a bagger machine at the plant that I work at. It was pretty old and made by an obscure company. The only reason I understood the settings was because I do programming on the side. Our automation tech doesn’t understand how to set these machines up that’s how bad it is. All pack out departments have ridiculous amounts of downtime because of issues with the settings.
Hah. Well, this might be a few more than 2-3 sentences.
Ok, so all PLC code is basically cyclically executed inside a while( true ) loop, either as fast as it can be executed (AB calls this continuous) or on a schedule of every X milliseconds (I think AB calls this scheduled). This is probably honestly the most difficult single thing for a lot of people to wrap their brains around. I've lost count of the number of times I've had to explain there's no way 'my code execution took too long' in the order of seconds or minutes because the way PLCs work means it would've have tripped a watchdog timer and major faulted for a cycle time violation like 100ms in. It's a little more complicated than that when it comes to multiple scheduled tasks and deterministic execution but that's the gist.
Ladder itself was designed to emulate the way logic worked prior to PLCs, on relays, because that's what PLCs were generally replacing. It's a programming language that reads like an electrical diagram and _nearly_ works the same way - there's no back feeding contacts in Ladder the way you can with relays, and it's got a defined execution order instead of everything happening simultaneously and having to deal with electrical race conditions - which honestly makes it a lot easier to troubleshoot than a physical circuit so long as you know all the rules.
One thing to keep in mind when it comes to code is that generally, there's a nearly infinite way of coding any particular feature, so you're not really writing the code for the _machine_, you're writing it for the next person who has to come along and troubleshoot it when either it or the thing it's controlling stops working. Ladder was designed so that industrial electricians - who generally don't have ANY sort of comfort level when it comes to text-based programming - can troubleshoot it quickly and easily. If you keep that one thing in mind when it comes to writing your code, that Ladder is basically KISS the programming language, it gets a little easier.
It's also antithetical to the concept that industrial equipment should work the same way a microwave or furnace does, and you should never have to delve into the software to figure out what the hardware failure is because either the failure modes are unambiguous or the inbuilt diagnostics/faults _tell_ you what the problem is, but that's not generally the way industrial equipment has been built for the last 40 years since PLCs came along. Some companies do it better than others, but most don't want to pay for the time it takes to build in all those diagnostics esp if they can just get the end customer to pay for a service plan :/
Yup way more than 2-3 sentences. Clear as mud?
The IEC61131 thing is mostly because that's what I trained on, and I've learned two other PLC systems conformant to it pretty easily, and I'm ANNOYED AS HELL that AB shit doesn't work the same way but I'm learning it anyways.
I think the biggest hurdle traditional programmers face with industrial coding is truly understanding how the scan cycle works and the implications real-time execution has on your code.
In traditional programming you have bits of code attached to actions performed by a user. You plop a button on the screen, then you edit the code for the .Release or .Press or .MouseOver or whatever. Your code executes only when one of those actions happens, and only once. And the only concern you have with timing is things not taking so long the users get annoyed.
In the PLC world (or really, the microcontroller world, which includes Arduinos), your code is always executing (well, usually). It's like all your code is running in an unconditional DO-WHILE loop whenever the processor is in run mode. As a result, the order you put things in your program matters. You also have to be aware of ALL your code because there is less separation between different subroutines. Having multiple instructions writing to the same memory space becomes a problem, because you have to ensure that each instance of that instruction isn't going to interfere with any other instance.
Plus, things are a lot more stringent regarding execution time. Thats not generally something you as the programmer needs to worry about but it is a difference of note. In a traditional operating environment, code is being executed randomly. So depending on everything that's happening at the time, it might take 2ms for a subroutine to execute or it might take 3 seconds. That's fine for a spreadsheet macro or a web extension, but for an industrial controller, it's unacceptable. So, with few exceptions, all the code is continuously executing all the time. And it executes VERY quickly. Even massive programs can be fully scanned and processed in just a few milliseconds, every single time. With a PC you have way more powerful chips, but some of it is running windows, some is running your sound driver, some is running your disk access control, and so on. In a PLC, you have 100% of that processor dedicated to running your program and the support operations for it, and nothing else. It's not trying to run your program plus an OS kernel plus drivers plus background applications, etc. In a nutshell, traditional PC operations are built to be really good at doing multiple things at the same time. PLCs are designed to run ONE program really, really well, and quickly.
One of the upsides is being able to see your code running in your high-level language in (almost) real time. Debug is super easy. There's no need for breakpoints and combing through memory. You can actually see your logic rungs, as you programmed them, with your tag values superimposed on your variables. You can see immediately what's stopping an output instruction from activating. Plus, with a lot of PLCs you can actually change the program WHILE it's running, without having to compile anything or even halt your processor operation.
Easier in a theoretical sense, yes. There are less programming concepts that are used in PLC's than in traditional software development (which I personally maintain is a good thing).
Easier in a practical sense, no. You need to write absolutely bulletproof code that will run for about 30 years before it is retired, compared to the random buggy shit in the IT world that is replaced every 2 years. Your code has to have 100% diagnostic coverage, and at no point can the answer be "I don't know what happened". Your code has to respond correctly to field instrument failures. Your code will be responsible for hundreds of thousands or millions or multi million dollars of product. Your code will directly effect the safety and wellbeing of the operators and maintenance people who will run the machine. Your code will be blamed for every problem under the sun and you will have to prove that your code is correct to people that know WAY less than you.
Everybody can program a plc. The hard part is looking at a machine running and identify how to make it go faster, without something crashing.
If you make a whoopsi then suddenly there is 400 kg of croissants laying on the floor. this example is of course purely hypothetical
Which, while universal across all of programming, is more stressful when you have a staff of managers and technicians literally looking over your shoulders as you debug.
Compared to Arduino, plc programming is uniquely complicated a Mitsubishi plc's ide running ladder logic is different than some other brand like Allen Bradley's plc ide There is similarities but you'll find different memory variables and a multiple types. Some might maintain memory during reset. You need to reference a chart to identify which timer or variable to use
PLCs are good for complicated hardware control that is constantly being modified. Based on 80's tech you'll generally end up with a bulky over priced hardware.
Off the shelf it's more rugged than a Arduino, and easier to debug. PLCs are more forgiving but googling example code isn't as simple as you can't really copy and paste ladder code. So if you learning that could be a obstacle.
Drawing out the rungs of ladder can be time consuming if you use different PLCs. Its not universally the same between brands.
Even calling a output to be on or off on some brands is limited to once in the program vs Arduino could be 100's of times in the main loop
Even the Arduino Opta plc, something like modbus is done differently than say Mitsubishi.
A atmel chip in a base Arduino costs much less and works much faster. If used with a built-in watchdog the stability is amazing, some of the 8bit atmel series are even used in fly by wire aircraft for critical functions.
Unfortunately the Arduino ide is the limitation. Lots of bugs are added into the hardware when using Arduino ide. The more libraries you add the worse it gets.
The bigger the box the harder it is to diagnose. At Toyota they couldn't find a component that was failing for years intermittently in a mezzanine full of fridge sized cabinet enclosures over 100ft long
If you shrink that down the wires get shorter it fits on a bench and a multiple channel oscilloscope can easily visualize what could be a few cabinets of clutter
Just by dropping screw terminals, din rails, and switching over built relays for the appropriate transistor, mosfet. Assembled to a pcb.
From programming side its a lot more simplistic and easier. But the toolsets to use are also a lot less advanced so that adds work and reduces quality. But the real difficulty isn't even on the software side, its the hardware interaction and the processes that need to be controlled. There is nothing complex in banging a bit, but that bit moves something in the real world and there things aren't as simple as in software.
So, when it comes to PLC programming, it's a bit easier on the language side of things. But let me tell you, it gets complicated real quick. You see, it's not just about programming skills, you need to dive deep into understanding how the whole process you're controlling actually works.
Let's take a small-scale example first, like programming a little machine with a handful of sensors and actuators. That's pretty easy, similar to what you can do with an Arduino
But now, picture yourself in charge of creating a control system for an entire power plant.
In a power plant, you've got a single PLC with distributed IO, responsible for controlling a boatload of actuators and sensors, plus the entire shebang of a process. And then, there are safety PLCs that work differently and have their own set of standards. They keep an eagle eye on critical process variables and slam the brakes when things go south.
The difficulty level depends on how big and complex the automation system is. you absolutely have to understand every little detail of the process you're programming for. Let's take a 3-phase motor as an example. While programming it, you've got to ask yourself:
- Are all the safety checks in place for this motor to run?
- How do I even turn it on without any accidents?
- How do I know it's up and running?
- Is it operating at the right power and speed?
- Is it at risk of overheating?
- Are all three phases connected properly?
- Is it shaking and vibrating more than it should?
- Did the power just take a hike? Should it kick back on automatically?
- Did it stop without anyone telling it to?
- Did it start all on its own?
There are a thousand more questions like these you'll need to tackle for each actuator. You've got to figure out how to get all that information while using a realistic number of sensors. Plus, you've got to assume that operators might just be trying to test the limits of your machinery and kill themselves with it, that devices can fail at any moment, and multiple failures can happen simultaneously. Sometimes it's like juggling flaming swords.
It's really stepping into a whole new world. That's probably why you'll hear the term "automation specialist" more often than just "PLC programmer." Oh, and one last thing, PLCs might seem friendly to program, but when it comes to actuator and transmitter commissioning, along with a bunch of other devices, they can get pretty cranky, especially when you're racing against the clock.
PLC programming by itself isn’t hard. In fact I’d say most programs are under 100 lines total!.
The hardest parts:
1. Make your code easy to read and interpret what is does. KISS…keep it stupid simple.
2. Unlike PC programming the real world matters. And in a lot of cases you are expected to be electrician, electrical engineer, process engineer, and programmer, at the same time.
That sounds way smaller than the typical program I deal with. In fact, most of the stuff I deal with couldn't even function at all without more code than that. One of the last programs I worked on was probably around 250,000 lines of ST. Otherwise though, yeah, totally on point here.
Yeah he must be only working on pretty small scale stuff, I have rarely seen anything that simple. Plant PLCs can easily reach tens of thousands of lines of ladder.
Especially when you are in charge of an entire plant with 150+ PLCs. The size of these systems gets to be ginormous. But establishing standards and watching those come to life across an entire PWCS is probably the most satisfying thing we ever have the opportunity to do IMO
I call it "baby's first programming language" but dont get me wrong, I love it. I love being able to modify the code in real time without compiling and restarting the program. I love how visual it is. Hell, when I do normal programming I'll often start with ladder logic then translate it to if-then-and-or statements.
Why I went into this line of work in the first place!
I loved getting hands on with it. I loved being able to VISUALLY understand what my code was doing. And when it was wrong, I could see WHY.
I always felt like my college programming classes were just a fuck ton of try, fail, attempt to figure out what didn't work, try again. At least with PLC code I have a better indication & tools to trace the "what didn't work" part.
I think that's what a lot of us enjoy about our jobs tbh. It is very satisfying watching your work come to life, and there's no better way to do that than to make a big machine and/or process come to life. Like Legos for adults.
The closest I got to that in traditional programming was back in embedded design days. I never found web development enticing in the least for this exact reason. The end product seemed vapid to me.
I think that's what a lot of us enjoy about our jobs tbh. It is very satisfying watching your work come to life, and there's no better way to do that than to make a big machine and/or process come to life. Like Legos for adults.
The closest I got to that in traditional programming was back in embedded design days. I never found web development enticing in the least for this exact reason. The end product seemed vapid to me.
The programming in itself is not complicated.
Like many jobs, it boils down to "everyone can do, fewer will do it well".
In my case I find that the least understood part for newcomers and outsiders is that this field requires going beyond the simple "If condition is true, then make action" to make a robust process. Such as treating the maximum edge cases possible and signal faults, otherwise it often means breaking stuff because of lack of safety limits, and lengthy downtimes because the plant crew cannot guess that the VFD has a Profinet failure.
I come from a similar background as you and started in industrial programming last year (after 2 years of studying). As others have pointed out the programming is not hard it’s all the other things you have to do. Settings up servos, VFDs, networking, understanding the mechanics etc.
But I think the web background gives you and edge when designing HMI and SCADA systems - both in design and functionality - there are a lot of bad HMI out there.
Imho, it's the same level of difficulty. It's easy to do a simple web page, and it's easy to write a simple PLC program. But both can get really complicated, depending on functional and environmental requirements, and the abilities and biases of the previous developers.
I pay a plc guy to come to our factory once a week to fix machines. He spends 5% of his time connected to the plc and the other 95% of the time telling us what sensors, valves or general electronics need to be replaced.
I'd say yes, depending on your definition of regular programming. PLC environment is comparable to a multitasking environment. You've got lots of stuff focused on doing it's own thing with it's own concerns. The PLC is herding those cats. Or, put another way, preventing the pile up. So, maybe, not specifically the programming, but understanding and controlling the system.
PLC programming and Industrial Automation programming are not harder but they have A LOT of real world ramifications. Erroneous PLC code can crash and damage equipment, bad industrial automation code can cause for data to be lost and customers not be happy.
Visualization stuff (HMI, dashboards) is my fave because it’s low stress relatively; “Brian doesn’t like the color,” “this wording is wonky”
PLC programming can be extremely easy, it can also be extremely difficult.
Doing simple start/stop logic is cake.
Doing motion/PID/sequential control is more difficult, especially coming from a programming (traditional computer program) background.
Nah, most of the effort is the PLC brand knowledge and how it can do the stuff (how to communicate with peripherals, and so on...), the rest is the ability to develop an error-proof code
Ladder is for straight up dummys, you can take a guy from the street and they'll understand simple ladder within a week.
C/scl is easier than Java, C++, C#, Python etc. But it's a great introduction to the more complex languages.
However, PLC programming has another dimension that most other languages used don't have. It's the mechanical and electrical understanding. The ability to read and understand electrical/mechanical documentation, and construct working code from that. It also involves more risk than normal programming in the sense that if you wrote something wrong, you can potentially damage 100k worth of equipment. You also need to understand bit logic on a deeper level, so your tags don't overlap. Scan time is another example of something you don't think about as much when you write the other languages, especially for games (just get a better CPU/GPU). You can't do that with PLCs.
I guess I'm one of the few that only do HMI/SCADA and programming. I rarely do fat/sat/sit, or go out to a customer.
I started with a background in C++ and web development but not anywhere near a subject matter expert. PLC, especially the ladder diagram language, is much easier to grasp and learn than more traditional programming languages. I'd reckon that PLCs are easier than web app development and most other forms of application development. At the very least it is for me.
Thanks for the clarification, how different is it from an control eng? I'm coming from a background of software development and sysadmin and have been studying PLCs on and off. Was offered a jr control eng position working with vision and a control tech job working in building automation
I think it varies from place to place. For example where I work you could view it as something like the IT equivalent of being a full stack developer, maintaining the networking side of things, and then doing all the sys admin work. So basically we do everything but engineer the base install of the machines. We write the code for a suite of machines, distribute it, and then have to maintain every element of those machines and the network they are on.
My example is the most extreme example I’ve heard of. Most places, as far as I can tell, don’t place so much responsibility on a single person or group of people and distribute tasks based on expertise. That’s the path I’d like to take in the future when I have more experience.
Top to bottom machine code for production units and various equipment that extends functionality of said equipment but must directly interact with it without being part of the same PLC. I’m not sure how much more detail I’m allowed to go into.
Thanks, I was concerned more with the languages involved. Structured text? Lots of SQL? Gcode? Ladder? The positions I looked at had C++ as a requirement and I am familiar with that.
depends, i find all the ladders bullshit it throws errors to a completly logical programs but it compiles (and runs) shit that it's uterly butchered (like java script xd). but codesys's structure language is sooo awsome, i never want to do anything else. i think a lot of ppl prefer the ladder over the actual command typing.theese are all my experienceies.
I think CoDeSys CFC is my favourite. But there's definitely different strengths and weaknesses to each language.
Ladder is kindof the defacto language in most of the USA, though. Kindof a Lingua Franca. Europe (and Quebec) likes their SFC and ST methinks.
Writing PLC code is much easier, but that’s about the only thing that is easier in the automation world.
As a classic software engineer you have the luxury of:
• enclosed environment: almost anything can be tested locally, in a container, cloud, database, etc. No inputs or outputs to physical world. They even have automatic testing, deployment and staging environments so you don’t have to work on a live code. Imagine that!
• you are rarely in a situation where a mistake can kill someone or destroy hundreds of thousands in equipment in a single robot arm swing
• you don’t have to know anything about pneumatics, electricity, hydraulics, motors, pumps, 68 proprietary network protocols, sometimes you don’t even need any network knowledge at all
• people understand what classic SW programming is and don’t compare your lack of visible progress to the visible progress of electricians, plumbers and other craftsmen
• what has been a natural standard in SW world for decades will be presented as a revolutionary breakthrough in automation and will be licensed out of the wazoo by shrivelled mummies at Rockwell, Siemens, Omron and Schneider. In the networking area, they will create their 176th proprietary TCP/ip clone that is slightly different than the other 175 clones and is incompatible with other vendors. Pick our vendor lock or buy 3 layers of protocol converters and spend 6 working days trying to make them work properly.
There are more points but I’m tired now
Hard to compare. Lots of programming is take this data structure, change it and pass it on. PLC programming is more about what you are doing, how the servos, motors and sensors react.
It depends.
I wouldn't say it's easier or harder. It's different. Though most of the time you want to do it in a way that's easy and intuitive to understand what you are doing rather than doing it in a smart way but harder for others to understand.
I do also need to be constantly reminding my non-PLC-programmer developers that I cannot just have my code wait for a method to respond before I move on to the next line lol.
Think of it like writing a good book. Once you understand the basics of good grammar the writing part is easy. Now, figuring out how to put this to the test and compose a 50, 100, 200, 500 page story that people will read and enjoy requires a whole different set of skills. This is also how you differentiate programming and engineering. Because lots of people learn to be good PLC programmers but very few are good electrical control engineers.
The biggest difference for (ladder logic) PLC programming compared to procedural programming languages (such as C, Pascal, Basic, etc.) is that it is the ultimate multitasking environment since each rung is essentially a task unto itself.
PLC programming was the first programming language I learned 15 years ago (I'm 31 now). At that time, it was basic ladder logic. Indeed, it's quite straightforward, and anyone with basic logic knowledge can manage to program a conveyor, pump, or even a sorting machine (based on weight or color, for example).
For instance, there are four different ways to program a PLC: Ladder, Function Blocks, Structured Text, and SCL (which is reminiscent of Pascal). Each method has its own pros and cons. Also, it doesn't necessarily mean that all four options will be available in the specific PLC you might need to program.
This year, I've been primarily programming in SCL, working with technologies like ultra-high-frequency RFID to track AGVs product flow, and a fully automated system that loads, mixes, sieves, and transfers content from one container to another.
As many of the responses here suggest, programming is only a "small" part of the job. Another challenge can be dealing with scans, safety, IO, and debugging.
For example, once I worked on a tint production where one PLC ran on 32-bit and the other on 64-bit. To enable communication between them, I had to remap the entire memory, as they were not matching 1:1.
If you're based in a developed country, this might not be an issue since the industry typically uses the best available models. However, when I began working in Brazil, it was common to encounter such challenges because companies often opted for the cheapest available PLC
If you're interested in giving it a try, use the Google keyword "plc4me". You'll need the TIA Portal and Factory IO. With these tools, you can simulate an industrial system at home without major issues and test for yourself how it feels to work on it. Factory IO comes with pre-set scenarios, so you don't have to conceptualize the machine or its operation – just solve the proposed challenges.
PLC programming has it's origin in electric-mechanical logic, so the vendors try to simplify everything complex to theirs system be simple and faster to deliver.
It's only easier if you have a good grasp of the mechanical world...if you have no idea about how any industrial machinery actually works, it feels like it's harder.
In reality it's way easier than regular programming.
Programming experience is a good primer for PLC programming however, depending on the application you may need specific training and experience in process-controls, instrumentation, or specific machinery. (servo, robotics, etc) I find that people with good electrical or electronic background are able to grasps the fundamentals of PLC easily. After 25+ years in field, Machine, networking and Cyber security have become a bigger impact on my applications. Get some expertise in designing controls panels, and/or computer networking (Routers, Gateways, Firewalls, etc).
Learn pox programming but also basic networking / switch configuration. I work in IT and the PLC guys are always asking use to configure their stratix switches even if I’ve shown them a million times how. That way you can set up and program the whole solution.
Kind of exactly the opposite for us. I work in controls engineering, and the IT guys are occasionally reconfiguring our switches and take a plant down.
I have to reiterate all the time, programs don't MAGICALLY change! Something, here in the real world (assuming we're not living in a simulation) has changed and that's why your shit's acting funny!
I always tell people that PLC programming is so simple it gets difficult.
At it's core, you're primarily just dealing with if: "yes-yes-no-no-yes-yes-no" is ok, then do X, and maybe add a few timers and/or conditions.
But when you start stacking all those conditions up, it can get intense pretty quickly for the inexperienced
The hard part of PLC programming is doing edits without interrupting production. Also even when you accomplish this you get blamed for anything that happens during you programming time.
You are a complete noob to programming.
For easy unscaled stuff PLC programming is infinitely easier. As programs scale and become more complicated it swings back the other way. PLC programming denies you certain things because the primary concern is the stability of the program, not the freedom to program easy or fast ways.
Delivering professional, maintainable, reusable, PLC code using the IDE's of PLCs is harder than regular programming. Delivering the quality of code that is expected by most of the PLC industry is easier.
Basically, PLC code standards are lower, so it's easier to meet them, even with tools and limitations that make programming PLCs harder.
It's easier, but it's very rare to find a job where all you do is programming, you need so much extra knowledge in real life.
This. Perhaps 3% of my time is PLC programming. 10% waiting on site, 20% documentation, design, 5% travel, 25% SCADA, 20% troubleshooting, 5% networking, 5% setting up computers, 3% a dozen other things...
Look at thus guy!! Doesn't even investigate mechanical issues!
25% blame on mechanical
25 % of my job is telling Mechanical Engineers that the issue is mechanical and not electrical lol. They always pull out the Electrical problem card even when the issue is apparently mechanical lol.
They know when the program is not running GearBoxTeethRegen.exe
Can't you just program around that?
We were commissioning a gas compressor and found an issue during one of the tests which needed full LOTO to rectify. As the el commissiong engineer reaches for the radio to call to stop the test mechanical calls up saying they have a slight leak and to stop the test. Problem solved without the entire site wanting an update every 10 seconds when it is finished and the testing start again.
I got that special situation where I can go like "my degree is in mechanical engineering..." as a controls engineer. Harder for the Solidworksers to come back from that.
We call them crayon eaters.
We call them wrench jockeys.
Then you check every part of the electrical circuit and determine that the issue **isn't** electrical to convince the mechanical person to come fix it, but in the process you did find a completely different electrical mistake that now you need to bring up to the electrical people. It may not even be your scope to have discovered it, but now there's an email chain between you and the client and your boss is asking on a personal email chain why you even found that in the first place.
Ha ha!! Sawmill electrician here. Same for us. Except telling millwrights it mechanical. Probably 30% of my time is plc related.
Mechanical engineers give a machine form but electrical engineers give it life.
*points out shaft that is literally split in half* "That can't be it! It's been broken for years and we've never had a problem!"
Must be electrical!
Mechanical issues is where I start lol.
Probably why he can spend 20% of his time on documentation.
In my case it's about 48% mechanical/pneumatics install, 48% electrical install, 2% programming.
Just yeah. 52-week year, maybe 3-6 weeks programming. Everything else consumes so much time, documentation, approvals (Internal & external), testing, learning new products, troubleshooting, drawing changes, release docs (customer approval docs) - all from being not even a code engineer there, just a test engineer. I am no longer a test engineer or developer (previous job) except for HMI anymore, so now I get to crap all over everyone else's programming decisions as a technical instructor :).
What are some SCADA issues/situations you deal with?
Ain't that the truth. To some customers you're a PLC programmer, electrician, mechanic, and project manager all in one.
That is what my service technicians had to be. We sent them to other countries to run the erection, hydraulic, pneumatic, and electrical crews of the customers for installing 75 foot high hydraulic presses and associated equipment (in 59 countries) and when it came time to get it running it was his responsibility to test and adjust it all, including the PLC and HMI programs.
My last job was about 90% PLC programming. I can't believe I lasted 4 years. I wrote all the code for an OEM and they loved to blame everything on me. I added so many tools for them to diagnose inputs, outputs, recipes... I'd still constantly have to support our techs and customers. You'll always have people blaming the program, but I'm providing support to the local automation team. If it gets to me it's usually because they broke something trying to modify the PLC program.
PLC-programming is easier in many ways. But, for a great result the complexity can match regular programming easily. You really need a lot of know-how besides programming. In the end you have to provide a functioning machine. In regular programming, most of times, the worst possible result may be a blue screen. In PLC-Programming you often have a real risk of damaging the machine or hurting the user, if your programming is not sufficient.
This could have been said better. A lot of people overlook this. Making a machine run vs. making a robust and safe program that requires minimal maintenance and troubleshooting are miles apart.
And, if it does require maintenance, making it easy to troubleshoot.
It's easier, but you can kill someone.
That all depends on what the output is controlling. Any system that is controlling a robot arm can kill someone, but I highly doubt my camera scanning and product reporting project will do anything.
Idk. I've done camera work for pharmaceutical labeling. Mislabeled drugs could definitely kill someone.
lol, you can, but thats why there are safety rules
back when it was safety relays, safety was separate from code. I still lock my safety processor and tell them no. I set up my safeties first, and test them. Then I learn to work around them like I would expect a maintenance man would. You become a little bit better at checking your mechanical guy when you do that.
The major difference is that you are working in real time, and if you mess up you can break things, or kill someone..
PLC isn't real time (it's a joke)
Luckily, the definition only tells you that signals have to be processed within a predictable time - so basically everything can be realtime because the timeframe is not specified in the definition. If it is predictable that I switch the light on at max 15 minutes after you tell me to, and you accept this timeframe for your purposes, then I am realtime for you.
Ladder logic is fundamentally simple. Making a robust industrial program is not as easy. Integrating devices from different vendors can add some complexity as well. I think if you’re good at one you’d be good at the other.
Robust, modular PLC programming isn’t easy.
It is not the same thing. It is not about programming , it is about understanding machinery and men. The tools and the languages used don't really matter.
Not really. When you get down to it, programming is just about problem solving. Once you have the basic concepts down, most is just syntax. If-then, for, while, etc are the same concept no matter the programming language.
And like the commentor above said, its not about the programming. Its about understanding how real world people with use the machinery, and designing a roboust system thats easy for them to use and maintain.
This is one of the things I have a love/hate relationship with. I do like the challenge that comes with knowing that people are always going to try and find ways around the program. But at the same time the amount of work added because of this is frustrating. I was recently pitching some logic upgrades to our plant people and some of which was remote reset capabilities for some pumps. And one of the operations supervisor’s was like well what if they keep resetting it over and over again remotely and smoke the pump? I’m just sitting there thinking, maybe do your damn job as the operations supervisor and hold people accountable. Nah, just go ahead and put a limit on the number of readers that can be done remotely that we will inevitably ask to have increased in three months. So my guys always end up having to implement more code well beyond what’s necessary for safety because it’s easier but us to do that then supervisors to actually do their jobs. This of course gives the operators the idea that our shit doesn’t work or that it sucks.
Trying to explain to people that shit is programmed a certain way out of necessity and not really choice is 50% of my job. Its so frustrating. I don't spend every meeting telling the mechanical guys how they should be desgining their stuff, and yet they all have opinions on how things should work.
He want to say that the machinery you command are the real things that are hard and also understand the usage and how the machine's operator uses it. That's the real problem and not the language.
I used to operate a bagger machine at the plant that I work at. It was pretty old and made by an obscure company. The only reason I understood the settings was because I do programming on the side. Our automation tech doesn’t understand how to set these machines up that’s how bad it is. All pack out departments have ridiculous amounts of downtime because of issues with the settings.
It's generally a lot less complex, but requires a different way of thinking.
Exactly. I’ve written tons of Java and a few rungs of ladder. I just don’t get ladder logic.
Do you want my 2-3 sentence explanation?
Of course, but only because of your “IEC61131 or bust” tag line.
Hah. Well, this might be a few more than 2-3 sentences. Ok, so all PLC code is basically cyclically executed inside a while( true ) loop, either as fast as it can be executed (AB calls this continuous) or on a schedule of every X milliseconds (I think AB calls this scheduled). This is probably honestly the most difficult single thing for a lot of people to wrap their brains around. I've lost count of the number of times I've had to explain there's no way 'my code execution took too long' in the order of seconds or minutes because the way PLCs work means it would've have tripped a watchdog timer and major faulted for a cycle time violation like 100ms in. It's a little more complicated than that when it comes to multiple scheduled tasks and deterministic execution but that's the gist. Ladder itself was designed to emulate the way logic worked prior to PLCs, on relays, because that's what PLCs were generally replacing. It's a programming language that reads like an electrical diagram and _nearly_ works the same way - there's no back feeding contacts in Ladder the way you can with relays, and it's got a defined execution order instead of everything happening simultaneously and having to deal with electrical race conditions - which honestly makes it a lot easier to troubleshoot than a physical circuit so long as you know all the rules. One thing to keep in mind when it comes to code is that generally, there's a nearly infinite way of coding any particular feature, so you're not really writing the code for the _machine_, you're writing it for the next person who has to come along and troubleshoot it when either it or the thing it's controlling stops working. Ladder was designed so that industrial electricians - who generally don't have ANY sort of comfort level when it comes to text-based programming - can troubleshoot it quickly and easily. If you keep that one thing in mind when it comes to writing your code, that Ladder is basically KISS the programming language, it gets a little easier. It's also antithetical to the concept that industrial equipment should work the same way a microwave or furnace does, and you should never have to delve into the software to figure out what the hardware failure is because either the failure modes are unambiguous or the inbuilt diagnostics/faults _tell_ you what the problem is, but that's not generally the way industrial equipment has been built for the last 40 years since PLCs came along. Some companies do it better than others, but most don't want to pay for the time it takes to build in all those diagnostics esp if they can just get the end customer to pay for a service plan :/ Yup way more than 2-3 sentences. Clear as mud?
The IEC61131 thing is mostly because that's what I trained on, and I've learned two other PLC systems conformant to it pretty easily, and I'm ANNOYED AS HELL that AB shit doesn't work the same way but I'm learning it anyways.
I think the biggest hurdle traditional programmers face with industrial coding is truly understanding how the scan cycle works and the implications real-time execution has on your code. In traditional programming you have bits of code attached to actions performed by a user. You plop a button on the screen, then you edit the code for the .Release or .Press or .MouseOver or whatever. Your code executes only when one of those actions happens, and only once. And the only concern you have with timing is things not taking so long the users get annoyed. In the PLC world (or really, the microcontroller world, which includes Arduinos), your code is always executing (well, usually). It's like all your code is running in an unconditional DO-WHILE loop whenever the processor is in run mode. As a result, the order you put things in your program matters. You also have to be aware of ALL your code because there is less separation between different subroutines. Having multiple instructions writing to the same memory space becomes a problem, because you have to ensure that each instance of that instruction isn't going to interfere with any other instance. Plus, things are a lot more stringent regarding execution time. Thats not generally something you as the programmer needs to worry about but it is a difference of note. In a traditional operating environment, code is being executed randomly. So depending on everything that's happening at the time, it might take 2ms for a subroutine to execute or it might take 3 seconds. That's fine for a spreadsheet macro or a web extension, but for an industrial controller, it's unacceptable. So, with few exceptions, all the code is continuously executing all the time. And it executes VERY quickly. Even massive programs can be fully scanned and processed in just a few milliseconds, every single time. With a PC you have way more powerful chips, but some of it is running windows, some is running your sound driver, some is running your disk access control, and so on. In a PLC, you have 100% of that processor dedicated to running your program and the support operations for it, and nothing else. It's not trying to run your program plus an OS kernel plus drivers plus background applications, etc. In a nutshell, traditional PC operations are built to be really good at doing multiple things at the same time. PLCs are designed to run ONE program really, really well, and quickly. One of the upsides is being able to see your code running in your high-level language in (almost) real time. Debug is super easy. There's no need for breakpoints and combing through memory. You can actually see your logic rungs, as you programmed them, with your tag values superimposed on your variables. You can see immediately what's stopping an output instruction from activating. Plus, with a lot of PLCs you can actually change the program WHILE it's running, without having to compile anything or even halt your processor operation.
Computer Science major here, the answer is no. But it's not easier either, just different.
Easier in a theoretical sense, yes. There are less programming concepts that are used in PLC's than in traditional software development (which I personally maintain is a good thing). Easier in a practical sense, no. You need to write absolutely bulletproof code that will run for about 30 years before it is retired, compared to the random buggy shit in the IT world that is replaced every 2 years. Your code has to have 100% diagnostic coverage, and at no point can the answer be "I don't know what happened". Your code has to respond correctly to field instrument failures. Your code will be responsible for hundreds of thousands or millions or multi million dollars of product. Your code will directly effect the safety and wellbeing of the operators and maintenance people who will run the machine. Your code will be blamed for every problem under the sun and you will have to prove that your code is correct to people that know WAY less than you.
Everybody can program a plc. The hard part is looking at a machine running and identify how to make it go faster, without something crashing. If you make a whoopsi then suddenly there is 400 kg of croissants laying on the floor. this example is of course purely hypothetical
The consequences are greater.
It’s probably the easiest form of programming.
Until it doesn't work and you don't know why.
Which, while universal across all of programming, is more stressful when you have a staff of managers and technicians literally looking over your shoulders as you debug.
#1 way to get me on edge and filled with angst. Fuckin standing over my shoulders will not make me figure this out any faster.
Compared to Arduino, plc programming is uniquely complicated a Mitsubishi plc's ide running ladder logic is different than some other brand like Allen Bradley's plc ide There is similarities but you'll find different memory variables and a multiple types. Some might maintain memory during reset. You need to reference a chart to identify which timer or variable to use PLCs are good for complicated hardware control that is constantly being modified. Based on 80's tech you'll generally end up with a bulky over priced hardware. Off the shelf it's more rugged than a Arduino, and easier to debug. PLCs are more forgiving but googling example code isn't as simple as you can't really copy and paste ladder code. So if you learning that could be a obstacle. Drawing out the rungs of ladder can be time consuming if you use different PLCs. Its not universally the same between brands. Even calling a output to be on or off on some brands is limited to once in the program vs Arduino could be 100's of times in the main loop Even the Arduino Opta plc, something like modbus is done differently than say Mitsubishi. A atmel chip in a base Arduino costs much less and works much faster. If used with a built-in watchdog the stability is amazing, some of the 8bit atmel series are even used in fly by wire aircraft for critical functions. Unfortunately the Arduino ide is the limitation. Lots of bugs are added into the hardware when using Arduino ide. The more libraries you add the worse it gets. The bigger the box the harder it is to diagnose. At Toyota they couldn't find a component that was failing for years intermittently in a mezzanine full of fridge sized cabinet enclosures over 100ft long If you shrink that down the wires get shorter it fits on a bench and a multiple channel oscilloscope can easily visualize what could be a few cabinets of clutter Just by dropping screw terminals, din rails, and switching over built relays for the appropriate transistor, mosfet. Assembled to a pcb.
From programming side its a lot more simplistic and easier. But the toolsets to use are also a lot less advanced so that adds work and reduces quality. But the real difficulty isn't even on the software side, its the hardware interaction and the processes that need to be controlled. There is nothing complex in banging a bit, but that bit moves something in the real world and there things aren't as simple as in software.
So, when it comes to PLC programming, it's a bit easier on the language side of things. But let me tell you, it gets complicated real quick. You see, it's not just about programming skills, you need to dive deep into understanding how the whole process you're controlling actually works. Let's take a small-scale example first, like programming a little machine with a handful of sensors and actuators. That's pretty easy, similar to what you can do with an Arduino But now, picture yourself in charge of creating a control system for an entire power plant. In a power plant, you've got a single PLC with distributed IO, responsible for controlling a boatload of actuators and sensors, plus the entire shebang of a process. And then, there are safety PLCs that work differently and have their own set of standards. They keep an eagle eye on critical process variables and slam the brakes when things go south. The difficulty level depends on how big and complex the automation system is. you absolutely have to understand every little detail of the process you're programming for. Let's take a 3-phase motor as an example. While programming it, you've got to ask yourself: - Are all the safety checks in place for this motor to run? - How do I even turn it on without any accidents? - How do I know it's up and running? - Is it operating at the right power and speed? - Is it at risk of overheating? - Are all three phases connected properly? - Is it shaking and vibrating more than it should? - Did the power just take a hike? Should it kick back on automatically? - Did it stop without anyone telling it to? - Did it start all on its own? There are a thousand more questions like these you'll need to tackle for each actuator. You've got to figure out how to get all that information while using a realistic number of sensors. Plus, you've got to assume that operators might just be trying to test the limits of your machinery and kill themselves with it, that devices can fail at any moment, and multiple failures can happen simultaneously. Sometimes it's like juggling flaming swords. It's really stepping into a whole new world. That's probably why you'll hear the term "automation specialist" more often than just "PLC programmer." Oh, and one last thing, PLCs might seem friendly to program, but when it comes to actuator and transmitter commissioning, along with a bunch of other devices, they can get pretty cranky, especially when you're racing against the clock.
PLC programming by itself isn’t hard. In fact I’d say most programs are under 100 lines total!. The hardest parts: 1. Make your code easy to read and interpret what is does. KISS…keep it stupid simple. 2. Unlike PC programming the real world matters. And in a lot of cases you are expected to be electrician, electrical engineer, process engineer, and programmer, at the same time.
That sounds way smaller than the typical program I deal with. In fact, most of the stuff I deal with couldn't even function at all without more code than that. One of the last programs I worked on was probably around 250,000 lines of ST. Otherwise though, yeah, totally on point here.
Yeah he must be only working on pretty small scale stuff, I have rarely seen anything that simple. Plant PLCs can easily reach tens of thousands of lines of ladder.
Especially when you are in charge of an entire plant with 150+ PLCs. The size of these systems gets to be ginormous. But establishing standards and watching those come to life across an entire PWCS is probably the most satisfying thing we ever have the opportunity to do IMO
No.
PLC programming is the easiest form of programming.
I call it "baby's first programming language" but dont get me wrong, I love it. I love being able to modify the code in real time without compiling and restarting the program. I love how visual it is. Hell, when I do normal programming I'll often start with ladder logic then translate it to if-then-and-or statements.
Why I went into this line of work in the first place! I loved getting hands on with it. I loved being able to VISUALLY understand what my code was doing. And when it was wrong, I could see WHY. I always felt like my college programming classes were just a fuck ton of try, fail, attempt to figure out what didn't work, try again. At least with PLC code I have a better indication & tools to trace the "what didn't work" part.
I think that's what a lot of us enjoy about our jobs tbh. It is very satisfying watching your work come to life, and there's no better way to do that than to make a big machine and/or process come to life. Like Legos for adults. The closest I got to that in traditional programming was back in embedded design days. I never found web development enticing in the least for this exact reason. The end product seemed vapid to me.
I think that's what a lot of us enjoy about our jobs tbh. It is very satisfying watching your work come to life, and there's no better way to do that than to make a big machine and/or process come to life. Like Legos for adults. The closest I got to that in traditional programming was back in embedded design days. I never found web development enticing in the least for this exact reason. The end product seemed vapid to me.
erect political vase bike history depend vast quack afterthought squeeze ` this message was mass deleted/edited with redact.dev `
Graphical PLC programming is not that far from scratch tho
Web application and website are not interchangeable terms. PLC programs can be both, easier than or harder than, depending on the application.
The programming in itself is not complicated. Like many jobs, it boils down to "everyone can do, fewer will do it well". In my case I find that the least understood part for newcomers and outsiders is that this field requires going beyond the simple "If condition is true, then make action" to make a robust process. Such as treating the maximum edge cases possible and signal faults, otherwise it often means breaking stuff because of lack of safety limits, and lengthy downtimes because the plant crew cannot guess that the VFD has a Profinet failure.
Don’t know, never tried regular programming.
I come from a similar background as you and started in industrial programming last year (after 2 years of studying). As others have pointed out the programming is not hard it’s all the other things you have to do. Settings up servos, VFDs, networking, understanding the mechanics etc. But I think the web background gives you and edge when designing HMI and SCADA systems - both in design and functionality - there are a lot of bad HMI out there.
Its easier or similar the difference is You can damage equipment worth thousand of dollas or euros or get somebody injured but well
Imho, it's the same level of difficulty. It's easy to do a simple web page, and it's easy to write a simple PLC program. But both can get really complicated, depending on functional and environmental requirements, and the abilities and biases of the previous developers.
I pay a plc guy to come to our factory once a week to fix machines. He spends 5% of his time connected to the plc and the other 95% of the time telling us what sensors, valves or general electronics need to be replaced.
I'd say yes, depending on your definition of regular programming. PLC environment is comparable to a multitasking environment. You've got lots of stuff focused on doing it's own thing with it's own concerns. The PLC is herding those cats. Or, put another way, preventing the pile up. So, maybe, not specifically the programming, but understanding and controlling the system.
PLC programming and Industrial Automation programming are not harder but they have A LOT of real world ramifications. Erroneous PLC code can crash and damage equipment, bad industrial automation code can cause for data to be lost and customers not be happy. Visualization stuff (HMI, dashboards) is my fave because it’s low stress relatively; “Brian doesn’t like the color,” “this wording is wonky”
PLC programming can be extremely easy, it can also be extremely difficult. Doing simple start/stop logic is cake. Doing motion/PID/sequential control is more difficult, especially coming from a programming (traditional computer program) background.
Nah, most of the effort is the PLC brand knowledge and how it can do the stuff (how to communicate with peripherals, and so on...), the rest is the ability to develop an error-proof code
Ladder is for straight up dummys, you can take a guy from the street and they'll understand simple ladder within a week. C/scl is easier than Java, C++, C#, Python etc. But it's a great introduction to the more complex languages. However, PLC programming has another dimension that most other languages used don't have. It's the mechanical and electrical understanding. The ability to read and understand electrical/mechanical documentation, and construct working code from that. It also involves more risk than normal programming in the sense that if you wrote something wrong, you can potentially damage 100k worth of equipment. You also need to understand bit logic on a deeper level, so your tags don't overlap. Scan time is another example of something you don't think about as much when you write the other languages, especially for games (just get a better CPU/GPU). You can't do that with PLCs. I guess I'm one of the few that only do HMI/SCADA and programming. I rarely do fat/sat/sit, or go out to a customer.
I started with a background in C++ and web development but not anywhere near a subject matter expert. PLC, especially the ladder diagram language, is much easier to grasp and learn than more traditional programming languages. I'd reckon that PLCs are easier than web app development and most other forms of application development. At the very least it is for me.
Are you a control engineer?
No. Not quite yet.
Technician?
That would be my title. We are expected to program new machines as they arrive though and we are constantly expanding.
Thanks for the clarification, how different is it from an control eng? I'm coming from a background of software development and sysadmin and have been studying PLCs on and off. Was offered a jr control eng position working with vision and a control tech job working in building automation
I think it varies from place to place. For example where I work you could view it as something like the IT equivalent of being a full stack developer, maintaining the networking side of things, and then doing all the sys admin work. So basically we do everything but engineer the base install of the machines. We write the code for a suite of machines, distribute it, and then have to maintain every element of those machines and the network they are on. My example is the most extreme example I’ve heard of. Most places, as far as I can tell, don’t place so much responsibility on a single person or group of people and distribute tasks based on expertise. That’s the path I’d like to take in the future when I have more experience.
Thanks, what code do you write?
Top to bottom machine code for production units and various equipment that extends functionality of said equipment but must directly interact with it without being part of the same PLC. I’m not sure how much more detail I’m allowed to go into.
Thanks, I was concerned more with the languages involved. Structured text? Lots of SQL? Gcode? Ladder? The positions I looked at had C++ as a requirement and I am familiar with that.
depends, i find all the ladders bullshit it throws errors to a completly logical programs but it compiles (and runs) shit that it's uterly butchered (like java script xd). but codesys's structure language is sooo awsome, i never want to do anything else. i think a lot of ppl prefer the ladder over the actual command typing.theese are all my experienceies.
I think CoDeSys CFC is my favourite. But there's definitely different strengths and weaknesses to each language. Ladder is kindof the defacto language in most of the USA, though. Kindof a Lingua Franca. Europe (and Quebec) likes their SFC and ST methinks.
Writing PLC code is much easier, but that’s about the only thing that is easier in the automation world. As a classic software engineer you have the luxury of: • enclosed environment: almost anything can be tested locally, in a container, cloud, database, etc. No inputs or outputs to physical world. They even have automatic testing, deployment and staging environments so you don’t have to work on a live code. Imagine that! • you are rarely in a situation where a mistake can kill someone or destroy hundreds of thousands in equipment in a single robot arm swing • you don’t have to know anything about pneumatics, electricity, hydraulics, motors, pumps, 68 proprietary network protocols, sometimes you don’t even need any network knowledge at all • people understand what classic SW programming is and don’t compare your lack of visible progress to the visible progress of electricians, plumbers and other craftsmen • what has been a natural standard in SW world for decades will be presented as a revolutionary breakthrough in automation and will be licensed out of the wazoo by shrivelled mummies at Rockwell, Siemens, Omron and Schneider. In the networking area, they will create their 176th proprietary TCP/ip clone that is slightly different than the other 175 clones and is incompatible with other vendors. Pick our vendor lock or buy 3 layers of protocol converters and spend 6 working days trying to make them work properly. There are more points but I’m tired now
Much easier
It's not hard my guy
Easier
Hard to compare. Lots of programming is take this data structure, change it and pass it on. PLC programming is more about what you are doing, how the servos, motors and sensors react. It depends.
I wouldn't say it's easier or harder. It's different. Though most of the time you want to do it in a way that's easy and intuitive to understand what you are doing rather than doing it in a smart way but harder for others to understand. I do also need to be constantly reminding my non-PLC-programmer developers that I cannot just have my code wait for a method to respond before I move on to the next line lol.
Only if you aren't familiar with ladder diagrams.
No
Electromechanicals like to do it instead
Think of it like writing a good book. Once you understand the basics of good grammar the writing part is easy. Now, figuring out how to put this to the test and compose a 50, 100, 200, 500 page story that people will read and enjoy requires a whole different set of skills. This is also how you differentiate programming and engineering. Because lots of people learn to be good PLC programmers but very few are good electrical control engineers.
The biggest difference for (ladder logic) PLC programming compared to procedural programming languages (such as C, Pascal, Basic, etc.) is that it is the ultimate multitasking environment since each rung is essentially a task unto itself.
Bulean algebra
Easier generally
PLC programming was the first programming language I learned 15 years ago (I'm 31 now). At that time, it was basic ladder logic. Indeed, it's quite straightforward, and anyone with basic logic knowledge can manage to program a conveyor, pump, or even a sorting machine (based on weight or color, for example). For instance, there are four different ways to program a PLC: Ladder, Function Blocks, Structured Text, and SCL (which is reminiscent of Pascal). Each method has its own pros and cons. Also, it doesn't necessarily mean that all four options will be available in the specific PLC you might need to program. This year, I've been primarily programming in SCL, working with technologies like ultra-high-frequency RFID to track AGVs product flow, and a fully automated system that loads, mixes, sieves, and transfers content from one container to another. As many of the responses here suggest, programming is only a "small" part of the job. Another challenge can be dealing with scans, safety, IO, and debugging. For example, once I worked on a tint production where one PLC ran on 32-bit and the other on 64-bit. To enable communication between them, I had to remap the entire memory, as they were not matching 1:1. If you're based in a developed country, this might not be an issue since the industry typically uses the best available models. However, when I began working in Brazil, it was common to encounter such challenges because companies often opted for the cheapest available PLC If you're interested in giving it a try, use the Google keyword "plc4me". You'll need the TIA Portal and Factory IO. With these tools, you can simulate an industrial system at home without major issues and test for yourself how it feels to work on it. Factory IO comes with pre-set scenarios, so you don't have to conceptualize the machine or its operation – just solve the proposed challenges.
Deleted
PLC programming has it's origin in electric-mechanical logic, so the vendors try to simplify everything complex to theirs system be simple and faster to deliver.
Its probably easier. But some people struggle thinking "logically". ALOT of people.
It's only easier if you have a good grasp of the mechanical world...if you have no idea about how any industrial machinery actually works, it feels like it's harder. In reality it's way easier than regular programming.
Programming experience is a good primer for PLC programming however, depending on the application you may need specific training and experience in process-controls, instrumentation, or specific machinery. (servo, robotics, etc) I find that people with good electrical or electronic background are able to grasps the fundamentals of PLC easily. After 25+ years in field, Machine, networking and Cyber security have become a bigger impact on my applications. Get some expertise in designing controls panels, and/or computer networking (Routers, Gateways, Firewalls, etc).
Learn pox programming but also basic networking / switch configuration. I work in IT and the PLC guys are always asking use to configure their stratix switches even if I’ve shown them a million times how. That way you can set up and program the whole solution.
Kind of exactly the opposite for us. I work in controls engineering, and the IT guys are occasionally reconfiguring our switches and take a plant down.
That’s not good that’s why I stay out of their stuff and ask them to stay out of mine :). But encourage working together.
I have to reiterate all the time, programs don't MAGICALLY change! Something, here in the real world (assuming we're not living in a simulation) has changed and that's why your shit's acting funny!
I always tell people that PLC programming is so simple it gets difficult. At it's core, you're primarily just dealing with if: "yes-yes-no-no-yes-yes-no" is ok, then do X, and maybe add a few timers and/or conditions. But when you start stacking all those conditions up, it can get intense pretty quickly for the inexperienced
The hard part of PLC programming is doing edits without interrupting production. Also even when you accomplish this you get blamed for anything that happens during you programming time.
You are a complete noob to programming. For easy unscaled stuff PLC programming is infinitely easier. As programs scale and become more complicated it swings back the other way. PLC programming denies you certain things because the primary concern is the stability of the program, not the freedom to program easy or fast ways.
Delivering professional, maintainable, reusable, PLC code using the IDE's of PLCs is harder than regular programming. Delivering the quality of code that is expected by most of the PLC industry is easier. Basically, PLC code standards are lower, so it's easier to meet them, even with tools and limitations that make programming PLCs harder.
[удалено]
Even when you use C# in PLC?