PLC vs PC Control Opinions

Jieve

Member
Join Date
Feb 2012
Location
USA
Posts
274
I'm hoping I can get some input from you folks here.

I have been working on and off in Automation for over a decade, mostly with Siemens PLCs. I am currently working with a small R&D automation team with (other than myself) more-or-less no PLC experience, the assembly process we are trying to automate is extremely complex, involves robotic assembly, and until now has been PC controlled (with manual intervention). One of the guys in the team has a computer science background, and has written the PC interfaces to CANopen, RS232 and a TCP server for communicating with various components, and the robot PC program has handled the rest of the control through user I/O. The HMI was written in some other programming language and interacts with the rest of the process through TCP connection. Since I joined this team a little while ago, we've begun migrating everything over to PLC control, as we've regularly been asked from people outside why we're not using PLC control, and I felt that certain things may be more easily and effectively handled via PLC (CANopen control of drives, fault handling and further HMI development, for example). Also our techs aren't computer scientists/programmers so should reading code ever be necessary, monitoring a ladder PLC program seemed to make more sense to me.

So far everything has been working out fine, but due to the extensive numbers of robot sequences required, different interfaces and other features of the system, the PLC program has become much much more than just (is it ever?) bit logic (mainly using string commands routed around to control components). While doable, the computer science guy is of the opinion that PLC control is an archaic relic of times gone by, and feels that the things we're trying to do are so much more easily implemented on a PC. I don't really have a good counter-argument; so far I've been able to implement everything fine, but we're coming at this from two different angles ... my argument has been for PLC control because theres no worry about a blue screen of death in the middle of a production sequence, the controls are robust and will last forever, and the programs can be more easily monitored by our techs. But he brings up examples of other companies with complex automation using things like labview for control. While my gut feeling is that this is like comparing hobbiest equipment vs. industry, I can't really argue with him from the high level language or ease of implementation standpoint.

So I'm curious, anyone have any input in defense of one argument or the other? Input from all different industries is welcome. And this also brings up another question ... where is the line drawn when deciding what parts of a system should be PLC controlled and what should be controlled by an industrial PC?
 
And in what category does the soft-plc in a virtualized server fall, that have the calculations for predictive maintenance done in the cloud?

I think that Beckhoff HMI is already HTML5.
I guess most PLC already use standard PC processors.

Where I work now the classic PLC and HMI days are counted. Milennials simply do not appreciate the joy in learning one slow, unique, expensive and locked in solution for each hardware.

We have already moved all data exchange to OPC UA. PC panels that 'anyone' can program in standardized and/or open source programs will follow, allowing the existing PLC platforms we use to remain.

But when the internet goes dark...
 
One of the guys in the team has a computer science background, and has written the PC interfaces to CANopen, RS232 and a TCP server for communicating with various components, and the robot PC program has handled the rest of the control through user I/O. The HMI was written in some other programming language and interacts with the rest of the process through TCP connection.

So he has spent a lot of time writing custom interfaces for things that are standard in the industrial control space, "ease of implementation".

the computer science guy is of the opinion that PLC control is an archaic relic of times gone by, and feels that the things we're trying to do are so much more easily implemented on a PC.

Right, because his background is computer science and he has a lot invested in what he has already built. Better to plead ignorance.

PLCs can do a lot of complex things. There is a reason they have survived the PC control waves over the years. PLCs are more advanced then ever, and they will continue to evolve. If you had an experienced PLC/SCADA programmer look at what you're doing I'm sure it would be an eye-opener. Probably also seen as a threat by your co-worker.
 
First, you need to adjust your understanding of what a PLC is and what PLC control means. I've seen this topic come up here and /r/PLC a lot recently and it usually generates a lot of comments that are paradoxical in what they consider PLC and PC.

Look at ControlLogix, I think everyone here will agree that wherever the definition of PLC ends, a ControlLogix is still a PLC. A ControlLogix is just a computer running a distribution of Wind River's VxWorks Real-Time Operating System. You can program it in Studio 5000 in Ladder, Structured Text, Function Block Diagram, and Sequential Function Chart. Would anyone really argue that programming a L33ERM in ST makes it not a PLC anymore? If it Rockwell added the ability to group axes and run them as a robot with G-Code, would it not be a PLC?

What is a Motion Controller and is it not a PLC? What is a Programmable Automation Controller (PAC) and is it not a PLC?

B&R also uses VxWorks as their RTOS and you program it in Ladder, Structured Text, Sequential Function Chart, Instruction List (please don't), Sequential Function Chart, Automation Basic (B&R specific that predates ST but is basically the same thing), ANSI C, and even C++ with additional licensing. It also does robotics and CNC with G-Code and other methods. It also hosts the HMI on the PLC as a web server or a proprietary visualization server. Is it not a PLC? Is it a PAC instead? Is it a PLC as long as you only program it in the IEC languages? If you only program it in Ladder? If you use a separate HMI?

Beckhoff uses Windows and IntervalZero's RTX RTOS extension to add hard RTOS to Windows. Is it not a PLC because its RTOS is alongside windows?

If you hyper-visor VxWorks and Windows on the same multi-core CPU is that not a PLC?
What if it's VxWorks and some flavor of non-RTOS Linux, does that make a difference? What about hypervising two RTOS?


I draw the line at RTOS and reputation. If you are using a reputable RTOS on reputable hardware, then it's a PLC or PAC or whatever you want to call it and it's fine in an industrial environment. A non-RTOS system, like regular Windows, Linux, Mac, etc, is not usually okay. It can be, if the thing it is doing is slow enough, stepwise enough, etc. But most machine control wouldn't fit that bill.

I don't trust hyper-vised anything. I have seen bugs in the standard and embedded Windows kernel cause hardware access issues in the other kernel and bring systems down. If one kernel can still interfere with another kernel, then hyper-vising isn't there yet. Unsurprisingly, RTX works really well with Windows and it is more stable than hyper-vising VxWorks with Windows. Also, Windows Embedded on it's own doing non-RTOS stuff is pretty solid, it's just when you mix it with a non-RTX RTOS that I think there are problems.

FYI, when robots and stuff have Windows on their controllers, it's almost always RTX. Up to you if you call that PC control or not. It's just as much a hard RTOS as VxWorks is and clearly things running VxWorks can be called PLCs.
 
I haven't been in the automation field for very long, only 3 years now. 2 years in maintenance and 1 year actually in controls. I have yet to see a system that is only PC based. There is always a PLC because of how flexible they are and the fact that they are produced for this exact purpose.

I have seen a PC used along side a PLC before. Advantages of this are if you are writing large amounts of data to a plant server then you can use the local PC to store everything you are writing into a buffer. allowing the plant server to grab it whenever it is needed. This also greatly reduced latency on the machines local network.

I am curently using a plc paired with a pc for aiming a headlight. The machine is controlled by the plc but the software for aiming the light was written by a third party company specifically for this application. The PC gives us feedback on the difference between where the sense is and where is should be and we adjust the servos accordingly.

I think some of the other posts are right on the money. I would prefer a PC platform if I came from a computer background too. Instead I came from an industrial background where PLCs are still dominant. I would say probably because companies like rockwell have already created products that easily integrate together.
 
reason for plc

you buy the programming software and you own it.
you can modify the program if necessary.

you can buy the scada system (advanced is free)
you get to make the program and keep it.

you make backups of the programs.

plc dies, buy plc parts, download program, and your running
pc dies, get new pc, install program.

why not to buy custom written pc programs,
no one knows the language
no one has the source code
the programmer puts a drop dead code in the program (It does happen).
the programmer gets mad and quits leaving the company in deep trouble.

there are pros and cons to each.
I've never dealt with pc based control programs, only plc programming, panelviews, rsview, and wonderware, sql.

james
 
I've toyed with the idea several times myself.

Here are advantages / disadvantages I see for both:

PC

Advantages:
Not necessarily tied to any hardware platform.
Supports multiple programming languages

Disadvantages:
Tied to Windows (or other) operating system. Most don’t last more than 10 years and they are no longer supported.
Fewer people in controls are familiar with the platform
Not as likely to receive support from an expert at a vendor
May have added cost of shielding PC from harsh environments

PLC

Advantages:
PLCs have better hardware durability. They are designed to harsher environments, and will typically operate at temperatures and conditions above / below PC-based systems
I’d bet money on a PLC lasting longer than a PC. PLC? 20 years? PC, maybe 10 at best?
Many controls engineers will know Allen Bradley or Siemens PLCs so there will be a larger labor force to pull from if someone leaves
PLC vendors tend to support their hardware/software (tech lines, etc)

Disadvantages:
Expensive
Stuck with one brand / limited options

My personal feelings:
Unless you are collecting and logging data (this is mostly what Labview is for), or receiving a ton of external controls into a process, PLCs are the better option IMO.
 
The PC vs PLC argument has been going on a very long time but I feel ultimately it comes down to who will maintain the equipment. I've replaced PCs that were used as PLCs because of one primary reason - the maintenance staff could not or would not maintain it. Yep, the PC did the job, but the C, Basic, etc. code written for it was beyond what the electricians wanted to deal with. Ladder they would touch, its graphically easy to follow and they understand what a rung of logic does because its in their skillset.
 
Thanks everyone for the excellent responses.

To be fair, both the CS guy and myself make no qualms about and are pretty upfront about our biases; I come from an electromechanical/mechatronics background and my automation experience has mostly been with conveyors, machines w sequential processes, some vfds/hmi's here and there, so PLCs programmed in the IEC languages (especially LAD and FBD w/ Siemens) are most familiar to me. He has said many times that his background makes him obviously biased toward PC control, so he was actually quite willing and eager to have me implement PLC control to see if it makes automating the processes easier or more effective.

CaptWinky makes some excellent points on the hardware side, definitely food for thought ... now I have to be careful what I designate a PLC. :) And rightly so.

I think my coworker's real issue comes down to perceived programmability, cycle times and memory sizes, which make the hardware come across ancient. With 10's-100's of millisecond cycle times, RAM sizes in the low MB. Then most of the programming I have been doing on our systems is in ladder, where admittedly I'm not even always sure we can implement the things he suggests. Up until now I've managed to make everything work fine. But I suppose programming the whole thing in a language like C (or even structured text) for example, might make it easier to write (if you're a CS type) and allows the option of revision control (which is a big deal to him). Being more familiar with LAD and FBD that's what I use, and I feel like our maintenance staff would do much better with the graphical languages should they ever need to access the program. Right now he's the one who gets called whenever something goes wrong, and I know he's not a fan of that fact.

I feel like the PLC/HMI combo also gives a solid platform for dealing with system faults, alarms and status as well, as well as user administration, that would otherwise be more difficult (or at least more time consuming) to implement in a custom programmed PC controlled system. Then again, that's just my perception.
 
one additional comment: One thing prompting all of this as well, is that we still need to use the PC to control parts of the sequence (similar to sheardowns setup), as it contains custom control code for a part of the process, where we couldn't find off the shelf parts that would do what we needed and a PLC wouldnt cut it. Currently comms are done between PLC and PC via ethernet. This has prompted a continuous "ok what should actually be controlling what" discussion, the answer to which seems to change frequently.
 
PLC vs PC is the wrong questions.
It should be
PLC vs commercial PC vs Industrial PC.
We still do some industrial computer systems.
Commercial PC are not good enough. They are not able to withstand industrial nasty environments.
We used Advantech industrial PCs for years. These have worked well. We use a real time Linux.
We also Rockwell Compact Logix mostly to handle the I/O.
One of the latest small projects uses a Unitronix HMI/PLC.
It is all about what is right for the job. Obviously it isn't a religious issue for us.
 
PLC vs PC is the wrong questions.
It should be
PLC vs commercial PC vs Industrial PC.
We still do some industrial computer systems.
Commercial PC are not good enough. They are not able to withstand industrial nasty environments.
We used Advantech industrial PCs for years. These have worked well. We use a real time Linux.


Industrial PCs:

I had the honour to look into various IPC. o_O

Mostly they are heavy, noisy and pricy, inefficient coffins comprising SEA no name (unrepairable) $50-100 motherboars.


A long ago we just refused to purchase those piles of junk.

  • For single projects is better to purchase an usual office workstation solution from wide known brands (e.g. Dell. HP, Lenovo). We quite quickly realized that mentioned workstations had had all atributs of IPC's cases: they had had reliable and repairable motherboards.

  • Or in case if you need to sell 50-100 projects/machines a year, the best solution is to assemble IPC by themselves. All wide known motherboard manufactures have in their product lines a few types of protected matherboards supporting CPU from low cost range. Also there are appropriate cheap cases on the market.
@Jieve,
I'm hoping I can get some input from you folks here.
if your colleague with computer science background is going to spent all his weekends being at work or being at trips supporting customers, just stop arguing with him and let him realize his ideas. :) But first sign a paper which won't allow him leaving the company within 10 years.

As concerned technical side of the question:
IMHO, at the moment I'm observing that almost all propriatary unix realtime OS (not Intel compatible) is dying or is already died.

Windows 10 LTSB is nice, but it's not real time OS. To turn this OS into (at least partially) real time you need to purchase a license (there are third party real time extensions on the market).

So I would suggest:

  • in case you're working with quite critical dynamic events. Win10 LTSB + real time extension and appropriate performance PLC.
  • in case you're working with not critical dynamic events or mostly static things/events. Win10 LTSB and appropriate performance PLC.
In both cases, the local so-called service department will be capable to trobleshoot the most of issues arisen.




BR
 
Last edited:

Similar Topics

Hi, I have a 1500 that controls a station with diferents warehouses, but i also have a 1200 that controls one of those warehouses, i have been...
Replies
9
Views
205
Good day Forum Members I got a older Lincoln welder and hoping to make it work at our shop. Welder in question is the Lincoln Power Wave 455M...
Replies
4
Views
144
Hello everybody, I am working for an OEM and we are in the process for trying to raise the effectiveness of the pretesting of machines. Basically...
Replies
20
Views
618
An outside contracting firm designed a machine for our company. There are several devices connected through Ethernet/IP. This includes a Panel...
Replies
4
Views
180
Hello, I’m new to this forum and if I’m posting incorrectly let me know. I’ve been having an issue I can’t seem to figure out. I’m sure it’s...
Replies
1
Views
100
Back
Top Bottom