PLC vs Microcontrollers

not quite...

i have been in the industry for 30+ years, have programmed many products including PLCs and MCUs and yet - I have never seen industrial robot system that used an MCU or PLC as the controller. all industrial robots i encountered are using proprietary controller with own motion controller, programming language etc. conventional PLCs do not fit that application for number of reasons. main reasons are performance , safety and connectivity to other systems.

PLCs can be used to make custom controls for just about anything, but they are not necessarily perfect for every task, which is why there are specialized products called motion controllers, safety PLCs etc.

typical industrial robot controller is a proprietary product that combines functionality of two or more of those specialized variants because robots need safety as well as motion planner, ability to control several axes and communicate with other systems (other robots, PLCs, etc.).

single MCUs are commonly used in small products (robotic toys etc.) or various products with some specific function (appliances, TV remote, microwave controller, dishwasher controller...). every PLC module will typically have at least one MCU so even smallest PLC system will likely have several MCUs - that is just for standard functionality. Safety functions as found in robotics needs redundancy - in every function block and every IO point. this alone rules out single MCU because single point of failure could lead to loss of safety.

Robots often interface to standard (or safety) PLCs but this is to get instruction what program to run or if it is safe to enter some zone. In this case PLC monitors production and delegates what things need to be done but the motion control is done locally - at the individual robot controller.

Consider: would you try to run a nuclear power plant from an Arduino or other microcontroller? Sure, it could technically be done, but by the time the hardware and software had been improved to meet the minimum standard requirements for safety and reliability, you'd have a PLC.

PLCs cost, compared to a simple uC, but you're not just paying for the Big Name on the label. PLCs, as complete systems, have incredibly high reliability ratings in both hardware and software, including the software development environment, and are extremely tolerant to the kind of environments you find in industrial settings -- variable and noisy mains power, massive EMI, incompetent electricians, vibration, dust, etc.

Plus all the equally qualified and proven add-on modules for I/O at all sorts of extreme voltages and amperages, and high-reliability industrial networking protocol stacks. Imagine trying to control a bunch of 480V motors from an Arduino equivalent, and the stack of additional MOSFETS, relays, surge protectors, and so on you would need. Or the reliability of exchanging ASCII strings over basic Telnet-esque port comms, vs something like ProfiNet or Ethernet/IP.

And that's before we get into safety-rated components, and their requirements.

At the end of the day, the Big Names in PLCs are undoubtedly milking their prestige and dominant position to a degree. But when you really start to look at what it takes to go from a bare uC to a fully effective and reliable PLC, there's a lot there. Not the least being the major man-hours involved in testing, certification, and tech support.

For small tasks with low I/O counts, sure, you could wire and code up a small uC. And for a personal project, especially one you can afford to keep tinkering with and maintain, it might be fine. OTOH, we've seen cheap 3D printers with bad programming set houses on fire. And in the situations where PLCs are normally used, where a failure can costs millions of dollars or even kill people....