PC based Control .vs. PLC


Michael Griffin

(Originally posted Thurs, 3 Sep 1998)
I’ve used both PLCs and PCs (for test equipment), and I think we should be carefull about jumping to conclusions without considering the application in which they are being applied. I think we also need to define just what we mean by a “PC”.
I define a PLC as an industrial controller which is ready to apply right out of the box. There is little or no integration effort to get different components to work with each other.
A PC is the beige box you see sitting on your desk. It requires loading an operating sytem, and the application software before you can do anything. If you want a working system, you have to do all the system testing and integration yourself.
Industrial computers seem to fall somewhere in between the above two catagories. They have been around for decades, and actually predate the PLC.

I work in an industry with many small machines, most of which are custom built for our application by a variety of companies (both large and small). Typically each machine has its own small PLC. For these types of our applications, a PC (however defined) offers no advantages to us at all, and has the disadvantages of higher cost, larger size, etc. The total number of PLCs we have is about two hundred or more.
Other applications we have involve test equipment where we need a full keyboard, graphic screen, and a hard drive. We also need to be able to plug in specialised data aquisition boards, GPIB boards, vision processors, etc. In other words we need a PC. These systems are generally desk top type PCs in EEMAC 12 rated enclosures. These include both systems which we have built ourselves, and systems which we have purchased from other companies.
The software is written in Quick Basic, C, and Visual Basic. The operating systems used include DOS, Windows 95, and Windows NT. I have heard on this list many complaints about the “blue screen of death”, but this has not been a problem for us, not even with Windows 95 (although Windows NT has caused lots of problems when used in office applications).
However, we do have problems with hardware. Monitors, keyboards, power supplies, and hard drives all fail. Monitors and keyboards are easy enough to change, but power supplies and expecially hard drives are more of a maintenance problem. These last two items are beyond what we expect our electricians to be able to replace, and so have to be serviced by qualified computer repair technicians (we get the same company which services our office PCs to do this - they have at least one person permanently stationed on site at our plant). If a PC fails at night, it has to wait until morning to get repaired.
The PCs seem to run OK for about 3 or 4 years, and then start to give trouble. When they do go wrong, they are much more of a headache, and take much longer to fix than a PLC would. Fortunately, the hardware which has Windows 95 and NT on it is all relatively new, so those ones haven’t started to fail on us yet. Some of the DOS systems are AT&T 6300s which were probably built in the late 1980s. This would not be considered very old for normal industrial equipment, but these PCs are difficult to keep going.
I had one 4 year old PC fail late last week (right about when this thread started), and another somewhat newer one failed a couple of weeks ago. Both were a big headache.
Another problem with PCs is their lack of standardisation. There have been so many bus systems, graphics card standards, motherboard layouts, and operating systems changes that each new PC (even ones that are supposed to be the same model) can be an adventure. Data aquisition and other similar board drivers, even those from large reputable companies, can be of unpredicable quality and may not work simply for reasons such as the clock rate of the CPU is higher than on the PC they were written for.

We have other machines which use STD Bus industrial computers. These are controlling standard machines (e.g. lathes) which are produced in some volume by a large company. I would not consider these to be ‘PC control’ though. STD Bus has been around for quite a while, and was designed for exactly this sort of application. These machines do not have hard drives, monitors, or keyboards (they do have special operator interface panels though). The boards do occasionally fail, but unlike PCs though, these boards are comparitively simple to change.
STD or other similar industrial computers do take more engineering effort to apply than a PLC, but may offer advantages for large OEM equipment builders making standard products. I would like to note that the company I referred to in the above paragraph still prefers to use PLCs for any one-off machines they may build.

Michael Griffin
London, Ont. Canada
[email protected]

Pablo Cussatti

(Originally posted Wed 09/02/1998)
Try recovering from a corrupt hard drive on a PC controlled system. Unless you go completely flash memory you will never achieve the reliablity of a PLC. And you do not crash a PLC5 by giving it an empty PID instruction you are faulting the processor. The difference is the code you put in was unacceptable, but is easily recoverable by fixing the code. What do you think happens when you divide by zero in a PC Control system? Yes PLC5’s crash, I’ve seen it happen, but I’ll put them up against any hard drive in town.
There is a place for both, it depends on the application.
Pablo Cussatti
WESTT Consulting
(Originally posted Thu, 3 Sep 1998)
Hi All,
I have over the past 10 yrs installed both PLC and PC based control systems.
My first two PC based control systems were in 1990, both were for the control of exothermic reactions in the chemical industry.
MOTIVATION: customer needed a quick inexpensive solution while he decided which DCS or PLC system to install. Plug in I/O cards and a DOS based SCADA were used with the control done within the SCADA. BOTH systems are still running to this day ! ( so much for temporary solutions )
A number of points:
1/ If its working fine dont fix it.

2/ Both systems were batch processes.

3/ The customer was made well aware of the pros and cons of
a PC based solution. ( remember this was 1990, no SoftPLC etc etc)

4/ A well engineered and planned system is the most important factor!.

Summation in my humble opinion.
a/ There is no cut and dried answer, each project must be evaluated
as to its suitability.

b/ I would still to this day thing long and hard before using PC based
control for continuos control.

c/ Batch processes are more suitable for PC based control.

d/ Some are definitely not suitable for PC control, the rest is a grey
area and as I have no bias in either direction I will give the customer
his options, pros and cons + costs, and then if the customer wants PC
based control then who am I to argue ?. Same for PLC control.

B Timm
System Integrator
(Originally posted Wed 09/02/1998)
>>Yeah, but if you crash the PLC-5 that way it points the finger
right back at you and tells you what you did! Look at location
S:12 and it points out the fault code, S:13 the program file
and S:14 the rung number where the programmers error
was made.<<

>Agree-ed... What makes you think PC-based control products can’t do this?<

In fact, the Allen-Bradley SoftLogix 5 does the same thing, using the same registers - S:12, S:13, and S:14.
Dave Lillie
SoftLogix Extensions Program Manager
Rockwell Software Inc.
(Originally posted Thu 09/03/1998)

<snip> Should I tell
you about the site where a $14M machine is subject to a random bit set in
PLC memory by a VAX ‘loosing it’ during every month’s end reporting (so far
the bits so set have been ‘benign’)?<snip>

Can you clarify. Was the VAX communicating with the PLC and trashing it via comms or was the VAX THE PLC and the accounts machine as well???
(Originally posted Thu 09/03/1998)
Phil O’Meley wrote:
I would say that by your small amount of NT work is in the office >environment
running software that in itself would make the most precious of >operating
systems real time or not crash!

If it weren’t for your other comments, I would think that this was intentional flame bait. This belief is exactly why Linux advocates can appear to be religious zealots. We do not believe nor willingly accept that applications should be able to crash an OS. The only acceptable cause for an OS crash is hardware failure.
What really makes me sick, is not that other people are willing to put of with this garbage, but that I am forced to put up with these systems on my desktop. I am putting in MM’s that run on NT, but not without backup systems, and not in a setup where the loss of the NT box will result in unsafe operations.
(Originally posted Thu 09/03/1998)
---“H. Ahrens” <[email protected]> wrote:
System 1: ..... big clip.

I’m not a vendor, so can’t give you your prices, but can give you ours.
System I am putting together right now (first machine in shop now).
8 axes of control (+/- 10 VDC, incremental encoder feedback)
53 DI, 28 DO, all 24 VDC
Plus flag, limit, and fault inputs from each drive.
Must talk to UNIX host.
18” XGA (1280 x 1024, 65k colors) industrial flat touch screen. ($7500) Custom made control cabinet holds PC, flat panel, all operator I/O (A-B 800 series buttons and joy sticks), keyboard, AC control, and alarm tower ($1500)
Air conditioner for above ($1200)
PC in custom box - Pentium 2, 333 MMX single cpu - standard components on AT motherboard ($3000) - includes removable SCSI hard drive for quick replacement.
Delta Tau motion controller cards (Ultralite, and remote Macro stations communicating across 125 Mbit (not a typo, 125 Mbits/second) fiber optic ring, up to 144 DIO at one station, plus 32 IO at each motor station (2 ea on ring) and 4 AI at each motor station. $15000 for all cards, fiber, power supplies, etc.
$1500 for miscellaneous (wire, terminal blocks, etc)
So, under $30k (can drop that quite a bit if move from flat panel display) we’ve got all controls, a huge graphical display. You do need to add drives and amplifiers to this, of course, but this system will control whatever you want in the way of drives. Talks across ethernet to a UNIX host which holds patterns to be cut, schedules patterns, and provides preliminary nests (nests can be modified or generated on operator PC very quickly). Production information goes back to the UNIX box. NT 4.0 running on workstation. This is an upgrade from existing NT system, btw. New machine, but nothing more than modification of existing capabilities. Existing NT based control systems in place more than four years - plants love them.
One big improvement is wiring. Nothing but power cables and two tiny fiber lines running to each motor cabinet. Plus e-stop circuit, of course.
Davis Gentry
Carpenter Company
(Originally posted Thu, 3 Sep 1998)

Great comments!! However, I would like to add one thing to your comments about PC’s. When you really understand the the PC’s hardware and the evolution of Windows, 95, NT since the days of the 8088 processor and Hard drives, we find the reliability and MBTF has really gone down hill. Example: With Western Digital, Quantum, Segate hard drives lucky to get 2 years before they die. Before we got, 5 years. PC’s and components are throw away. In comparing old technology, I gave an old AST 386 (1998) to my sister, she thinks it is great in 10 years it has yet to die. The PC game is not about us in Industry, we are too small for MS to worry about, but corporate IT and financial makes the decisions on the platforms. Guess, who controls the money and makes the standard. We can whine, but it won’t do us any good. Make the best with MS and other vendors and find the best tools and make production work.
MS and Intel is selling the $1,000 PC. The PC is now an appliance and every home will have one. To do this the PC must be stripped to get the cost down. This is the same hardware we are being asked to put into factories. Death is imminent!! NT 4.0 has about 26 million lines of code and NT 5.0 will have 40 million lines of code. Now really, how much of this code do you really think MS can really debug. Guess who is quality assurance? Is NT really a multi-tasking system, or is it hype versus making legacy software with a nice front-end. Other Issue on PC’s is components quality (off -shore cloning) on the Mother Board and ISA or PCI Boards will go down. Another point is with PC Power Supplies. They use cheap fast switching PS, (not linear) and have no clamping on each leg of the rectifier for voltage spikes. As we get voltage spikes over the wire the output current drops, our PC slows down. Need APC UPS to help this. Does the customer really understand. Unfortunately they only look at the cost not the reason, and sometimes could care less. On the Microsoft front, NT blue screens will continue, because underneath the covers is more of a hardware based system, in some cases I have seen cases with a non certified NT MB (don’t ask what certification means in this case) the PC will run for awhile with no apps running, then all of a sudden “BLUE”.
Because technology advancement is needed in the PLC’s because functionally they are limited in data capabilities. Keep the industrial ruggedness found with PLC’s, and expanded the structure of memory and treat like a PC and allow a common kernel to be used. Allow Java objects and other applications reside in the same box, plus keep ladder and add the rest of the newer PLC programming tools. This way, when data needs to be moved up through the enterprise provide a TCP/IP port along the side of the proprietary communication ports. Other applications could then use exception report handling by getting an instance of the objects data which is being updated in ms by the PLC.
Lets be careful and strip out our control projects using sound judgement and good engineering practices. Usually good common sense will work. On the other side, it would be good for vendors and new engineers to listen to us who have been around (10-30+ years) and understand where we are coming from. After a few projects, they would learn too. Usually, by learned mistakes and the experience of knowing how to listen.

George Robertson

(Originally posted Fri 09/04/1998)
Could someone provide examples of PC based control products that do this? I can’t think of any at the moment. It would be possible, but you would have to usurp all but the lowest levels of the operating system to guarantee that your code would be able to trap any errors. Then you’re back to asking why you moved into PC based control in the first place.
[email protected]
George Robertson
Saulsbury Industries

Johnson Lukose

(Originally posted Thu 09/03/1998)
>I continue to enjoy the debate over PLCs vs. PCs. Unfortunately, it seems
that their are two camps. People who like PLCs and don’t trust PCs for
control (or are suspicious of it), most of whom are real life users,
programmers, engineers, etc( I consider myself to be in this category). and
those who are wedded to the PC idea.<

>The other group (pro-PC) appears largely to be composed of people with a
(direct or indirect) stake in the PC for controls business.<

Especially, I like to hear from users who will spend thousands to millions on the BIG IRON / PLANT but try every trick in the book to skimp on the control systems!

Johnson Lukose

(Originally posted Fri, 04 Sep 1998)

> What really makes me sick, is not that other people are willing to put of with this garbage, but that I am forced to put up with these systems on my desktop. <

Yes, I agree with you, but for the millions of people who think Wintel is the only computer system they ever know, this was liberation!! Prior, computers were glass house, white-coat, high-priest, etc. Ordinarily, the man in the street could only read about it in papers and watch it in movies. Along came IBM’s blunder and Bill Gates’ marketing brilliance!! Let’s not take it away from them. Nobody has done more for computing!!

Kerry L. Schrank

(Originally posted Tue 09/01/1998)
> For example, what is really needed is for someone like PLC Direct to get Koyo to develop several PC-based CPU modules for their Direct 205 PLC. ...<

Check out PLC Directs new 1998 Fall catalog on page 21. There is exactly a PC-based CPU module for the Direct 205 PLC that runs Think&Do’s flowcharts. This new CPU is called a WinPLC that is a fusion of PC and PLC technologies.

Best Regards,

Kerry L. Schrank
Think & Do Software
(Originally posted Fri 09/04/1998)

You raise an interesting point. Asking in ignorance --- when we look at the average time to upgrade for a PC used either in business or home, is there a new standard for life expectancy? In other words, if Joe Bloggs is probably going to upgrade his hard drive in 3.2 years, why should a hard drive manufacturer develop a product that lasts more than four years. Do we have defined failure times based on buying trends rather than a lust for quality?
D. Mitchell Carr, Technical Manager - Strategic Marketing
Eurotherm Controls Inc
(Originally posted Fri 09/04/1998)
PC direct control is as reliable as PLC control. Fundamentally the electronics are the same! So reliability is in the software design. Utilization of proven RTOS, like QNX, and years of proven operation with software like OMNX OCS, makes the question of which platform a difficult choice where analog control is involved. When one considers the additional capabilities of the PC software, ease of use, cost, and the reliable hardware platforms available today, I agree with Steve, PC control is a clear choice by those of us who have used both in our factory automation.

Dan Hollenbeck

(Originally posted Fri 09/04/1998)
>Could someone provide examples of PC based control products that do this?<

SoftPLC’s SoftPLC product, own embedded RTOS
Allen-Bradley’s SoftLogix 5, Win NT
both using the same registers as the AB PLC-5 S:12, S:13, and S:14.

>I can’t think of any at the moment. It would be possible, but you would have to usurp all but the lowest levels of the operating system to guarantee that your code would be able to trap any errors. Then you’re back to asking why you moved into PC based control in the first place.<

I don’t know about AB’s Soft-Logix but, SoftPLC has it’s own built-in control logic interpreter just like the AB PLC-5. Therefore, it supports online run-mode programming, and can trap runtime programming errors such as DIV by Zero.
When it is all said and done with, a PLC is just a CPU with an OS that runs a firmware control logic interpreter.
Now if your PC-based control product simply compiled the control logic into machine code you might have to ask some questions.
(Originally posted Fri 09/04/1998)
Does your application meet the intent of the Challenge? Using a DeltaTau motion control card offloads all of the “real time control” to the DSP’s and CPU on the PMAC. I am familiar with the DeltaTau PMAC and know that you program it separately with its own language and download it to flash ram on the PMAC where it executes.
What is the PC doing in your application? HMI only? Some other process control?

Garth Gaddy
(Originally posted Fri 09/04/1998)
In fact, Steeplechase does this exact thing. If my flowchart logic causes a fault - say a “divide by zero” or an “array out of bounds” error, then I get a dialog that says a fatal error was encountered and what it was. On that same dialog is a “Go to Error” button. When I click it, it opens the program at the exact place where the error occurred.
BTW: Chrysler Kokomo Transmission Plant tells me they are running 3 shifts and making 2300 transmissions per day with Steeplechase.
(Originally posted Fri 09/04/1998)
Good point. If we were running a continuous process in which the loss of the PC would result only in the loss of the HMI I would agree that this does not meet the intent. Our system certainly has a portion of the programming residing continuously on the PMAC card. This is the portion which reads and writes the I/O. Our code resides on the NT PC, and handles all of the logic for that I/O. It also reads orders from the UNIX systems, then translates those orders into motion control code (still up in that air as to whether we will use strictly G-code, PMAC style code, or a combination), and passes that code *on a move by move basis*. So if the PC goes down all production immediately stops. As the control logic resides entirely on the PC, and the PMAC is merely acting as an I/O system, an interpreter and a drive controller, then yes, I think it does meet the intent. Much the same way a GE FANUC motion controller operates - a CPU handling housekeeping, and a motion controller card with an independent CPU handling the drives.
Davis Gentry
(Originally posted Fri 09/04/1998)

Lets get out of the spec’s for a minute and get back into the real world of what actually happens in the factory (Pulp&Paper, Semiconductor, Food processing plants etc.—I have spent 20 years doing integration, installation, etc- a lot of upgrades small and large projects). First, production does not have the expertise to do upgrades on the PC. Second, they expect the system to run 24 x7 X 365 days around the clock. Hard Drives are a failure component. They are now in a small foot print 3-1/2” running at 7200 and 10,000 RPM. The spindle is constantly spinning with a lot of heat build up. There are also environmental particle problems (some nasty environments no matter what extent we go through to protect). HD Manf. can produce lots of revenue with the current marketing scheme, this is the game (I can deal with it). As the result, the end user will spend more money to keep the system up todate. I can tell that this is a big concern for some companies that have many PC’s. The manhours also to do upgrades all takes time, all due to the failure ratings of components. You know, we use to care about MBTF, now we don’t even bring up the subject. There has been good articles written about this subject, too.
The other issue is the NT registery, every application require registration including any objects and DLLs. The registery gets defragmented just like our hard drives. Fortunately, MS has a tool to try to clean up the register. The other problem is that the repair disk does not always work 100% to do a repair. When was the last time you updated the registery, what about the network? The only tool that I know about to help solve this problem is ghost.exe.
Keep in mind that I have been the Project Manager and installed some very large distributed SCADA, HMI, PLC and DCS client/server applications for process control. Each has had raid and back up systems using the top name brand computers like Compaq, Dell, IBM, Generic, HP, and DEC. In addition to being a controls engineer, I also am a NT Administrator and MSCE. This last year I installed redundant DEC Alpha’s 4300 clustered together using Clustering technology from DEC for a SCADA.
Hope this helps. I know it is lengthy, but points outs some the technical issues.
Rod Parry
The point is, we need to strive to put in the most realible hardware we can. Today with the technology we need plans and strategies on how to most effectively deal with these issues in order to keep are up time to the highest levels.