Why does everyone use PLCs in industrial environments, instead of a microcontroller based solution?
For a longer task, the PLC program is as complicated as a microcontroller program.
A microcontroller based solution may be more customisable, and of lower price.
I'd think a major factor is people. The engineers that can design a microcontroller to run a factory are busy making batches of small devices. Engineers that work on brand name PLCs use standard software packages, they don't have to deal with lower level programming, most problems they encounter someone else has already solved with that hardware (comms to strange devices, IO issues, PIDs). Also the engineers are interchangeable, with a good spec or code commenting you don't need the engineer that built a system there when you need to change the code.
It's also a bit like asking why would someone buy a PC when they could build their own.
The higher cost of PLCs is offset by the testing (often in nasty environments) they are (or should be) submitted to. Could you design a custom microcontroller system? Yes, but then you'd probably need to certify it.
Customizability is not really a major issue when you have a large plant full of equipment; in fact, you want the opposite, you want stuff to be as standardized as possible.
Also, ladder logic is already pretty much standardized — except for vendor-specific features — which make debugging/porting software between PLCs a simpler task than it is porting between different microcontrollers.
Not everyone who works with PLCs is an electronics expert.
I started doing PLC as a pure process guy. I could not use a multimeter, did not really understand the difference between voltage and current. I had done some C in a college class, but that was it.
High level languages are massive. I could learn basically the entire intruction set of a PLC in a couple of weeks of training, and that was enough for basic PLC programming. I never had to worry about libraries, I/O handling, memory allocation, any of those things.
And as mentioned before-safety applications. I would not trust anyone's homebrewed microcontroller that they are claiming a SIL-3 rating for.
The environmental issue (physical, electrical isolation, EMI, etc.) is a huge one and has already been covered by other answers.
You also need to consider how PLCs give you a very deterministic environment. They are well understood and have been in place since the 1970s.
You know how long each rung is going to take and you are guaranteed the behavior based on known input parameters. With pure microcontroller programming it can get complicated to figure out exactly how a change in a function is going to affect the whole functioning of the program.
Ladder logic is easy to understand and program for machine control. We have electricians programming them without any involvement from engineering. They can easily troubleshoot the line's electrical systems by themselves and make the appropriate repairs. They can also write their own programs and do modifications to existing ones. The debugging environment is way (and I mean WAY) better than what you can normally accomplish with embedded micros.
With safety systems it becomes even more important to use safety PLCs and their redundant capabilities and watchdogs to ensure proper functionality.
You know have a few PLCs in the sub $100/ea range: CLICK® Series Programmable Logic Controllers (PLCs) (Stackable Micro Brick) and plenty in the sub $500 range with limited IO.
There are some modules that are basically industrialized "micro-controllers" packages. For example most PID temperature controllers can be thought as such.
Having said all that, you can start seeing places in the industry in which computers with real time OS are taking care of control tasks and machine control directly. This will continue to grow specially with networked IO.
Think about end users: A PLC is more friendly for a person with a light EE background. Easier to use, easier to maintain plus a PLC gives some top level factory automation control. Think about a huge plant that needs 10,000 different functions, you cannot build them all, time/cost is huge compared to using COTS (cheap off the shelf).
If you are a real EE, don't take such a job, it's a boring, low tech job. A real EE's job is to use a MCU to create a PLC box for other guys to play with.
Another factor not yet mentioned is that some PLC vendors have invested considerable effort demonstrating that their systems can be relied upon to behave as specified, even in the presence of various types of adversity (in the presence of of adversity that would make normal operation impossible, the device may be relied upon the trigger a fault output or cause other outputs to go into a fail-safe condition). While it would be possible to program many types of microcontroller to provide such robustness even in the presence of glitches that could flip one or more register bits during operation (e.g. by performing redundant calculations using different formulas, such that an extreme coincidence would be required to glitch both sets of calculations in such a way as to yield consistent results) the effort required to write and validate such software would be enormous relative to the complexity of what the software actually did. It's much easier to use a PLC which has such safety features designed into it.
In my experience I have seen both microcontrollers and PLC's used in industrial environments.
The determining factor is "Who is going to support/maintain/modify the equipment after it is commissioned?"
In industrial environments more time is spent reading (see fault-finding) code than what is spent writing it. This doesn't mean that you are trying to find problems in the code, but are using the code to help diagnose problems in the field. Often the people required to do such fault-finding are electricians, who are more comfortable reading electrical schematics than code in a text format (thus the popularity of the graphical type "programming languages" such as ladder logic). In larger sites, with dedicated automation engineers, this becomes less of a factor.
Closely related to the above are issues of historical inertia for a particular solution. The technical backgrounds of personnel and prior experience with hardware/vendors lead to prerequisite requirements for projects that are usually organised around lines such as ("we already use vendor X and have spares on hand - anything implemented in the future needs to use X-YZ").
Also related, and becoming more of an issue in the last few years, is "How is this equipment going to communicate with the rest of my equipment/factory/site/company". This is usually pre-solved for PLC's and more of an issue for low-volume micro-controller solutions.
I have seen micro-controllers implemented where a very custom solution was warranted (but then usually only implemented as a vendor-project and supported by the vendor). Reasons are normally related to execution speed or the need to have the hardware and code very closely located (no possibility of communication delays and the requirement to separate the critical process from other unrelated code)
The microcontroller is a device, the PLC is an equipment. Use microcontroller "on the ends" if you are an impecunious hobbyist or if you are a manufacturer of a mass product. For customized industrial solutions PLC is the only choice.
They can both accomplish the same goal. While a micro controller driven system may be cheaper, programming in C code is a massive undertaking. To be proficient at C languages tons of training is involved.
That being said there is an area where I work that uses MCUs to communicate with a C++ program to track and regulate current and voltage of large rectifier charging circuits for industrial batteries (200+ AH batteries). There are approximately 100 rectifiers. Finding the old AD-DA with the STD controller and relay card is next to impossible. Once these boards go bad that's it.
That is why we are currently in the process of upgrading all to the allen bradley line of compact or control logix line of PLCs. Are they expensive? Yes. Is hiring a programmer that knows C++ expensive? Yes. Using RS Linx/Logix, several people that all ready work for the company can write/edit programs using that software. Couple that with the amount of support and expansion, it can be faster and more cost effective to use PLCs.
One other factor worth mentioning is product life cycle. Typically for PLCs support is available for many many years. I'm still supporting some Texas Instruments PLCs from 1985 and 1987. They were well built and extremely reliable. Spares are available from industrial repair centres or on eBay at this stage and command high prices.
Try finding replacement chips, boards and stuff to run your (insert favourite micro) in 30 years' time.
I like the above answers and thought I should chip in too. PLC vs Micro Controller also has alot to do with scale and cost. For example, You could very quickly program a washing machine with a PLC. But then your washing machine would cost 3 times as much as it does to offset the price of the PLC. So you design a micro controller with a single program to be replicated 100,000 times. The cost of engineering for that is high, but over 100,000 units its very low with a low end cost for the equipment.
Alternatively, You could also program an entire power plant in a micro controller. However, (along with many of the above answers), you will likely spend 20 times as much time programming it, and another 20 times as much time debugging it - Lower hardware cost yes, but engineers are expensive, especially good ones. Or you could use a PLC with a higher hardware cost, but the time programming it is much less, resulting in lower engineering cost.
Also note, I wouldnt want to be person who had to program BACnet, Modbus, CIP, and an ethernet HMI driver into a Micro-controller. Plcs can do that with a few extra cards and a couple hours of configuring.
Amongst the other great answers, in one word: standardization.
Standard hardware, standard communication, standard development IDEs, standard languages.
Different brands do offer different flavors, but in general, once youve learned one brand of PLC, switching brands is more of a licensing burden rather than a technological one.
For standard of programming and electrical parameters it is appropriate to use PLC instead of microcontroller.
Microcontrollers are used when you are dealing with products, especially low powered and small size, like those for automobiles and for medical use. You don't use PLC in there.
But when you are dealing with machines like badging, cutting etc. one can easily use PLC.
Moreover PLC are standardize application of embedded chips.
The progamming language for plc is very easy and user friendly,the expansion ports used in the plc are also more while comparing with micro controller,and mainly "in microcontroller if any pin is damages then it is more difficult to troubleshoot"for all these reasons industries will use plc istead of the micro controller.there is some more but these are main problems faces in industry
I've built and used PLCs over the years. I suggest there's a market convergence, with WiFi PLC-like micros now costing $49 and selling like hotcakes.
PLC manufacturers are feeling price pressure.
Newer cost effective PLCS like the Siemens Logo may be better suited for simple applications.
Just hitting the market are PLCs that use Arduino instead of ladder logic. A lot of bang for the buck there. Search kickstarter for PLC
-Martin
Simple answer is to always use PLC. . . . But if PLC is not feasible due to factors like cost, size or complexity of the Application only then should we go for Micro-Controller because PLC are more rugged, its meant for Industrial environment (meaning involving lot of mechanical vibration, high temperature, dust, electrical spikes etc), its tested for reliability, uses standard programming methods which enables engineers with lesser skills to make changes etc.
