The prerequisite is, of course, the reliability of the hardware, i.e. the PC-based controller running on a suitable industrial PC. Above all, the flexibility for development is unbeatable. #plc #automation #codesys #twincat
Been There. Done that. The reasons why I won't do it again would fill a white paper of significant size. Summary 1. PC operating systems are far more bloated than a PLC. 2. Environmental limits are poorer for a PC 3. Power Consumption 4. More Frequent need for patches on PC 5. It was a financial failure the last time they tried it and it's still a financial failure. That's just a start.
I'm confused. A PLC/PAC is specifically designed for a particular purpose. It still uses a CPU and memory. It has software. It has connectivity. It's designed for a particular environment. A PC is designed for general purposes. You can harden the hardware all you want with redundancy and such but in the end the OS's are designed for different purposes. A PLC is read inputs, process logic, write outputs, repeat. The CPU's in both are basically the same architecture. I believe in a PLC one core does the processing and one does the communication. Any PC with Windows is event driven. The core kernel of windows is an event engine. It's not a sequence engine. Both have their place.
Love the image! And let me sit beside you on the debating table. The only hassle is that we are using two legacy acronyms here: - PC (Personal Computer) - PLC (Programmable Logic Controller) Just as the term PLC has lost meaning - we need to program more than just *logic* for modern automation and control - so has the term PC - we need shared access compute/storage/networking more than a *personal* device. Clear?
Question: How many times have you encountered the blue screen of death on a PC? Now, compare that to how often you've seen a PLC crash. For example, would you use a PC to control airport runway lighting? PLCs are designed for industrial environments, offering superior reliability and stability over traditional and "industrial" PCs in automation applications. Be very careful when working on industrial automation specifications—other people's lives may depend on it.
First the #1 Control System requirement is control system function Availability that PC OS cannot meet. Number two through the next million are, the resources taken away from performing control system functions necessary to protect against Shamoon, WannaCry and a million other targeted successful PC OS exploits. Number one million four is no PC OS can handle 10 microsecond response necessary for ten thousand sensors in a motion control system because the OS is not optimized for motion control functions. I've got a million more of them. 🤣
For the developer for sure but most likely not for the end user. We are replacing 10 year old PC based PLCs right now mean while we have 30 year old PLCs which will likely run for another 30 years.
Absoluetly, with caveats. I've had industrial equipment as big as an apartment building run on a PC-Based PLC for years. My only caveat is the use of PC-Based PLCs in super-critical applications. To this date, I've never used a PC-Based PLC controller for reactor control, electrical generation plant control, or reactive chemical plant tank/transfer control. I was never asked to either. MTTF & MTBF on super-critical/redundant hardware safety controllers like Triconix absolutely crush PC-Based PLCs. Add in SIL3 with most super-critical controllers and a 20 year operational lifetime, and the engineer has some peace-of-mind here.
It’s always a lazy answer to say any PC or any PLC will work for everything. Having a conversation about a system of hardware and software is more meaningful than just talking software or just talking hardware.
Yeah how many mechanics do you know in facilities that can program on one? By the time you train them decisions were probably made to replace them...
IT / Communications Supervisor at Jo Mill Oil Company
2moI've thoroughly enjoyed all the comments here. There seems to be two different types of comments. One group is about products. Look at what this product can do. The other group addresses what I thought the original post was about; the advantages and disadvantages of the two different engines. I see a lot of talk about scan times. Scan times are a function of CPU clock speed. Doesn't matter if it's a PLC or an IPC. Scan times are only relevant with a sequential PLC type engine regardless of what box it's in. I think a lot of these comments have missed the purpose. It's process control. Read inputs. Process the logic and write outputs. That's it. The process determines how fast that needs to happen. Then evaluate the solution with respect to MTBF and MTTR and the economic balance between costs and reliability. Those things will define the best product. Obviously there are other considerations but that's basically it. PLC or IPC isn't the issue. Two different architectures. Choose the one that best fits the solution.