Today is...
Monday, March 27, 2017
Welcome to the Modbus Community, about
the world's leading automation protocol.
PC based Control .vs. PLC
I am interested if anyone in the group has any specific reasons why they are still buying PLCs and not PC based controllers. (Originally posted Tue, 25 Aug 1998)
By Don Baechtel on 3 November, 1999 - 11:55 am

Are there any features or properties that a PLC has that PC based controllers do not?
Specific reasons that are affecting your purchasing decisions are very appreciated.
What could we do that would change your mind ?
Thanks.

By Herman De Schepper on 3 November, 1999 - 12:00 pm
1 out of 1 members thought this post was helpful...

(Originally posted Wed, 26 Aug 1998)
I reply on the mail sent by Don Baechtel.
There are reasons why the PLC is still used and popular :
-The reboot time is minor compared to a PC (this can be important in some industries)
-The cycle time of the PLC can be made deterministic ; you know the sequence in which the program is executed.
-Reliability: a PLC that runs doesn't crash, you can't guarantee this with a PC
-The PLC hardware is robust + you don't have to remove a frame to exchange cards (in case of a defect). With some PLCs you even don't have to cut off the tension.
-The technical maintenance personel is more familiar with the PLC; this counts as well for programming as for hardware problems.
-Security reasons

In general, I think that the PC still has to prove its reliability in many industries. As long the real-time processing is more important than the information processing, the PLC is in favor.

Herman De Schepper
Technical coordinator PLC
Process Systems
Egemin N.V. Belgium

By Andy Piereder on 3 November, 1999 - 12:15 pm

(Originally posted Thu, 27 Aug 1998)
I would like to add that many automation applications simply do not require even all the features and power of current PLC models. The low price of many PLCs often means that many PLCs are 'oversized' for the applications they are implemented in.
In view of this, PC control in its traditional sense would seem to be destined to remain a specialized, high-end application. On the other hand, new offerings that blend OI functionality with controllers and CE based OSs offer the potential of real cost and space savings as well as programming and communications flexibility.
As has been historically the case, new technologies don't replace old ones, but simply broaden the palette of solutions.

Andy P.

(Originally posted Mon, 31 Aug 1998)
>>There are reasons why the PLC is still used and popular: - The reboot time is minor compared to a PC (this can be important in some industries)<<

Depends on the BIOS ... most good IPCs have a BIOS option for fast boot.

>>- The cycle time of the PLC can be made deterministic; you know the
sequence in which the program is executed.<<

Use an IEC1131-3 environment and a RTOS like QNX and your PC based solution will be more predictable than the PLC solution.

>>- Reliability: a PLC that runs doesn't crash, you can't guarantee this with a PC<<

Interesting ... a PLC that runs doesn't crash?? Why??

>>- The PLC hardware is robust + you don't have to remove a frame to
exchange cards (in case of a defect). With some PLCs you even don't have to cut off the tension.<<

With our PC and fieldbus based solution you can exchange the IO modules at run time! (as long as a clean bus topology is used .. e.g. like PROFIBUS or CAN ... )

>>- The technical maintenance personel is more familiar with the PLC; this counts as well for programming as for hardware problems.<<

With IEC1131-3 and the usage of fieldbusses. I don't see any differences ...

>>- Security reasons<<

Well chosen embedded PC hardware has the same quality as the PLC hardware.

>>In general, I think that the PC still has to prove its reliability in many industries. As long the real-time processing is more important than the information processing, the PLC is in favor.<<

A PC solution under QNX gives you a better real-time behavior and the possibilty to use the information processing and communication features ...

Armin Steinhoff
http://www.DACHS.net

(Originally posted Mon, 31 Aug 1998)

> >>There are reasons why the PLC is still used and popular:

> - The reboot time is minor compared to a PC (this can be important in some industries)<<

> Depends on the BIOS ... most good IPCs have a BIOS option for fast boot.

$We never had to load a operating system onto the many PLCs we have, but we had to reload and configure several of our NT based IPC due to Systemcrashes!!!! What takes more time? $

> >>- The cycle time of the PLC can be made deterministic; you know the sequence in which the program is executed.<<

> Use an IEC1131-3 environment and a RTOS like QNX and your PC based solution will be more predictable than the PLC solution.

$ Pretty exotic OS stuff you have to use. What about NT? $

> >>- Reliability: a PLC that runs doesn't crash, you can't guarantee this with a PC<<

> Interesting ... a PLC that runs doesn't crash ?? Why ??

?B'cause it is made from one block, whereas IPC is a mix of materials aout of a toolbox?

> >>- The PLC hardware is robust + you don't have to remove a frame to
exchange cards (in case of a defect). With some PLCs you even don't have to cut off the tension.<<

>With our PC and fieldbus based solution you can exchange the IO modules at run time !

> (as long as a clean bus topology is used .. e.g. like PROFIBUS or CAN ... )

> >>- The technical maintenance personel is more familiar with the PLC; this counts as well for programming as for hardware problems.<<

> With IEC1131-3 and the usage of fieldbusses ... I don't see any differences ...

> >>- Security reasons<<

> Well chosen embedded PC hardware has the same quality as the PLC hardware.

> >>In general, I think that the PC still has to prove its reliability in many industries. As long the real-time processing is more important than the information processing, the PLC is in favor.<<

> A PC solution under QNX gives you a better real-time behavior and the possibilty to use the information processing and communication features ...

$Might be with QNX, but NT stuffed my last x-mas party, when the IPC thought the Profibus was running, but as a matter of fact it didn't. The vessel was loaded with a exotermic process. We just had luck.$

$Conrad Vinzens, cvinzens@eurnotes.sial.com

By Gabriel Suarez on 20 June, 2000 - 5:45 pm

My opinion. PLC´s technology is in the final countdown. The new embedded systems PC-104 or 51/4" or others with the fabulous potential (Pentiums III, etc.), electronic flash disk (40mb/s), etc. combined with hundreds of rugged periferics are redundant most powerful. This systems are PLC´s murders. Programs in hundreds of languages extends the possibilities. And RealTime OS (RTLinux, QTX, etc.) destroy all barriers. GABRIEL SUAREZ. EGROJ. ARGENTINA

By Edgar Hilton on 6 December, 2000 - 5:48 pm

Especially, take a look at RTLinux's small sibling: miniRTL (runs on a minimal PC-104 system). If you want minimal system and controlling capabilities, along with secure shells for remote monitoring over a tcp/ip interface, then miniRTL is the way to go.

I am working on a project for school. I am an industrial eng major. The school will not limit me to any resource however i am in a dead-lock. We are trying to create a real-time or near realtime remote monitoring device/network. We have a gould centrafugal pump that is pumping water. . . We want to measure dB(roller bearing life), PSI, Temp(water), etc. . . We have the networking for attachment to remote server via internet. We want to use a laptop PC to monitor the pump station, but not aware of any software availabe that will run on a windows or lynix based OS(keeping in mind we want to do this with out a PLC). Also, what hardware would be recomended to attach our PC to the pump? Basicly we are totaly lost!!! I am in charge of putting the data onto the internet for remote access, but if we can not get the data from the pump we can not put the data on the internet. Please some help!!!!!!

By keith lawson on 11 November, 2001 - 1:20 pm

Phone an instrumentation company up and ask them. National instruments can supply the IO and the hardware you need as well as the software. They can be found at:

"www.natinst.com":http://www.natinst.com

LabVIEW software would be the easiest solution to your problem.

E-Mail or phone them.

By anbuselvarajan on 19 September, 2007 - 12:33 am

MATLAB is also offering real time interface solution... "dspace" is that one. Using this you can compute highly complex algorithms for real time solution with ease.

By Mark Forrester on 27 October, 2008 - 4:31 am

To the one who is doing a school project on bearing wear: As a Navy veteran, we used DVSIs for monitoring bearing wear and approximate length of time the bearings will last. I'm not sure if you can get a hold of them, but may I suggest that you try and contact Performance Monitoring Team of San Diego, CA or PMT, Norfolk, VA. They are only two teams in the Navy (that I am aware of) that use these type of devices. They are used to determine life of bearings on certain pieces of equipment on Naval Ships as well as utilizing Thermal Graphic Image devices, used to determine the stability of breaker panels for these devices. Good Luck!

By Guy Truyens on 8 March, 2001 - 3:24 am

> I reply on the mail sent by Don Baechtel. When two opposites compete , the one that merges , will win. It's likely that PLC vendors will integrate PC technology in their products , so they will have best of both worlds. Guy Truyens. eXitec.

By Roland Wagner on 8 August, 2001 - 7:52 am

Even if PC based control spreads more and more in the automation industry normal PLCs will always be interesting, and if it is just because of the price: Propriatery hardware will in the interesting amount of devices always be cheaper than modular ones. On the other hand if more than just I/O controlling is necessary (for example like engineering, visualizing, motion control etc.), PC based solution are much more interesting even according the cost aspects.

As already mentioned in some of the authors before the technical topics in order to make PCs ready for controlling are completely solved.

Much more interesting is the question whether the programming environment keeps the same no matter if you are working with a PLC or a PC based PLC (SoftPLC). The IEC 61131-3 as an international standard and hardware independent software suppliers for that standard serve the whole range of requests.

Best Regards

Roland Wagner
3S - Smart Software Solutions GmbH
www.3s-software.com

PLC's vs. PC based control.
No contest. PLC wins.
PLC's will outperform - but most importantly will
endure over time !

What is the life cycle of a PC ?
I spent $4000 on a PC with 2 floppies and
256 K of memory a long time ago. I do not know where it is now......It had CGA monochrome graphics !
(At that time I was programming A-B PLC/5's.)
Recall those TI435's or was that GE or PLC direct or Koyos ,,,,,,,,, Still need to program one tommorrow...
Let's tell the plant manager that the line stopped due to an application error and it's a Microsoft bug.
But since the PC hardware is so cheap we can use the PC and our boss will be happy and we will make it until the next project....Maybe !
I still see PLC/5 and TI's and all the tried and true ways but that PC is know-where !!!!!!!
Jimmy


PC-Based control is a living fact in manufacturing today. General Motors Powertrain has been using PC-Based control for over 10 years. GMPT began with a DOS product and have moved to the next generation of Microsoft Windows based PC control. They have found the PC to be no more or less reliable than the PLC. The implementation of PC Based control is a part of GMPT Lean Manufacturing Stratige.

The power of the current PC processors allow the PC to run circles aroung the PLC.

The PLC manufacturers have been trying to make PLCs act like PCs for decades, why not jjust use a PC?

PCs are on the plant floor for the HMI and SCADA systems, why not just converge the technology into a single PC with control?


Ken Jones
Nematron Corporation
ken.jones@nematron.com

By Roets Johan, Technician on 28 February, 2007 - 12:11 am

Reply to PC is not so reliable. Cycle time of the PLC is the big advantage. Also reliability. The hard disk in the PC is the weak part in a PC (vulnerable to vibrations). Also programming is a point.

However when it comes to cost in particular for small applications (PLC with graphical interface) an industrial PC with bus system to i/o modules is more cost effective and has more possibilities for programming a user interface. If you want a PLC with graphical user interface (or graphical screen with interface to PLC) the cost rises considerably compared to an industrial PC. A beatiful example is the Teamster (Swedish company) glue application where an complete gluing application (gluing gun and control for robot) is controlled by a industrial PC (graphics and user interface are just magic). If you would want to this with a PLC the cost would be 3 to 5 fold. Also if you depart from a PC you have more possibilities for logging (hard disk) networking (standard), etc.

When it comes to maintenance: keyboard 6€, screen 200€, hd 50€ is much cheaper then PLC accessories. I think overall the industrial PC will make its entrance (more cost effective). With the PC also the way is open for companies to make the steering of your machine more open for low-skilled workers by working with a graphical interface. PLC manufacturers are also going this way but at a very high price for the customer. The only but is the software at the moment. If you start with PC steerings you are on your own to program it. Not only the steering but your interface also. But for manufacturers of machines that always perform the same process, I think it will make them more competitive and enable them to offer a higher grade of service to the customer at a lower price.

1 out of 1 members thought this post was helpful...

I have 30 years experience in Control systems including over 10 years as a Programmer Analyst developing PC based applications. I have much experience with PC based controls as well as DCS and PLC systems from various manufacturers. In my opinion no hardware is more reliable, robust or faster than a good PLC. In no situation has a PC based system ever come even close to reliability, performance or flexibility of a PLC (Contrologix or Unity being the best of the best).

As a consultant with a world class engineering company I (and my peers) would never in their right minds consider using PC based systems for final point control. PC's work well for advanced supervisory control but that is it. I hate even using Windoze based systems for HMI's as I believe that QNX is a far better solution. I have seen QNX HMI's run for 10 years without a reboot! No Windoze based console could ever hope to achieve this. PC's are for desktops or servers not control!

By Allan Evans on 5 October, 2009 - 5:01 pm

Hear, hear Good to read some sanity occasionally.

By curt wuollet on 6 October, 2009 - 3:50 pm

I agree for the most part and in the past, certainly. But with the PAC and the SOC low power PC with SSD. They are converging hard.

Soon the only real difference will be the software, which in my opinion has always been a major factor. PC reliability has been slandered because of the crappy software people choose to run on them. With a small tight embedded type system, I doubt you would see much difference between the Wall Plug type PC's and a high end PAC. If you load crap on both of them, you wouldn't see much difference in reliability either.

Regards
cww

By James Ingraham on 6 October, 2009 - 10:49 am

Red, I have to moderately disagree, despite the fact that my company has almost entirely migrated away from PC-based control systems.

Red said, "In my opinion no hardware is more reliable, robust or faster than a good PLC."

Well, what's a "good" PLC? Are we putting smart relays in the same category as hardware redundant PACs? Are you comparing to off-the-shelf Dell PCs instead of industrial PCs? I've seen PLC hardware fail, usually for some good reason. I've seen PCs last a decade.

Red said, "In no situation has a PC based system ever come even close to reliability, performance or flexibility of a PLC."

PCs run circles around PLCs for performance and flexibility. Reliability is a maybe. They have PCs running nuclear power plants and medical equipment. QNX is on the International Space Station, and Windows boxes are in Mission Control in Houston. There's nothing a PLC can do that a PC can't, but the reverse is patently not true.

Red again: "I ... would never ... consider using PC based systems for final point control."

Well, that's fine. But lot's of people do, and have success with it.

Red: "...Windoze..."

Name-calling does not invalidate the tremendous success of the product.

Red: "I have seen QNX HMI's run for 10 years without a reboot!"

And yet you say that the PC is not reliable. You seem to have contradicted yourself.

Red: "PC's are for desktops or servers not control!"

There are a lot of counter-examples out there. I have quite a few industrial gantry robots running on PCs, including some even on Windows.

-James Ingraham
Sage Automation, Inc.

By Ken Emmons Jr. on 7 October, 2009 - 9:08 am

I think the distinction is a reliable PLC vs. an off the shelf desktop PC with [at least] two fans, hard disk drive, CMOS battery, cheap motherboard that was designed in a hurry and not necessarily tested well, and a morphing operating system.

If you have a well tested fanless computer with solid state disk and mounted as Read-only (Linux, QNX, embedded XP, WinCE) you are starting to get into PLC territory as far as reliability. In other words you are as reliable as your fanless PC box can be, which is probably pretty good in many cases. I would also add that an industrial hardened IO system is needed, whether it is a Wago/Beckhoff networked IO or industrial plug-in card.

I've used Keyence brick PLCs for 17 years and not had a single failure (Other than one or two shorted IO points which was not its fault).

We've also used Mitsubishi Q series hardware for the last 5 years or so and not had a single failure there as well. Neither of these systems are without fault, but as far as reliability they are good.

So in the end both *Can* be made to be reliable, it just depends on who is implementing it.

KEJR

In reply to Red: So, your problem seems to be the OS used in those cases? I won't argue with you with regards to your MS Windows problems. Talking about that usually leads to a flame war here, so I'll just say that there are well known alternatives such as Linux and BSD which are at least as good as QNX if not better.

As far as the hardware is concerned, a lot of things have changed in the 10 years since the original post was made. You can get fanless motherboards and power supplies, as well as solid state drives for a very reasonable price. Some of the "embedded" hardware systems you buy these days are simply small form factor "PCs" using third party motherboards which were designed for embedded applications.

What seems to be the distinction in most people's minds these days is "PC = MS Windows". Apple's "Mac vs. PC" commercials haven't helped in that regards either, even though the Mac is using basically the same hardware today.

In practical terms though, what I would call a "PC" is any widely available general purpose computing platform that can run a 32 or 64 bit OS. You can get small laptops today that use ARM and MIPS CPUs, so x86 compatibility or the ability to run MS Windows can't be considered a criteria these days.

What I expect to see in future is the major PLC vendors putting third party embedded PC motherboards in custom cases and selling them as PLCs. They would do this for the same reason they have adopted Ethernet - cost and performance. I would expect to see this particularly in the lower volume applications, such as higher end PLCs, CNC controllers, etc. They would have a standard Linux or BSD OS supporting their software. The average user though won't know the difference.

Windows is not stable at all, there is an article in the link below:

http://indanotes.blogspot.com/2008/12/pc-stability.html

Linux is much more better, I have never experienced QNX but I believe it should be a better alternative for automation.

I believe that PLC is designed for controlling motors and machines and it is the best alternative for controlling; but it is not all of automation.

A system is really automated if it is also automatically managed, and PLC is not strong in auto-management. For automatic management, PC is the only alternative today.

I agree fully with Mr. Herman De Schepper and wish to add that implementation of redundancies in PC based control system are next to impossible.

By Curt Wuollet on 27 January, 2012 - 5:23 pm

Now that's just silly, your email probably crossed 10 redundant system getting here.
And the hardware is the easy part.

Regards
cww

By R A Peterson on 3 November, 1999 - 12:01 pm

(Originally posted Wed 08/26/1998)
1. convince me that NT will crash as rarely as a PLC5. I have yet to have a PLC5 crash on me. I've had dead ones, I can accept that. I can't accept random crashes where after cycling power "everything is fine". I have had numerous blue screens of death in my relatively small amount of NT work.

2. convince me that PC hardware (such as harddrives) is as reliable as a PLC5. I want something I can prom, flash prom, eeprom, or put into battery backed ram. no harddrives, no isa or pci bus. I'd accept a pcmcia slot, because its commonly used in the industrial control world and has had few problems (at least in my experience).

3. BTW, I think ASAP is looking at windows CE for certain platforms. My windows CE handheld computer has yet to crash! I think that the real PC control is probably not NT but CE longer term. NT is just too BIG. CE is about the right size so it can actually be adequately tested and proven. It also has the advantage of minimal outside interfrence in the OS. For better or worse, MS has a lot more control of CE then NT in this respect (for such mundane things as drivers).

4. make online programming available (I think ASAP is the only one that does this). Its a big nuisance to have to shutdown a machine to make a simple change. I'm amazed that any enduser would accept this for any decent sized machine.

5. Convince hardware makers to make a std line of hardware, with common features that are more or less interchangeable. The only thing going for the open s/w is that it runs on what amounts to an open hardware platform (the PC), which is a really poor choice for industrial control, regardless of how ruggedized it gets. Maybe VME is the long term solution (just maybe) in this respect, but a lot of PLC makers have made VME products over the years that just haven't taken off (other then the obvious 90-70 stuff that is based on VME).

6. Stop making the promise of saving money on either hardware or software.

There maybe long term advantages, but all the stories of money savings is so much bunk as far as I can tell (based solely on my experience with people who have made the switch or who were forced to make the switch for a machine or two). Maybe longer term there is some advantage, but I don't see it.

(I used PLC5 as an example - insert 984 if you want, or 90-70, etc.)

By omeleyp@OZEMAIL.COM.AU on 4 November, 1999 - 3:34 pm

(Originally posted Thu 08/27/1998)
You write:-
1. convince me that NT will crash as rarely as a PLC5. I have yet to have a
PLC5 crash on me. I've had dead ones, I can accept that. I can't accept
random crashes where after cycling power "everything is fine". I have had
numerous blue screens of death in my relatively small amount of NT work.

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!
.2. convince me that PC hardware (such as harddrives) is as reliable as a
PLC5. I want something I can prom, flash prom, eeprom, or put into battery
backed ram. no harddrives, no isa or pci bus. I'd accept a pcmcia slot,
because its commonly used in the industrial control world and has had few
problems (at least in my experience).

Your absolute faith in PLC suppliers is a tribute to their marketing, the flash disk technology today addresses your example, even the way in which soft PLC's manage the hardware also reduces the risk of this.
3. BTW, I think ASAP is looking at windows CE for certain platforms. My
windows CE handheld computer has yet to crash! I think that the real PC
control is probably not NT but CE longer term. NT is just too BIG. CE is
about the right size so it can actually be adequately tested and proven. It
also has the advantage of minimal outside interference in the OS. For better
or worse, MS has a lot more control of CE then NT in this respect (for such
mundane things as drivers).

CE, you will find is limited in its speed and application, I noticed elsewhere in this news group where a subscriber puts forward the view that the technology we all espouse is really of little consequence to the end users. It really boils down to the ability of the solution to meet the customers requirements in a cost effective and timely manner.
4. make online programming available (I think ASAP is the only one that does
this). Its a big nuisance to have to shutdown a machine to make a simple
change. I'm amazed that any enduser would accept this for any decent sized
machine.
There are others, such as Taylor Industrial Softwares Waltz, I have now used this on several project up to 160 digital I/O and 0 Analog I/O all being processed in under 30 ms. No to bad!
5. Convince hardware makers to make a std line of hardware, with common
features that are more or less interchangeable. The only thing going for the
open s/w is that it runs on what amounts to an open hardware platform (the
PC), which is a really poor choice for industrial control, regardless of how
ruggedized it gets. Maybe VME is the long term solution (just maybe) in this
respect, but a lot of PLC makers have made VME products over the years that
just haven't taken off (other then the obvious 90-70 stuff that is based on
VME).

You should try STD bus, its pretty good, we used it in a couple of applications where it performed admirably.
6. Stop making the promise of saving money on either hardware or software.
There maybe long term advantages, but all the stories of money savings is so
much bunk as far as I can tell (based solely on my experience with people who
have made the switch or who were forced to make the switch for a machine or
two). Maybe longer term there is some advantage, but I don't see it.

(I used PLC5 as an example - insert 984 if you want, or 90-70, etc.).

The main cost saving we have made for our customers is in the portability of the process knowledge across various or a mixture of I/O vendors. Consider this customer a wants process to operate in their plant. You are one of the recognised leaders in this field and your IP is in the software. Unfortunately you have written the process in GE and they are insisting on AB, you are now forced to re write the code in AB and pass this cost onto the end user. Along comes the scourge of the control world, Mr PC controller user, his process knowledge is not as advanced as yours but he doesn't penalise the end user by saying you want AB you gotta pay for it, he says no worries, increases his price marginally to cover the re mapping of his I/O, but knowing the industry he can increase his price again, and still be cheaper than you, while investing part of this money in improving his process software or MMI. In this example the customer gets a quality product at a reduced price, Mr PC controller improves his product, while you just lost the job. True story!!!!
I suggest to the group that each technology has its place, as our customers are forced to be more cost effective then so we must by providing them the best system at the best price. In the last 15 jobs we have undertaken we have used everything from a Z World controller through Modicon / AB PLC's and onto Taylor's WALTZ controller. All of them represent success all of them represent engineering difficulties, all of them suited the customers need.
Yours sincerely
Phill O'Meley

By Mark Blunier on 10 November, 1999 - 6:40 pm

(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.
Mark

By Johnson Lukose on 11 November, 1999 - 3:46 pm

(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!!

By Nick Busigin on 15 November, 1999 - 11:07 am

(Originally posted Mon, 07 Sep 1998)
Actually, I disagree that IBM and Bill Gates have done more for computing than anyone else. On the contrary, I think that their companies have held back progress in computing. Back when MS and IBM started out, there were already better technical solutions (for that time period) beginning to be commercialized (eg. Digital Research's CP/M and MP/M and the S-100 bus architecture). These didn't reach a critical mass because they were abandoned in favour of inferior technology with better marketing. I contend that there has been an incalculable waste of programming time spent on the programming of work-arounds to the deficiencies in MS and IBM technology. What I will give Microsoft and IBM is that they demonstrated that when technology goes up against marketing, marketing usually wins.
Nick

By R A Peterson on 15 November, 1999 - 11:41 am

(Originally posted Tue, 08 Sep 1998)
I don't entirely agree. CP/M was a neat 8 bit operating system (try a 1kbyte BIOS for Z80-good trick), but it faltered in going to the 16 bit world and allowed ms to take over. I did a fair amount of programming in z80 cp/m and thought it was really slick. cp/m86 was slow coming out of the blocks, horribly marketed, and then left to die, but admittedly somewhat superior to msdos (faster, smaller, etc.)
I would argue the s100 bus was as good as the PC bus, but no better and the PC bus is slightly less expensive. The s100 bus also had the bad rap of being a hobbyist bus. This tended to scare off the business users.
What really killed off cp/m wasn't just ms but also the venders of s/w that never bothered to write s/w for cp/m86. Msdos was what they chose to write s/w for, and with few apps, it withered and died.

(Originally posted Tue, 08 Sep 1998)
Again, almost true. The story is that Marketing wins everytime over technology. In this case, Gary Kildall, the CEO of Digital Research, refused to meet with Don Estridge and the IBM "suits", so he left it up to his wife and others. They didn't do very well at presenting CP/M-86, but IBM decided to offer it with the PC at a significantly higher price than MS-DOS. By the way, IBM went to MS only because BASIC was not available on CP/M-86, but MS supplied BASIC to Apple. Once at MS, Bill Gates found that IBM was intending to offer CP/M-86, so he did an overnight Master Distributor contract with Seattle Microsystems, had his programmers work overnight to construct a demo of it, made the demo to IBM the next day, and offered to allow IBM to private-label it PC-DOS. IBM offered PC-DOS for about $90 and CP/M-86 for about $260. The rest is history and a no-brainer.
Dick Caro
Richard H. Caro, Vice President
Automation Research Corporation

By Nick Busigin on 16 November, 1999 - 3:56 pm

(Originally posted Tue, 08 Sep 1998)
>I would argue the s100 bus was as good as the PC bus, but no better and the PC
bus is slightly less expensive. The s100 bus also had the bad rap of being a
hobbyist bus. This tended to scare off the business users.<

Back then, I liked the s100 bus architecture better than the PC bus - as it was meant to be modular/open. ie. You could swap CPU boards (say go from a Zilog to an Intel or even to a Motorola CPU) and leave the rest of your hardware intact (memory boards, disk controllers, etc.). Well, that's the way it worked most of the time. ;-). Also, the s100 bus systems of the day had a 24 line address bus compared to the short-sighted 20 line address bus of the IBM PC. I recall s100 bus systems with 68000 CPUs running UNIX being available at roughly the time that the first IBM PC came out. By comparison, the original IBM PC was a toy and more of a hobby machine than the then extant s100 bus systems.

>What really killed off cp/m wasn't just ms but also the venders of s/w that
never bothered to write s/w for cp/m86. Msdos was what they chose to write
s/w for, and with few apps, it withered and died.<

Very true, but I still contend that marketing won out over technical merit.
It's interesting to look back and see the path we took to arrive to where we are today. ;-)
Nick

By Curt Wuollet on 16 November, 1999 - 5:02 pm

(Originally posted Thu 09/10/1998)
Hi, Nick
The fact that IBM made personal computers legitimate with their marketing muscle wasn't all bad As I remember, the S100 machines were pretty spendy ( I had a Cromemco) we should give them credit for making them ubiquitous. The bad part is how little thing have changed since then. We still live with a lot of zany engineering "features" of the original IBM's. (segmented addressing, very limited hardware interrupts, "the BIOS" etc.). As an example of a technically inferior design becoming the "standard", it rates right on up there with the Windows stuff.
Curt Wuollet
Heartland Engineering.

By Johnson Lukose on 16 November, 1999 - 10:31 am

(Originally posted Tue, 08 Sep 1998)
I myself have taken pokes at MS technical holes. It was my point to say that IBM and Microsoft whether by blunder or design made systems affordable and within reach to everyone in this world not just in the USA. Was any CP/M, MP/M or S100 systems available in this part of the world? Could I afford CP/M, MP/M, S100 systems? Do you think the 'owners' of CP/M, MP/M or S100 technology would have driven the prices down let alone push the technology as Wintel? What would be the price of an equivalent CP/M, MP/M, S100 systems equalling 80386, 4MB RAM, 250MB Harddisk, VGA, OS in 1990? What would be the price of an equivalent CP/M, MP/M, S100 systems equalling PII-266MHz, 64MB RAM, 4.1GB Harddisk, SVGA, 56K Modem, OS, Winsock, Internet Browser, Internet Mail, Anti-Virus, Audio and Speakers today? I bought mine from Dell for RM5500.00 (~US$1500). Even the books were expensive back then, you could buy a monitor for the price today!
In my country the PC industry had it's beginnings with the 'Pineapples' - Apple clones from Taiwan. The computer shops were sprinkled miles away, almost clandestein, the traders had too, as a slight sneeze from the US and these shops will be raided by the Trade Ministry. Then came the IBM PC, the whole paradigm has turned on the head. Today there is a legitimate computer industry in the billions of RM and perhaps you have heard of MSC (Multimedia Super Corridor) initiative.
NO, I remain - Nobody has done more for computing than IBM and Bill Gates!!
Let's not take it away from them.
thanks.

By Phill O'Meley on 15 November, 1999 - 11:06 am

(Originally posted Mon 09/07/1998)
Without wishing to enter into a slanging match over NT vs Linux or continue in the vein of other threads, I agree that you shouldn't have to put up with any application crashing an operating system.
I suppose I am from the engineering school that like a challenge and say restores old cars that were less than perfect examples of engineering in their time ie Model T Fords to perfect examples of my skill in making it work. Well, for me making an NT system behave in an acceptable manner was a challenge and with help from a couple of sources we have been damn well successful. I chose the WALTZ / NT path as I was fed up with loosing work because we were perceive as the "Brand X" vendor when the site was using "Brand Y", Then the bit about the process knowledge comes into it as well.
So please accept my apologies if my comment raised your ire, however, beta max, MAP, and some really great engineering concepts are now dead. Why, because the commercial and marketing forces of our world have a louder voice than the engineering bodies. So instead of trying to stop the tide I thought working with it would feed our employees longer and give us a better start than hose that fight against it.
Regards
Phill O'Meley
PS If you can give me a shrink wrapped soft PLC running on Linux then I would look closely at it........

By David McGilvray on 15 November, 1999 - 11:55 am

(Originally posted Tue 09/08/1998)
> PS If you can give me a shrink wrapped soft PLC running on Linux then I would look closely at it........ <

Check out AutomationX at www.mnrcan.com.
David McGilvray

By Curt Wuollet on 16 November, 1999 - 3:59 pm

(Originally posted Wed 09/09/1998)
> > PS If you can give me a shrink wrapped soft PLC running on Linux then I would look closely at it........ < <
> Check out AutomationX at www.mnrcan.com.<

Thanks for the link to M&R.
This way we could offer a reliable, powerful, non-proprietary product.
Or, if the customer insists, offer it on NT.
Thanks again
Curt Wuollet
Heartland Engineering

By Mark Blunier on 16 November, 1999 - 10:26 am

(Originally posted Tue 09/08/1998)
>Without wishing to enter into a slanging match over NT vs Linux or continue in the vein of other threads, I agree that you shouldn't have to put up with any application crashing an operating system. ... I chose the WALTZ / NT path as I was fed up with loosing work because we were perceive as the "Brand X" vendor when the site was using "Brand Y", Then the bit about the process knowledge comes into it as well.<

Unfortunately, its the chicken & egg syndrome.

> So please accept my apologies if my comment raised your ire, however, beta max, MAP, and some really great engineering concepts are now dead. Why, because the commercial and marketing forces of our world have a louder voice than the engineering bodies. So instead of trying to stop the tide I thought working with it would feed our employees longer and give us a better start than hose that fight against it.<

I believe that in a few years, we will see Linux solutions that are currently NT only (or NT mostly), but for now I'll have to wait.

> PS If you can give me a shrink wrapped soft PLC running on Linux then I would look closely at it........<

While I would prefer something based upon Linux (when it supports real-time without needing patches), Regardless of what OS is running, unless the hardware quality is improved and hard drive are not needed for the system to run, I'll stick with a PLC. I am pro Linux, be even so, I still feel the PCs in there current state are not good platforms. I would consider a 'PC' system with an embedded kernel.

By Phill O’Meley on 16 November, 1999 - 3:54 pm

(Originally posted Wed 09/09/1998)
I am currently reviewing the Venturecom reduced NT product that may
behave as we would all like to see, I will keep you informed of the
outcome, or is there anybody out there with experience in this product
Regards
Phill

By steinhoff@STEINHOFF.DE on 5 November, 1999 - 3:09 pm

(Originally posted Mon, 31 Aug 1998)
PETERSONRA@AOL.COM wrote:
1. convince me that NT will crash as rarely as a PLC5. I have yet to have a
PLC5 crash on me. I've had dead ones, I can accept that. I can't accept
random crashes where after cycling power "everything is fine". I have had
numerous blue screens of death in my relatively small amount of NT work.

IMHO, any PC hardware plus NT doesn't lead to a reliable solution.
2. convince me that PC hardware (such as harddrives) is as reliable as a
PLC5. I want something I can prom, flash prom, eeprom, or put into battery
backed ram. no harddrives, no isa or pci bus.

We also use PC/104 modules ... no hard drive, no backplanes.
I'd accept a pcmcia slot, because its commonly used in the industrial
control world and
has had few problems (at least in my experience).

I would never trust that PCMCIA stuff ...
3. BTW, I think ASAP is looking at windows CE for certain platforms. My
windows CE handheld computer has yet to crash! I think that the real PC
control is probably not NT but CE longer term. NT is just too BIG. CE is
about the right size so it can actually be adequately tested and proven. It
also has the advantage of minimal outside interfrence in the OS. For better
or worse, MS has a lot more control of CE then NT in this respect (for such
mundane things as drivers).

There are viable alternatives to NT and CE ...
4. make online programming available (I think ASAP is the only one that does
this).

Wrong ... it's also supported by other IEC1131-3 packages
Its a big nuisance to have to shutdown a machine to make a simple
change. I'm amazed that any enduser would accept this for any decent sized
machine.

That's the reason why ProConOS for QNX (the target for MULTIPROG wt) allows online changes and online handling of IEC1131-3 tasks.
5. Convince hardware makers to make a std line of hardware, with common
features that are more or less interchangeable. The only thing going for the
open s/w is that it runs on what amounts to an open hardware platform (the
PC), which is a really poor choice for industrial control, regardless of how
ruggedized it gets. Maybe VME is the long term solution (just maybe) in this
respect, but a lot of PLC makers have made VME products over the years that
just haven't taken off (other then the obvious 90-70 stuff that is based on
VME).

There are a lot VME/PC solutions in the market. Don't forget CompactPCI.
6. Stop making the promise of saving money on either hardware

Yes, you don't save money at the hardware site... if you use the same quality of hardware.
or software.

The software is the key for big savings. What costs the TCP/IP software for a PLC5 ?
(if available ..)
There maybe long term advantages, but all the stories of money savings is so
much bunk as far as I can tell (based solely on my experience with people who
have made the switch or who were forced to make the switch for a machine or
two). Maybe longer term there is some advantage, but I don't see it.

The PC technology is more open ... so you can realize solutions which are not possible to realize with proprietary PLC hardware (and software).
For instance: one of our customers has tried to realize a control system for driverless fork lifts with the Siemens S5 series of PLCs ... and they failed because of technology barriers at the hardware site and the software site.
They are now very successful with an embedded PC running QNX, PROFIBUS-DP and an IEC1131-3 programming tool for QNX targets.
Regards
Armin Steinhoff
http://www.DACHS.net

By jeg@dsautomation.com on 5 November, 1999 - 3:11 pm

(Originally posted Mon, 31 Aug 1998)
Crashing a PLC5 is not as hard as you think. Insert a PID instruction and accept all defaults.
Jay E. Grassel
Data Science Automation Inc.


>>1. convince me that NT will crash as rarely as a PLC5. I have
yet to have a PLC5 crash on me. I've had dead ones, I can accept that.<<

By hahrens@DIRECT.CA on 10 November, 1999 - 5:04 pm

(Originally posted Tue 09/01/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.
Hugo Ahrens, Project Manager
IAI Industrial Automation Inc.
http://www.plc-control.com

By hollenbeck@INVOLVED.COM on 10 November, 1999 - 5:09 pm

(Originally posted Wed 09/02/1998)
Agree-ed... What makes you think PC-based control products can't do this?

> 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.

By Hugo Ahrens on 10 November, 1999 - 5:53 pm

(Originally posted Wed 09/02/1998)
>Agree-ed... What makes you think PC-based control products can't do this?<

I hope a well designed software PLC application will do the same as a real PLC, and point out runtime errors. What I see happening though, is that when we talk about PC control we do not only refer to software PLC applications. I see (and l consider myself lucky for being a bystander in most of these situations) programmers using the, to them standard tools, to create apps that sometimes also affect the control. Then there is a big hassle in getting to the cause, because we have to "prove" the origin. 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')?
Hugo Ahrens, Project Manager
IAI Industrial Automation Inc.

(Originally posted Thu 09/03/1998)
Hugo,

<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???
Thanks,
Mitch

By Pablo Cussatti on 10 November, 1999 - 6:00 pm

(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

By Dave Lillie on 10 November, 1999 - 6:36 pm

(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.
http://www.SoftAutomation.com/SLX

By George Robertson on 11 November, 1999 - 3:30 pm

(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.
ggrobertson@mindspring.com
George Robertson
Saulsbury Industries

By Dan Hollenbeck on 15 November, 1999 - 10:54 am

(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.

By George Robertson on 15 November, 1999 - 11:00 am

(Originally posted Fri 09/04/1998)
So with softPLC, I can't get the blue screen of death?
ggrobertson@mindspring.com
George Robertson
Saulsbury Industries

By Dan Hollenbeck on 15 November, 1999 - 11:40 am

(Originally posted Tue 09/08/1998)
Correct. The blue screen of death only applies to PC based control products that use Win NT. SoftPLC has it's own RTOS, which means it controls the source code to the RTOS.
By the way, there are many other PC based control products that don't use Win NT.
As a PC based control vendor you risk your your personal, product, and company reputations on the controller's OS. As a customer you risk much much more. Where do you want MS to take you today?
This is also true of the PLC vendors, products, and users, however the PLC's OS is on the firmware.

Daniel Hollenbeck
SoftPLC Corporation
http://www.softplc.com
hollenbeck@involved.com

By Robert Holman on 16 November, 1999 - 10:27 am

(Originally posted Tue 09/08/1998)
I have used softPLC on a number of projects (I use both PC and PLC depending on the customer). That is correct, you won't get the blue screen of death with softPLC. It is like using an A-B 5/25 but it also eliminates some of typical PLC limitations such as scan time (just run with a faster CPU), memory (just add some RAM to your PC box), you can add ethernet communications to talk to the rest of the world and I can talk to it remotly with a modem. And you still have all the functions of the A-B registers to monitor what its doing (yes, via the modem too).

Robert Holman

By Johnson Lukose on 16 November, 1999 - 5:00 pm

(Originally posted Wed 09/09/1998)
If PC based control is about slapping on an Intel microprocessor with everything else proprietary, every man and his dog is offering PC based control. So there is the answer, we no longer need to waste our breath / keyboards on this PLC vs. PC based control debate??
thanks.

By Dave Lillie on 16 November, 1999 - 5:05 pm

(Originally posted Fri 09/04/1998)
>"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."<

A couple of points need to be clarified here:
a) The "Classic" PLC 5 ran on an interpreter (ex. 5/15, 5/25) b) The "New Platform" PLC5 is compiled (ex. 5/20, 5/40, 5/60, 5/80)
c) The SoftLogix 5 is compiled
d) All of the above support Online Runtime Editing using the same programming software package
e) All of the above are designed to detect and report application parameter errors prior to, and without, passing them to the OS. This prevents critical errors from occurring, and provides the diagnostics that our users need to create stable application code.

>"So with softPLC, I can't get the blue screen of death?"<

I'd like to answer this question for the SoftLogix 5, using an excerpt from the Q&A document on our http://www.OpenAutomation.com website. There has been significant marketing hype occurring on the BSOD issue. Please see our Whitepaper in this area for more detail on this subject.
Q: Does your technology provide the ability to run after a kernel exception (Blue Screen of Death) in NT?
A: Absolutely not, we believe that this in an inherently unsafe thing to do. It is equivalent to a PLC 5 "red light". The reasoning behind this is that it is not possible to determine whether or not the kernel exception resulted in the corruption of data in the I/O control and status area of memory. If corruption occurred in this area, I/O cards used in the soft control program could also become corrupt. It is simply not possible to protect this area of memory using today's PC hardware. Anyone who claims otherwise is either uninformed, or allows for a level of integrity that is considerably less than what we believe is required for control.
Dave Lillie
SoftLogix Extensions Program Manager
Rockwell Software Inc.
http://www.SoftAutomation.com/SLX

(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.

By George Robertson on 15 November, 1999 - 11:04 am

(Originally posted Fri 09/04/1998)
I repeat, with Steeplechase, I can't get the blue screen of death?
ggrobertson@mindspring.com
George Robertson
Saulsbury Industries

(Originally posted Tue 09/08/1998)
This is a different question than you first asked.
There is a big difference between errors that occur in the Windows NT world (and can cause a blue screen of death) and runtime errors that occur in the real-time world (as a result of mistakes in my programming).
Steeplechase keeps these two worlds separate. If a blue screen of death happens in NT, the runtime is not affected by it. In fact, the runtime can notice the event and take corrective action.

I have written NT Kernal Mode drivers. In one hour, I can write a program that will cause a blue screen. If I try not to cause blue screens, it takes longer for one to happen. With careful design and thorough testing, I can (and have) create a driver that probably won't blue screen.
The great blessing of PC based control is that I can use things written by people who have never heard of Steeplechase to make my machine better. If one of those folks writes a driver that causes the blue screen of death, Steeplechase protects the runtime (and my machine, my production, my operator, etc.).

(Originally posted Mon 09/07/1998)
You may also note that Octagon Systems, manufacturers of single board computers and Event Technologies, developers of GELLO, an object based programming control language, announced two weeks ago that GELLO would now be available imbedded on the Octagon product offerings! Now you can buy a single board computer, with or without built in I/O, with a ready-to-run control "operating system" no different than a PLC cpu. You design your "logic", download it through a serial port to the Octagon unit, connect up the I/O and/or terminals and go. Except the Octagon cpu, being a PC (sans any moving parts) has about 10x the flexibility as a brick style plc. Prices start under a $1000. Learn more about it at http://www.gello.com.

By Tony L. Smith on 28 April, 2004 - 5:45 pm

Hey Guys and Girls,

I have worked with Soft 5 since it was first introduced by Allen Bradley. With its NT operating system it was not dependable to say the least. I think Soft 5 was designed for PLC applications where there would be large amount of data involved. As you know Windows NT is no longer supported by Microsoft. When I talked with Allen Bradley they could not tell me how to make there computers using Soft 5 and A Win 2000 operating system work.

I have discovered a way to make there computers operate on Win 2000 and I do not have crash problems anymore. It is very dependable now.

By Manmeet, India on 18 July, 2006 - 2:43 pm

Hello,

This rivalry between PC based control and PLC is good.

Let me tell u that both the technologies have advantages. Yes the electronics have reached to the point that there is no difference of advantages or failure in the components of both technologies and are reliable. Yes, all electronics componenets suffer the failure reliablity fatigue (after running continuously, there are failure rates) and the components have to be changed. PLC components I/O cards are more expensive as compared to the PC cards They are expensive if the PC is Industrial PC. PLC is like program and forget and the monitoring by SCADA. PC based control is always connected to system all times but can be customised for SCADA.

As regards the operating systems, Yes NT has been discontinued but WIN 2000 is still fine. If someone asks the Blue screen problem, PLCs have the same problem like red LED that means program has stopped.

The distinct advantages are the price and economics. I give you my examples.

Our system Mantra by ControlSoft Inc. (US based company--a Pioneer in Loop tuning technolgies and OEM vendor of these technolgies to many top brads in automation) is available both in Hardware and Soft form (PC based). both offer connectivity to OPC, DDE or drivers. But we found that customers are more worried about the Hardware rather than the technolgies being offered. In this hardware form we are offering unlimited loops and FBD while in PC based control we are offering no of Loops and FBD usage based. We never had a problem in PC based control but we had in hardware. The prices are also the matter. Rather than the harware modules cost, there is loop cost and FBD usage.

Then the PLC is programmed by its own software rather than by third party vendor But PC based control can be programmed with interfacing with SCADA/C++ etc.

It all depends upon customer choice. he will prefer that in which he has less hasels.

Manmeet

By Marc Sinclair on 3 November, 1999 - 12:01 pm

(Originally posted Wed 08/26/1998)
I seem to remember that we went through this some time ago but, You ask
"What could we do that would change your mind ?"

Well,
Put the PC in a small DIN rail mountable enclosure, (10cm *10cm *25cm would do)with cage clamp connectors for all IO.
Include io onboard, maybe 24 in and 16 out and two built in RS232 / 485/ PTP, PROFIBUS ports and allow me to add on (or replace) more IO easily with no tools.
Make available a range of analogue IO at reasonable cost.
Make it easy to program and supply the programming software for free which
allows me and the customer to view and modify the program.
Make it so that I can protect the software if needed and update via small
EEPROM modules for less than £25
Make sure that the unit is available worldwide within a day so that any
breakdown or damage can be rectified quickly
Make available a range of HMI units from a simple 2 line LCD and function keys through to full colour screens with no extra programming software required.
An ASI master card / Module for less than £175 Worldwide technical assistance.
Make it cost less than £400
I get all this already (and more!!) from a plc so you'd have to do better than this!

By Mike Esposito on 3 November, 1999 - 12:12 pm

(Originally posted Thu, 27 Aug 1998)
...get your head out of the sand...
-what u described would be fine for a coke machine or car wash
-but more than 2 axes of servo motion and a real hmi (recipes... communicate w/ IS systems)
-your cute little shoe box won't come close
-don't take me wrong...i love plc's...however u overstate your case

1. the software is never free...in fact quite the opposite... constantly needing to upgrade $$$ as new generation plc's and processors come out..., and portability of the software does not exist-koyo to AB and Siemens...software costs $$$
-also i've never seen any ab slc500 shareware??

2. plc hmi (anything over 2 line display) also requires some separate ($$$) software
-another unique programming language which is tied to that model hardware
-just had terrible experience w/ Siemens interfaces and which rev. of software i was using
-even worse were the compatibility problems w/ my Siemens eeprom programmer
-it liked one cpu but not the hmi ???
-changed its firmware...it liked the hmi but not .... u guessed it ...the cpu

3. by the way...pc's are avail in rack mount...various types std, din rail box, vme....many others

Again i'm not saying PC's are better than PLC's just different....
-also PLC's CAN"T do motion and they do a s*cky job w/ HMI
-however they are GRRRReat w/ I/O and ease of use, durability is super.

By Darwin Frerking on 3 November, 1999 - 4:56 pm

(Originally posted Fri, 28 Aug 1998)
Mike,
Marc is talking about his concept of a PC-based system that would meet his needs; not about PLCs. He is pretty close.
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. The high end would be Pentium based with 64/128 MB of memory. Then get MEI to develop DSP-based motion modules for the same PLC. And offer it all at reasonable prices: $300-800 for the CPUs and $200-300 per motion axis.
They would have a winner and we would have the processing power and hardened I/O for the majority of our applications.

Regards,
Darwin Frerking, Control Engineering Manager
FAS Technologies - 10480 Markison Road - Dallas, TX 75238

By Kerry L. Schrank on 12 November, 1999 - 2:11 pm

(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

Kerry L. Schrank
Think & Do Software

By germaine_systems@EMAIL.MSN.COM on 4 November, 1999 - 3:27 pm


Points taken, but don't underestimate where 'cute little shoeboxes' have got and what they can do when they are programmed by programmers.
In my experience the majority of food production facilities consist of separate machines which communicate with an overall control system. I program these machines to do simple tasks, including servo motion and recipe selection / programming. They then send back data to the CAM system and will accept setup parameters and commands. PCs in this situation are too expensive and unreliable yet for me to consider, I have used industrial PCs programmed using C++ very succesfully, on oil production platforms, for data collection and overall control but found lots of limitations in speed and hardware especially concerning interrupt availability. Don't get me wrong I love PC's I would never use a PLC for a database program or complex interface but don't ignore the fact that PLCs are still evolving.

By Robert Phillips on 3 November, 1999 - 12:02 pm

(Originally posted Wed 08/26/1998)
My preference is PLC due to fact that they are designed and tested to hold up under 24 hour operation. As far as components go, the brand I recommend used plug in relays for outputs. These relays have a mechanical life of over 50,000,000 operations.
For the most part, you cannot get detailed specs on the pc components.

Robert Phillips
City of Wichita Falls, Tx

By Davis Gentry on 3 November, 1999 - 12:03 pm

(Originally posted Wed 08/26/1998)
>As long the real-time processing is more important
than the information processing, the PLC is in favor.<

While I agree with some of the points made in this email, the one above is open for debate. Many highly demanding real-time processes cannot be run on PLCs due to their slow speeds and limited programming languages. High speed complex machine vision processing, precision motion control, complex machine control (semiconductor manufacturing is one I've had experience with), etc are examples. In some instances there can be PLCs or PLC like devices (GE FANUC CNC controllers for example) which can do some or all of the tasks, often a computer (PC or other - some VME/VXI based minis have some PLC like characteristics)can do the job better, faster, and cheaper.

Davis Gentry
Controls Engineer
Research and Development
Carpenter Company

By Johnson Lukose on 10 November, 1999 - 5:57 pm

(Originally posted Wed 09/02/1998)
Please remember that the PLC began as a "programmable relay system". All the stuff you are refering was built-on analog computers then migrated to mini-computers.
Of course the microprocessor revolution has changed the face of it all. Today TMR wants to do DCS, DCS wants to do PLC, PLC wants to do DCS... it's a jungle out there!
thanks.

By Darwin Frerking on 3 November, 1999 - 12:04 pm

(Originally posted Wed, 26 Aug 1998)
I've been implementing PC-based and PLC-based solutions for 15 years now. There's a place for both.
I've used PC-based, programmed in BASIC, Pascal, C, or VB for applications that required complex motion control, calculations, communications, and also a graphical user interface.
I have used PLCs in simpler stand-alone applications and also as I/O for PC-based systems. It is hard to beat the integrated control and I/O of a PLC.
If the PLC manufacturers would offer general purpose PC-based CPUs and intelligent motion control modules in their micro-PLCs, they would have a real winner.
You don't need to change my mind; only offer PC-based CPU and I/O hardware packages for the price of a micro-PLC, i.e. 300-500 dollars.

Regards,
Darwin Frerking, Control Engineering Manager
FAS Technologies - 10480 Markison Road - Dallas, TX 75238

By David Lawton Mars on 3 November, 1999 - 12:04 pm

(Originally posted Wed, 26 Aug 1998)
A quick response to Hermann's note:
<< The technical maintenance personel is more familiar with the PLC; this
counts as well for programming as for hardware problems. >>
I don't buy this train of thought ! If there are true benefits to be had from technology, industry will buy it (eventually!). Fieldbus is a good example of this !
<< Reliability: a PLC that runs doesn't crash, you can't guarantee this
with a PC >>
You've just about hit the nail on the head ! In many industries (FMCG included, which is where I work), downtime means serious money. Robustness is a KEY consideration when choosing a platform to control the "real plant". Okay, PC based SCADA etc for data collection, SPC etc etc., but actually running the plant? I think this is still some way off.

(Originally posted Wed, 26 Aug 1998)
Please allow me to add a couple items to those already mentioned in previous replies to your request:

(1) We need a migration path. We have a HUGE installed base of PLC's. Let us say that we accept that PC control is the wave of the future. Just exactly how do we get from where we are today to PC based control? Specifically, what are the steps to be taken for a GLOBAL corporation to make this migration?

Want to know what PC control vendors come in and tell us? They say: "Give us a machine to do a prototype on." Man! That is not a migration path! We don't just go throwing any old solution on even ONE of our machines.
Want to know the other thing vendors do? They come in and show us all kinds of neat new technology. Again, this is great stuff, but what is the migration path?
Also, what's the migration path for our maintenance people? We have a HUGE investment in PLC training for our maintenance folks. What is to become of that?
Vendors need to work closely with global corporations to develop realistic long range migration plans and systems if they expect to see corporations make such a migration.

(2) Programming standards are an issue. Basically, from what I've seen, the SFC's generated by PC based software are used to generate ladder diagrams that implement the logic of the SFC. The problem which arises is that the ladder logic so generated does not conform to our company's current (worldwide) ladder programming standards. How can we make it conform?

For example, let's say that we use (in A-B PLC's) B3 bits for our "fault summary bits". How can we ensure that, if we draw an SFC with your software, the ladder generated from the SFC will use the same B3 bits for fault summaries that we would use? Or, to say it another way, how can we ensure this without effectively writing a ladder program ourselves. If what it boils down to is more work for the programmer to implement a certain format of ladder diagram through PC based control than it would take to implement the same ladder directly in the PLC, then PC based control won't go anywhere soon.

(3) All this being said, I do think that PC based control has its place.
The big selling point of it, in my mind, is memory. We are tapping the limits of what can be done with even the largest PLC's. This is where PC based solutions seem to make the most sense. Give us a migration path and we'll use PC based control in such applications.

By Randall Reed on 3 November, 1999 - 12:06 pm

(Originally posted Wed, 26 Aug 1998)
The last "real" reason i heard for plc was from an omron rep. he was very happy that day as a customer just cut a 50k order for plc. the reason was 100k of mechanical damage to a pharamaceutical line. (pc based).

By Badaruzzaman on 3 November, 1999 - 12:07 pm

(Originally posted Wed, 26 Aug 1998)
PLC is the replacement of the relay controller.It's memory is low compared to PC.It does not has hard disk which can content a lot of memory.It does not support data acquisition,dos and windows.The PLC software is downloaded to the ROM in the PLC.The PLC software is depend on the manufacturer like OMRON, AB,Siemen and others.Now there is the company try to promote PLC Open which not depend on the particular brand.PLC is widely used in the automation industry.Now Siemen try to promote micro PLC which the price is very low.
Thank
Badaruzzaman
MARDI Malaysia

(Originally posted Thu 08/27/1998)
What about price? In my system design, price is a major factor and then the amount of I/O.

By Timothy P. Gabrys on 3 November, 1999 - 12:17 pm

(Originally posted Fri 08/28/1998)
Price can vary between PLC's systems as well as PC based. Some of the Micro or brick PLC's are inexpensive ($150.00-$300.00). Larger PLC systems can run as high as $8000.00 for the processor alone. Price can vary based on I/O requirements as well as processing capabilities. You typically have to use the micro PLC manufacturers proprietary software to program these systems.
PC hardware can also be inexpensive especially if you look at some of the embedded microprocessors on the market. These systems typically have no moving parts (flash disk and RAM) and have shock and temperature specifications far superior to the traditional PLC. These embedded PC's are used in the transportation (on the vehicle) as well as gas and pipeline industries where shock and temperature swings can be severe. Prices of these microprocessors can range from ($300.00 - $1000.00). DOS is used as an operating system in a majority of these type applications. We have customers that still use 386 processors for their applications because of the low cost. The interesting point here is that in some cases the 386 processors out perform their PLC counterparts in program execution speed. Using embedded processors also open up your options when choosing software. Their are packages available out there that are operating system independent and offer you the choice of programming language. These packages come in many flavors (Object Oriented, IEC1131.....).
For more info on embedded PC's check out (http://www.octa.com)
or contact RTA at (414) 453-5100

By davis_gentry@YAHOO.COM on 4 November, 1999 - 3:32 pm

(Originally posted Mon 08/31/1998)
This is all true. One other thing to mention is HMI. If you need a graphical HMI you will almost certainly use a computer. If so, and you are already spending the $$$ to purchase one why not have it do the control. I've had good luck with that. And few of the really advanced applications use PLCs for control - not flexible enough.
Davis Gentry
Controls Project Engineer
Research and Development
Carpenter Company

By robert@CITRINE.CYBERSTATION.NET on 4 November, 1999 - 5:13 pm

(Originally posted Mon, 31 Aug 1998)
I agree 100%. My order is: reliability, overall ability,,,,,,,,,,,,,,,,,,cost.
It makes no sense to have the lowest initial cost if you also have the highest downtime.
Robert Phillips
City of Wichita Falls, Tx

(Originally posted Thu, 27 Aug 1998)
Industrial PLC's are far more robust in their processor operation and are not prone to the need to reboot as PC based controllers are. They are also usually installed in a control system, for the most part, as the sole control for that system with a PC acting only as the HMI interface with that system. This allows the user to run other applications on the PC without the fear of losing control of the system in the event of a PC failure or an application failure. Each control system application has it's pros and cons as to whether it should be operated with a PLC control or PC based control. Personally, if I am only performing data acquisition functions on a non critical system, then PC based control is acceptable. If I am performing building control for a critical computer room support application I would prefer the PLC controller.

By Steve Preslin on 3 November, 1999 - 12:13 pm

(Originally posted Thu, 27 Aug 1998)
The PC may be the way for a small company with a DIY engineer. I can't imagine running an Electrogalvanizing line on PC based stuff. If your PC takes a dump or starts having mysterious problems, who you gonna call? AB and others have years of experience and generally can get you through a problem with a phone call. Parts are also easy to come by.
Thanks, I'll stick to PLCs
Try to tell a production manager how much money you saved by using "Joe Blows Turbo PC" for your control when its down and you can't get parts or tech support.
Steve Preslin
Metro Metals

By Frank Powell on 3 November, 1999 - 12:14 pm

(Originally posted Thu, 27 Aug 1998)
I use PLCs because they are being used in a mobile application and are under extreme vibration and shock conditions. I didn't want to deal with hard drives and all of the connections in a PC. (I could have used flash RAM) I already had somewhat limited experience in ladder logic and none what so ever with C or C++.
I also had a requirement of using 12VDC power for the system which was quite limiting.
I will be interested in seeing Real Time Windows CE (flame shields UP!!) and all of its possibilities. Especially since it has built in flash ram, VGA for displays, and communications (serial and email).
Frank Powell
Mechanical Engineer
California Pavement Maintenance
9390 Elder Creek Road
Sacramento, CA 95829

By AllanJH@AOL.COM on 4 November, 1999 - 3:26 pm

(Originally posted Fri 08/28/1998)
I think PC based control has it's place, but one reason I have seen to use PLC's still is on a job with a small I/O count you just cannot beat the price of a micro plc. I have been through several PLC to PC based jobs. Once the "white box' is purchased, especially if it's industrial grade the price is already over the PLC & operator interface costs. Just my 2 cents.
Allan Hopkins
J.E. Grote Co.

By twright1@ptdprolog.net on 4 November, 1999 - 3:29 pm

(Originally posted Mon 08/31/1998)
Don, it isn't what you can do to change my mind. It's what you can do to change the minds of other people in my company. The number one reason that I was given NOT to apply PC's was "support concern". The company I work for has plants across the country, with various levels of technical expertise. Individuals in charge state they are unwillingly to accept PC's in these other facilities due to lack of familiarity and support. Other reasons include (in their words):
-Not as reliable
-Floor maintenance can't work on them
-No real cost benefit

For me personally, I know that you are already working on, or already have some of the "PLC" things:
-Smaller form factor hardware, (the size of a PC card or micro PLC)
-IEC1131-3 languages
-Total motion integration, for instance, programming a motion routine in the ASAP environment for execution in a motion card
-Drive the price down as far as possible, (of course)
-Other target OS's

Right now, I would use PC control for applications requiring a graphical HMI. For applications requiring a text based, or no HMI I still prefer to use a micro PLC. I believe you will have to stay ahead of the features offered in today's micro PLC, for example Mitsubishi Fxxx series and others. Also, I would attack the reliability issue. I have been able to find MTBF numbers on motherboards, hard drives, displays, and PLCs. Some time ago I even posted the results of a quick web search which provided the following, Quantum cpu MTBF around 200,000-300,000 hours vs. Seagate hard drive 1,000,000 hours (if I remember correctly).
Of course, XYCOM should be able to help with some of these issues.
This is a very interesting thread, as it was in the past. I have some other comments. For those mentioning a migration path, please note that you may be able to utilize the same IO and logic that has already been deployed. You just have to use the appropriate scanner card and do some extra typing. Also, as was already posted, please remember that there are other platforms that can be utilized such as VME, STD, Compact PCI, and embedded controllers. One of the benefits of "soft control" is flexibility.
Thank you, Todd

By Edmund_L_Mulligan@ARMSTRONG.COM on 4 November, 1999 - 3:36 pm

(Originally posted Mon 08/31/1998)
I agree that a PC with good I/O and a real-time operating system is very nice.
I'd really like to set up an application using a system like that. Unfortunately, no matter how good the system is most people won't make the change until the technology they use every day will no longer do what they need. It is not a matter of making the PC based control system better, it is PLCs reaching the point where they won't do the job. With the advances in PLCs, that is a long way off. Otherwise, the switch would require good technical reasons for the PC based system, and the total cost of hardware, software, spare parts, and complete training for engineers, technicians, and operators would all need to be (combined) cheaper than a PLC system. Don't forget that there would be no training and little spare parts costs for the PLC solution if that's what the plant already uses. The PC based system might be easier to diagnose, but unless it is quicker than the usual card replacing that happens with a familiar PLC based system there is no gain for servicing. Don't forget the double spare parts stocks needed, because they certainly won't be able to rip out all the working PLCs so they will need to keep parts for both systems on the shelves. I'm told that the more parts in stores, the worse it is for the $$$ side of the business.
Projects aren't so much picked for technology reasons as they are for cost/benefit calculations. If it doesn't pay back right away, it doesn't get funded.
I see more of a gradual convergence in development, not a switch from PLCs to PCs in control systems.

Ed
Speaking for me, not for Armstrong!

By brannon@QUEUESYS.COM on 5 November, 1999 - 3:12 pm

(Originally posted Tue 09/01/1998)
I am always amazed at people trying to sell higher and higher tech solutions for non-existent problems. --- Just what is the problem being addressed here. --- Lack of Sales? --- If there is a real need for more than a PLC, then use whatever is required. --- However; make sure that what you use is designed to be out on the plant floor or put it in the control room where it belongs.
Plcs are so popular because they work. --- No Blue Screens, no reliability issues, they just work. --- They always work. --- A slight overstatement, maybe, but not by much everything has a few implementation bugs, but after that it should just run and run and run.
The second reason PLCs are so popular is that they are easy to understand. --- They were designed to replace relay panels and now have developed much more capability. --- Any Maintenance electrician can take a ladder diagram in one hand, look into the mass of red wires of a control cabinet and determine what is making his machine malfunction. --- If any changes are needed to the program, he doesn't need hours of moving hundreds of red wires, resetting timers, or complex programming languages, he just needs to know how his motor starters (or other outputs) and limit switches (or other sensors) work and apply the standard symbols for them, that he already knows. --- Even his Gets and Puts of values from and to advanced SCADA systems look like common inputs and outputs.--- His program looks like the machine he's trying to fix.
The first PLC that I actually sold was installed in the US Postal Service. --- It was installed in a relatively Clean (as plant floors go), Air Conditioned Bulk Mail Center (still hot and humid as hell compared to the office where my pc resides).
My demo was "installed" without a control cabinet, sitting on top of a Motor Control Center, out on the plant floor, with the bundle of wires and cables "hanging in the air" through an open door where it ran flawlessly for 2-weeks attached to the terminal blocks of the new disconnected "Black Box" it would eventually replace. --- Not the ideal installation even for a PLC. --- As I recall, Safety issues were handled by limiting access to the immediate area as this was only a test.
PLCs are designed to survive in real world control situations. --- Have you ever seen what the high heat and humidity of a manufacturing facility will do to your pc? --- How about the dirt and grime getting into the floppy, CD ROM, or hard drives? --- How about what the noise/RFI from a motor starter's coil or contacts will do to for the reliability of these marvelous pc based control systems?
Try an arc welder being used in the general vicinity. --- When I went back to the U.S.P.S.-BMC, a couple of days later, I was dumbfounded as I watched my A/B-PLC demo function perfectly with a guy welding in the next bay over, yes I had a top of the line Sola Basic Constant Voltage power conditioner in front of the PLC, but it still wasn't even in a control cabinet. --- We wouldn't have suggested it, but I still saw it.
Keep that pc in a VERY Clean, VERY air conditioned office and use it for the office work or Non-critical HMI-GUI interfaces it was designed for. ---
Keep it off the plant floor unless it was designed to be there.
Ok, I'm ready, go ahead with the flames.
LB.

By armin@steinhoff.de on 10 November, 1999 - 5:14 pm

(Originally posted Wed 09/02/1998)
At 11:24 01.09.98 -0400, Lee Brannon wrote:
>I am always amazed at people trying to sell higher and higher tech solutions for non-existent problems. --- Just what is the problem being addressed here. --- Lack of Sales? --- If there is a real need for more than a PLC, then use whatever is required. --- However; make sure that what you use is designed to be out on the plant floor or put it in the control room where it belongs.
> Plcs are so popular because they work. --- No Blue Screens, no reliability issues, they just work. --- They always work. --- <

... until they crash because of software or hardware problems.

>A slight overstatement, maybe, but not by much everything has a few implementation bugs, but after that it should just run and run and run.

> The second reason PLCs are so popular is that they are easy to understand. --- They were designed to replace relay panels and now have developed much more capability. --- Any Maintenance electrician can take a ladder diagram in one hand, look into the mass of red wires of a control cabinet and determine what is making his machine malfunction. <

What a wonderful picture ... but I would take the red wires in one hand and look then to the ladder diagram :-))
What is different if there is 'PC based hardware' between the red wires and the ladder diagram ???

>--- If any changes are needed to the program, he doesn't need hours of moving hundreds of red wires, resetting timers, or complex programming languages, he just needs to know how his motor starters (or other outputs) and limit switches (or other sensors) work and apply the standard symbols for them, that he already knows. --- Even his Gets and Puts of values from and to advanced SCADA systems look like common inputs and outputs.--- His program looks like the machine he's trying to fix.<

I would not trust a machine which looks like thousends of ladder logic lines 8-)

> The first PLC that I actually sold was installed in the US Postal Service. --- It was installed in a relatively Clean (as plant floors go), Air Conditioned Bulk Mail Center (still hot and humid as hell compared to the office where my pc resides).<

AFAIK ... most of the sorting machines of the US Postal Service don't use PLCs. They are managed by QNX systems.

> My demo was "installed" without a control cabinet, sitting on top of a Motor Control Center, out on the plant floor, with the bundle of wires and cables "hanging in the air" through an open door where it ran flawlessly for 2-weeks attached to the terminal blocks of the new disconnected "Black Box" it would eventually replace. --- Not the ideal installation even for a PLC. --- As I recall, Safety issues were handled by limiting access to the immediate area as this was only a test.

> PLCs are designed to survive in real world control situations. <

Industrial PCs too ...

>--- Have you ever seen what the high heat and humidity of a manufacturing facility will do to your pc? <

I saw a lot of PLCs dieing by high heat and high humidity ...

>--- How about the dirt and grime getting into the floppy, CD ROM, or hard drives? <

Nothing happens if a fan is pressing filtered air into the IPC case ...

>--- How about what the noise/RFI from a motor starter's coil or contacts will do to for the reliability of these marvelous pc based control systems?<

If the IPC has a marvelous professional power supply ... nothing happens.
Regards
Armin Steinhoff

> (Originally posted Wed 09/02/1998)
At 11:24 01.09.98 -0400, Lee Brannon wrote:
>I am always amazed at people trying to sell higher and higher tech solutions for non-existent problems. --- Just what is the problem being addressed here. --- Lack of Sales? --- If there is a real need for more than a PLC, then use whatever is required. --- However; make sure that what you use is designed to be out on the plant floor or put it in the control room where it belongs.
> Plcs are so popular because they work. --- No Blue Screens, no reliability issues, they just work. --- They always work. --- <

... until they crash because of software or hardware problems.

>A slight overstatement, maybe, but not by much everything has a few implementation bugs, but after that it should just run and run and run.

> The second reason PLCs are so popular is that they are easy to understand. --- They were designed to replace relay panels and now have developed much more capability. --- Any Maintenance electrician can take a ladder diagram in one hand, look into the mass of red wires of a control cabinet and determine what is making his machine malfunction. <

What a wonderful picture ... but I would take the red wires in one hand and look then to the ladder diagram :-))
What is different if there is 'PC based hardware' between the red wires and the ladder diagram ???

>--- If any changes are needed to the program, he doesn't need hours of moving hundreds of red wires, resetting timers, or complex programming languages, he just needs to know how his motor starters (or other outputs) and limit switches (or other sensors) work and apply the standard symbols for them, that he already knows. --- Even his Gets and Puts of values from and to advanced SCADA systems look like common inputs and outputs.--- His program looks like the machine he's trying to fix.<

I would not trust a machine which looks like thousends of ladder logic lines 8-)

> The first PLC that I actually sold was installed in the US Postal Service. --- It was installed in a relatively Clean (as plant floors go), Air Conditioned Bulk Mail Center (still hot and humid as hell compared to the office where my pc resides).<

AFAIK ... most of the sorting machines of the US Postal Service don't use PLCs. They are managed by QNX systems.

> My demo was "installed" without a control cabinet, sitting on top of a Motor Control Center, out on the plant floor, with the bundle of wires and cables "hanging in the air" through an open door where it ran flawlessly for 2-weeks attached to the terminal blocks of the new disconnected "Black Box" it would eventually replace. --- Not the ideal installation even for a PLC. --- As I recall, Safety issues were handled by limiting access to the immediate area as this was only a test.

> PLCs are designed to survive in real world control situations. <

Industrial PCs too ...

>--- Have you ever seen what the high heat and humidity of a manufacturing facility will do to your pc? <

I saw a lot of PLCs dieing by high heat and high humidity ...

>--- How about the dirt and grime getting into the floppy, CD ROM, or hard drives? <

Nothing happens if a fan is pressing filtered air into the IPC case ...

>--- How about what the noise/RFI from a motor starter's coil or contacts will do to for the reliability of these marvelous pc based control systems?<

If the IPC has a marvelous professional power supply ... nothing happens.
Regards
Armin Steinhoff

By PETERSONRA@aol.com on 10 November, 1999 - 5:16 pm

(Originally posted Wed, 2 Sep 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.
Personally, I'd like to hear from some very experienced USERS of PLCs (not sellers of PCs or s/w for PCs) who have made the switch to PCs for control and get their input.
No offense to anyone.

By Steve Cliff on 10 November, 1999 - 5:50 pm

(Originally posted Wed, 2 Sep 1998)
Yes, it has been fun...
Or maybe the two camps are those who HAVE used PCs and those who HAVE NOT used them.
Some trust their successes; the others fear the unknown?
steve

By Ken Woodard on 12 November, 1999 - 2:16 pm

(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.

(Originally posted Wed, 2 Sep 1998)
I have done PLC systems for a number of years. I have had plus and minus experiences with a variety of them. I have experienced reliability problems with AB plc's. 2's,3's,5's. I have most of my reliability problems fixed with Eprom upgrades not the old standard check the grounding answer AB. Cannot say i was overly impressed with support of so called robustness. I have done control on literall thousands of I/O points and several hundred PLC systems. I have alos done DCS systems. Once past start up and E-prom upgrades they have run reliably.
We just finished 2 PC systems both based on Taylor Waltz. One is a pharmaceutical plant and one is a machine control. The pharmaceutical plant has been running for about 11 months now. The machine contrtol has been running for 6 months. I thought the programming was very easy(it is all ladder logic. The troubleshooting is very good. Much easier than any PLC I have ever used. In the plant we have the system networked witht he plant information system which was done with a $65 3Com card. Plant system however does crash about once a week. We feel it is an NT problem. NT is quite sensitive to the hardware it runs on. We are changing to a different NT box. In the pharmaceutical plant the crashes have not caused a problem because it is all batch processes. The whole process restarts in under 2 minutes. The operators are quite happy with it and have learned to cope with the crashes.
For my input the PC is okay for discrete processes or batch processes. I do not feel it is mature enough for continuous processes yet. That is some input from someone whom has done a PC and lots of PLC systems.
Owen Day
Engineer
Optimal Control Systems

By Davis Gentry on 10 November, 1999 - 5:52 pm

(Originally posted Wed, 2 Sep 1998)
I would not classify myself as 'very' experienced with PLCs, but I have deployed (spec'd, programmed, set up, debugged, and maintained) PLC-5, SLC 5/xx, and one S5/90U installations. These were in industrial environments, not lab stuff. I have also done the same with computer (PC - CISC, VME - RISC and CISC, other hardware, DOS, NT, HP-UX, Solaris, and other) based installations, and now work almost exclusively with PC systems. I am not selling these - they are exclusively for use within my company's 30+ plants. I will spec a PLC if it seems to be the best solution - and occasionally do for simple applications where no complex HMI is required and where no information is passed to our business systems.
My experience is that this question is largely decided on what the engineer is comfortable with. I am 32, and am capable with PLCs, but more comfortable with computers so that is what I choose. Twenty years from now I'll have some young engineer coming up who has some new technology for control (nano-computing?) and I will argue that it is unproven and just not as capable as that with which I have experience. One of the guys with whom I had some major disagreements on this subject brought PLCs into his company over the strident objections of those who insisted that they could never replace relay banks. But that was almost twenty years ago, and he wasn't thrilled about replacing them even in applications where a computer was demonstrably superior.
Basically it is my opinion that right now many applications can be solved by either method, and there will be both advantages and disadvantages with whichever solution you choose. The thing to avoid is a religious attachment to any technology which prevents you from seeing both its good points as well as its bad points. Hopefully, twenty years from now I'll be able, however grudgingly, to admit that there may be situations in which that new technology is useful.
btw - for those of you who think that because I work for an R&D organization everything I do is blue sky with little practical application - everything we do goes directly to our plants in large quantities - and I'm responsible for supporting this stuff - so if the electrician can't troubleshoot a problem I'm the one who gets the call. Or if my computer is blowing hard drives on a monthly basis.
Davis Gentry
Controls Project Engineer
Research and Development
Carpenter Company

By Michael Griffin on 10 November, 1999 - 5:59 pm

(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
mgriffin@wwdc.com

PC based control system is also called SCADA: Supervisory Control & Data Aquisition System. It can be considered next generation control system for coming sixty years. PC life cycle for replacement can be extended to 8 years with
spare PC. It can be great Integrated Process Control with data record on CD-ROM for long time. PC based control system can be designed for longer life cycle up to 10 years for PC & wireless hardwares.

(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
R.S.A.

By Johnson Lukose on 11 November, 1999 - 3:33 pm

(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!

By Hugo Ahrens on 10 November, 1999 - 5:55 pm

(Originally posted Wed 09/02/1998)
I was going to send the following reply to add to the ongoing discussion:
Why might PC control not be as successful as PLC control? I would like to take this to a personal level. My experience is with $10k to $200k control systems in material handling, manufacturing, food processing and pipe line applications.
Issue #1. Reliability
PLC = Some of my applications have run 15 years+ without any attention. In 20 years of working with PLC' s (on about 300 PLC systems) I've diagnosed one CPU failure. It took 20 minutes, 10 minutes to get and replace the CPU. PC = No PC application I've had something to do with (or I've been close to) has run without hiccup for more than two years.
Issue #2. Cost
Comparing apples to apples we must at least use the same quality I/O system.
PLC = Let's call this the base cost (it was there first), consisting of decent hardware, say A-B PLC-5 & I/O. Available range for a PLC-5 CPU is about $2200 to over $10k.
PC = Using the PC as the controller we get to throw out the PLC CPU. But instead we must buy a rack adapter so the PC has something to talk to on the I/O rack (about $1400). Next we need a PC of some sort, even the cheapest will be $1500 (these cost are in Canadian dollars, divide by 10 for approximate US$ or was it 1.5?). Then we must buy a PC module to act as a scanner, so the PC can talk to the I/O (about $1600). The scanner module comes with software that must be installed and made to work. Now we get to install the software PLC application (about $1500 to $3500). At this point we spent somewhere around $6500 and we now need to purchase new software to program our softPLC (we already got the software for PLC programming), that's another $1500 to $2500.
With these costs I can go to a pretty high end PLC CPU....
Issue #3. Environmental
PLC = Just look at the construction. I've seen a PLC mounted on the back of a safety barrier constructed of railway ties. This barrier was struck every 5 minutes or so (by accident) by a 1 ton log. When I saw this installation it had been operating without problem for two years. PC = Just look at the construction. The moment you offer me rack based PC's (constructed like a PLC) the cost for the CPU more than doubles and the rest of the stuff is priced just like PLC modules.
Issue #4. Maintenance/Repair
PLC = Front mounted everything, plug in - plug out. Lots of LED's. Selftest at startup. Idiot lights.
PC = ? Try to get a 10 to 20 year veteran tradesman to change the CPU or memory. Have a look into an electricians tool pouch and see what kind of tools he works with.
Issue #5. Troubleshooting
PLC = In a one week training course I can take a competent electrician from PLC novice to competent PLC troubleshooter (done it hundreds of times).
PC = I've been working on PC's (and on micros) for 25 years. With formal college graduation in industrial electronics, various training in micros and computing science I still would not call myself a competent PC troubleshooter. And the recent computing science grads I have hired do no better. Hit and miss, suspecting a driver here, an overwritten update there and the odd flaky chip, and a millon files and DLL's, it's trail and error - and the hours mount to levels no client will pay. So what does it take?
By now you might not believe me, I'd love to use a PC for control (for the obvious reasons not mentioned here). So that's why I did not want to send the above, to see some eager PC fanatic sentence by sentence pick my arguments apart and try to embarrass me. If you are still reading this you must be either a vendor desperate for client feedback (is it month end and the token report on user feedback to headoffice is due?), or you are in need of something better to do with your time. In case you are a vendor or have some other interest in promoting the PC for control, here is a challenge (rather than do the negative and pick apart my message, do all of us a favor and do the positive thing, convince us with facts to use a PC the very next time): I have outlined three systems below. For these systems on a line by line basis define your solution with catalog numbers and pricing. Wait, don't go to work yet! These system definitions are subject to change. I will usually be on of the last to admit that I don't know everything, but here I want to say right away the specs I've written up below are from some typical projects I was involved with this year (I tried to pick a small, a medium and a larger project). If you feel strongly that something should be changed in the specs let me (us) know. So I suggest, for the next two weeks we should be open to suggestions to alter the three system definitions.
After that time we will give a set -go signal to have the vendor offer their solutions (not fair to have a moving target). Any takers?
System 1:
14 outputs, 4 120VAC, 10 24VDC.
26 inputs, 6 120VAC, 20 24VDC.
2 Axis incremental encoder feedback,
with servo control for each axis -10V to +10VDC.
Operator display, provide RS-232 signal line only to support 4 lines of 20
char. ASCII
text to be updated at better than 500ms.
Speed requirement 10ms update maximum.
Physical construction: The control system is to fit into a wall mount sealed cabinet in a typical machine shop, with no external ventilation. All devices are within 20 cable feet of the enclosure. An operator pendant station containing 16 of the 24VDC inputs, one 24VDC pilot light and the 4 line operators display is mounted 20 cable feet from the control enclosure.
System 2:
220 inputs 120VAC.
60 outputs 120VAC.
6 Analog inputs 4-20mA.
1 Axis incremental encoder.
6 Axis Temposonic
with servo control for each axis -10 to +10VDC, 28 inch/s control to 0.001".
Speed requirement 20ms update maximum.
External communications network existing, Data Highway+, must offer a data file of 200 items for external monitoring (by an outside processor). Operators display with 4 display pages (machine overview, axis diagnostics, production reporting, annunciator)
Physical construction: The control system is to fit into a floor mount sealed cabinet in a dusty sawmill production floor setting, with no external ventilation and continual moderate vibration. All devices are within 80 cable feet of the enclosure. An operator control station containing 34 of the inputs, 12 outputs and the operators display is mounted 30 cable feet from the control enclosure.
System 3:
600 Input
400 Output
10 Analog inputs 4-20mA.
4 Analog outputs 4-20mA.
Modbus communication to protective relays (Multilin 269+).
Data Highway+ communication to VFD's.
A secure modem tie in is required for long distance phone based troubleshooting of equipment.
Speed requirement 25ms update maximum.
Physical construction: The control system is to fit into a floor mount sealed cabinet in a (possibly hot to 40deg.C) electrical control room setting, with no external ventilation. All devices are within 300 cable feet of the enclosure.
An operator control station consisting of a PC with MMI software is to be desk based 80 cable feet from the control enclosure. The client staff is not exited about having the MMI software run on the same computer as the control system. It seems they do not trust their maintenance staff to be able to make the frequent display changes required on the MMI without affecting the softPLC. So they want a separate desktop PC for the MMI.
Like I mentioned above, if you think these typical systems are not including something that is important in your work, let's hear about it. Is this practical enough?
Hugo Ahrens, Project Manager
IAI Industrial Automation Inc.
http://www.plc-control.com

By Davis Gentry on 10 November, 1999 - 6:42 pm

(Originally posted Thu 09/03/1998)
---"H. Ahrens" <hahrens@DIRECT.CA> 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 Fri 09/04/1998)
Davis-
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

By Davis Gentry on 15 November, 1999 - 11:01 am

(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 Thu, 3 Sep 1998)
Hugo,

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.

(Originally posted Fri 09/04/1998)
Rod,

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?
Mitch
D. Mitchell Carr, Technical Manager - Strategic Marketing
Eurotherm Controls Inc

(Originally posted Fri 09/04/1998)
Mitch,

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.

By Steve Jaeckels on 15 November, 1999 - 11:44 am

(Originally posted Tue 09/08/1998)
I have seen a lot of comments regarding hard drives and their inability to withstand the rigors of the factory floor. I would like to point out that PC-Based control does not necessarily mean that the PC being used is a consumer model from the shelves of the local Best Buy or Circuit City.
PC-Based control can, and does, take place on a large variety of machines, including a vast array of diskless, single board PCs from companies like Octagon Systems (www.octa.com). These systems offer a multitude of storage and memory options, and have better temperature specs than any PLC (-40 to 70 C). They have been proven over-and-over again in rugged applications - without the problems caused by hard drives.
Eliminate the hard drive issue from your objection list to PC-based controls - it doesn't belong there.
As for the operating system, the user has a multitude of options. NT is certainly one choice, but the generally accepted assumption that NT is the only way to implement a PC-Based control system is absurd. Still, even with its large storage requirements, NT will soon be able to reside on these small, diskless embedded PCs (disk-on-a-chip is coming out in 160+Meg).
For those who aren't interested in NT, there are a good number of non-NT solutions for running PC-based controls. They range from DOS-based systems to real-time OSs like QNX.
Eliminate the blue screen issue from your objection list to PC-based controls - it doesn't belong there.

Steve G. Jaeckels
Manager - Applications/Product Support
Event Technologies, Inc.

(Originally posted Wed 09/30/1998)
WinCE will answer all of these questions.

Doug Smith

(Originally posted Thu 10/01/1998)
I hope the embedded controllers will be supplied with visible Reset button.

Zak Fuchek

(Originally posted Wed 09/30/1998)
Just by the way, you can purchase RAID (Redundant Array of Inexpensive Disks ) which will total mirror a hard drive and even allow you to swap a defective one out with the power on. These are very inexpensive starting at $200 raid Level 1 to $1000 Raid Level 5. I have not had a disk failure in years, the latest drives have Mfg. warranties of 5 Years with MTBF of 65000+ hours i.e. 8 years continuos..
Doug

By Brian Woodcraft on 9 September, 2000 - 10:56 am

The trouble with RAID is that the controller is still (often) a single failure point. If you are using NT I suppose the disk is constantly getting thrashed and this can't help their MTBF.
Alternatively - Our QNX solution runs from RAM once booted and allows hot-redundant PCs.
Never been a problem - never will be.

(Originally posted Wed 09/09/1998)
This whole thread brings up a good debate.
The risk of doing control with a diskless PC is significantly lower than on a system with a disk. Also, the smaller the operating system the higher the reliability. As a rough rule of thumb the more lines of code the higher the probability for interactions that are not detected in testing but eventually show up as bugs in the field.
Using diskless PC hardware with compact and proven operating systems (DOS & QNX for example) is much less risky than larger operating systems (NT, WIN 95, CE).
Having been in real-time control for over 20 years and seen the progression to distributed multi-processing I'm a bit miffed by the idea of running MMI, information, and real-time control in one PC under NT even with "real-time" extensions. This is the kind of stuff we used to do with minicomputers because the cost of a machine was so high. In the PC world it doesn't make any sense. Run control on diskless PC's networked to PCs for information and MMI. This is a scalable, reliable architecture. We regularly run ethernet as a backbone and have great speed.
All one needs to do is a MTBF failure analysis on a desktop vs a diskless PC to see the difference.
The PC technology is sound and will outperform any PLC. As for ruggedness our products run single board diskless 80486 and 586 CPUs and are certified 1E for nuclear which is a stringent set of test for operating under high noise and vibration. I don't know of any PLC product that meets this requirement "out of the box".
The flexibility of the PC architecture has allowed us to provide redundant processors that run in lockstep for guaranteed bumpless redundancy at a low price. No special programming required.
There is a great deal of propaganda floating around about this subject, but PC based controls are here to stay.
Bill Lydon
RTP Corp.
414-427-0789
http://www.rtpcorp.com

By Johnson Lukose on 17 November, 1999 - 1:10 pm

(Originally posted Fri 09/11/1998)
This is a good rule of thumb for microprocessor chips too - the more transistors you cram in the higher probability for all gate combinations that are not detected in testing but eventually show up as bugs during run time. OR doesn't microprocessor reliability count in overall system stability??
thanks

(Originally posted Mon 09/14/1998)
Good comment that has merit. Software however has a much lager number of permutations and has the ability to to modify itself ( many times not intended) which hardware does not. The number of applications loaded complicate this. The number of lines of code in software is so much greater than hardware making this a more complex issue.
I do agree that the lower parts count as a rule of thumb is higher reliability.
Years ago I had a government study that showed based on experience the more copies of a program being used the the sooner bugs will be found and fixed. Intuitively this makes sense.
Obviously reliability is a complex issue but I think using common engineering sense is the key.

No, hardware architecture is much less prone to bugs than software architecture. In part, simply because it is much, much larger.

> Are there any features or properties that a PLC has that PC based controllers do not?

> Specific reasons that are affecting your purchasing decisions are very appreciated.

> What could we do that would change your mind ?

> Thanks.
Reply:

I have noticed few points about people reluctant to move to a PC based control system instead of PLC..

First thing the reliability of PCs
Crashing of operating system
Operators / engineers may exit the system un noticeably....

These points may vary area wise or even country wise...

If anybody has better clarification ..It is welcomed !!!

Regards

By Will Brokenbourgh on 7 May, 2000 - 12:46 am

At one time, I worked for a major speaker manufacturer who had two different types of production lines working side-by-side. One side was controlled completely by PLC, the other by NT stations running AB SoftLogix. Guess which line was more productive?

The PLC controlled line never had a control-failure related issue, required a very short start-up time, was very responsive, and was more forgiving in terms of operator input and tech blunders.

The PC controlled line would have mysterious crashes, freezes, individual stations would stop communicating with each other or would just stop functioning for no apparent reason, recovery from power outages was a nightmare, boot-up time seemed like an eternity. All of this with name-brand equipment and top of the line AB software and hardware.

I vote for PLCs.

By Brian Woodcraft on 9 September, 2000 - 10:32 am

I just had to add my experiences to this one (excuse me if the protocol is incorrect, but i am a virgin at these posting things)

I worked for many years as a control engineer with Relays, then PLCs and now with PCs. At every stage I questioned the wisdom of whether the change was really progress, and always the answer is the same...

PCs are the future (the present for foward thinking companies) of our industry. They offer far higher performance and reliability if used properly.

Now don't get me wrong, Win NT is never going to be a solution for a Real-Time control system - I don't believe it was ever intended to be - but you have to consider that it is the (currently) ultimate front-end.

We use a QNX OS on our field control units and this is an excellent real-time solution offering connectivity to virtually any external interface as required.
The logic and control functions are scanned in a similar manner to a PLC, so offering a true scan cycle (typically less than 5 milliseconds for a plant with several hundred devices and a pentium 350).
Because it is a PC, just add a KT card and it will talk to Allen Bradley I/O (or whatever) use the standard serial port for modbus, a network card to allow comms to a workstation or 64. Want to share the information with half the world - no problem connect it to the web and let TCP/IP do the rest.

Attach some Windows workstations and now the control system can talk to anything, no bespoke protocols, no expensive hardware. Just good old fashioned MS (read 'world') standards.

Now your control system can get the current price of baked beans off of the web, it can e-mail the night supervisor to tell him to get some extra hands in, then it can make a load of extra tins of beans, it can use a workstation's sound card to shout instuctions at the line workers, it can queue the beans up at the warehouse door ready for the trucks, that it requested last night by calling the transport manager's mobile phone and using WAP to let him know that the price of beans was up.

OK so the analogy could use some work, but the point is that this is not a massive undertaking to achieve. All of this is pretty standard stuff.

I can't deny that this is all possible without the aid of a x86 processor, but it's much cheaper and likely to prove more reliable as the standards are better tested than any custom code. It's easier to maintain (PC hardware is off MANY shelves, not just the specialist few)and far more expandable.

respected sir, i am a third year under graduate engineering student studying in india. i am much interested in this topic and has been reading a lot on this wap application of process control. i am also engaged in research work at our institute regarding the same topic. i would like to know more from eminent people from industry like you on this topic. thanking you in anticipation harsh

Hi Harsh I guess the idea of WAP made you ask for this information. WAP is a commercial failure. But it is great idea that could be of immense use in the Process Control Industry. In fact Process Control industry in stuck in years behind. So something of similar concept will work. If you are interested in this, let me know what exactly is your background and what you want to do > Maybe I can help Prem

By snyderej on 29 May, 2001 - 9:29 am

About 3 years ago I first began trying to justify PC based control platforms (back then Intellution, Allen Bradley, Action, and a few other big names were all that was really available). Then the problem was no real time control in any of the above engines. Now some of that's addressed, but most applications still dont offer real time control kernel replacement of the HAL layer in NT. This isn't all bad, in a recent test of Allen Bradley Softlogixs 5000 we had scan updates of 1 to 3 ms (worst case) with some 1000 I/O points being scanned and we were watching a video on the same computer. I believe it was a 700Mhz Dell or something.

Let's also face the fact that someone has to support the system you put in after your gone. It seems easy at first to dive into something neat like linux rts's etc but what enevitably happens is you get a new job, training never happens as it should, and the plant is stuck with your pet project that someone eventually comes in and cleans out. Since I have cleaned some of these out, I can assure you, nobody talks good about you.

In the late 80's we began using VME based processors running real time kernels (like wind rivers) which also means we develop our entire control system in C Language and port it down, and on top of that we have written tons, and I mean tons, of application specific code to connect all these onto our plant ethernet backbone and our SCADA system through to our MES system. Now it takes specifically trained people to develop new code for these systems, you do not find these people on the web at jobs.com or whatever, you train them yourselves. It takes years for someone to really get a hold on these types of systems.

So what am I saying, we are again testing PC based systems and it looks like we are going to buy one this time. I won't say which one because I don't want to influence anyone but we had 7 or 8 engineers involved for the last 3 months and are just now testing it, so we are not stepping in unprepared. This is also a motion application with .5mS updates, if you've done your homework you'll respect this coming off a PC. Don't just pick the pretty package or the same manufacturer of the PLC equipment your used to buying if your thinking of jumping on board.

Take your time, they will all come to you with a demo. and make sure you understand how to troubleshoot it after it's in. The botup time is also a very usefull fact as someone eluded to earlier in one of these replies. I hated waiting for an old Unix based RTS system to load (remember NextGen?), it took better than 5 minutes, I would kill myself if I had to do that again. Of course I hated waiting for my old Allen Bradley 5/03's to download over RS232, but those are the old days, or are they?

By roger Irwin on 27 July, 2000 - 9:45 am

Just my 2C on this oft discussed issue.

The 'ideal' criteria for scheduling on a general purpose server (eg web server, database server etc) contrast with hard scheduling. Unless some specific hard scheduling mechanism has been installed you cannot simply 'pretend' it exists
because some empirical testing reveals n milliseconds of jitter, it is not reliable.

But if you do put in real hard time scheduling you open another can of worms with event queues, process queues etc. Modern OS do not like applications doing things as and when they like.

But there are solutions, which all tend to work in a pretty similar way. Given that both NT and Linux (to pick two widly contrasting systems) both have (more than one) RT packages available and that all work on the same principle, it would
suggest to me that it is THE method.

The principle is that a specific amount of processor time is set aside for real time processor, for example, in a 100ms cycle, 20mS is dedicated to RT tasks, and 80mS to the rest. During the RT time slot, normal OS operation is suspended, and a hard scheduler is invoked.

Of course the real time tasks have their own interfaces (drivers) to the underlying hardware, and to avoid chaos with all the queues and buffers in the host OS they do not interact directly with app space, but use a kernel based
interface.

When all is said and done it is as if you are running two systems on one physical hardware.

By steve harris on 30 March, 2001 - 3:01 pm

For one thing, us electricians were thought about when plc's were designed. It uses ladder logic, which we are familiar with. Second, PLC's are thought to be "industrial" grade vs. computers (office grade) What can you offer to make it more user friendly, cheaper, more reliable? Go ahead and sell me!!!

By Koen Verschueren on 4 April, 2001 - 4:03 am

1) You can easily find softPLC software that can be programmed in ladder. 2) There are also industrial PC's. you can find them with or without keyboard, with touchscreens or with only a few function keys so operators can't use them to install other application. 3) If you use a PLC and SCADA software then PC control with remote IO is cheaper. For small applications the PLC will be cheaper. I can think of some applications where a PLC would be better or safer, but in 80% of all applications you can change PLC by PC control. 4) If you use a good quality (industrial) PC, a flash harddisk and a Real time operating system a PC can be as reliable as a PLC. 5) Keep a PC control dedicated, once you have installed all software and hardware correctly you will never have problems with a PC I have done a number of PC's controlling cryogenic plants on a standard Compaq PC with remote IO from Advantech (RS485). I have written a Visual Basic program to control these plants. In the 3 years they are running (continuously) I never had a problem with one of them.

Have you guys worked on a DDC sowftare called "Action" . I got introduced to it in 1990 because the vendor supplied this as a datalogger device(remember those flashy old boxes) and for the best of my knowledge it is still functional. This was a simple DOS based DCS software in which I/O racks had to be added. It never failed all these years. No..there was nothing called triple redundancy, client-server etc. So I guess with the right price and support and some extra marketing effort, PC based controls can have a legitimate place in the market. Prem

By Zan Von Flue on 20 July, 2001 - 1:00 pm

> 1) You can easily find softPLC software that can be programmed in ladder. 2) There are also industrial PC's. you can find them with or without keyboard, with touchscreens or with only a few function keys so operators can't use them to install other application. 3) If you use a PLC and SCADA software then PC control with remote IO is cheaper. For small applications the PLC will be cheaper. I can think of some applications where a PLC would be better or safer, but in 80% of all applications you can change PLC by PC control. 4) If you use a good quality (industrial) PC, a flash harddisk and a Real time operating system a PC can be as reliable as a PLC. 5) Keep a PC control dedicated, once you have installed all software and hardware correctly you will never have problems with a PC

<--stop for point 1 and 2, your correct. However for 3, Scada information grows taking either softPLC time (this is not wanted) or the scada runs slower, so seperate the Scada and plc. This is not the idea. Also, small applications are better with a HardPLC, and I feel Large applications also. The expandiblity of a PLC is far greater then a PC. Plus you don't have to worry about the driver for the end device. Alone the video card in a PC now. If this dies (ok it happens) this card has to be replaced with a equivalent card and, who wrote the driver and DLL's? which is point 5- at least with us, a control system is yearly worked on. Other's can't leave things alone.
later
zan

By Jesper M. Pedersen on 20 November, 2001 - 2:34 pm

Here is an interesting topic for anyone that considers to use PCs for control applications:

If a control system or industrial plant is manufactured in europe, or is to be installed in europe it must conform to the "CE" regulations.
One important part of this is the EMC directive. Many peoble think that the "CE" mark that is found on almost everything today means that it is OK to use for control applications - unfortunately that is not so. The EMC conformity regulations are split into two "environments": "home/office"
and "industrial".
The industrial environment requires a higher degree of immunity against electrical interference (EN50082-2), but also allows a device to radiate more interference than normally (EN50081-2).

On short: In europe, all standard low-cost PC parts can NOT be used in an industrial environment. If PCs are to be used, they have to be industrialized versions with the appropriate CE/EMC declarations. That also goes for any
expansion cards, monitors, keyboards etc. I do not know if there are equivalent regulations in north america. But I think that the EMC directive is quite sensible in requiring components to perform in a noisy environment.

Greetings all

Jesper M. Pedersen - DISA Industries.

Mr Jesper,

Well, could u write expansions for CE and EMC, which u have stated as industrial safety standards?

thanks,
pran

By Michael T Mellish on 9 September, 2002 - 4:39 pm

1. Hardware Longevity: With a PLC, you can get spare parts which just plug in & work without changing your system for about 15 years. With PCs, you cannot purchase the same video card, harddisk or monitor within 6 months of your purchase. Yes you can find things that work BUT the regression testing for your system can be extreme.

2. Vendor Family maitenance: PLC vendors have entensive testing to ensure that every change fits the current family OR that there is an upgrade path which will carry the user forward. The PC world is filled with dead & dying software and hardware with no path forward.

3. Environment: PLCs systems work by natural convection cooling, across a range of temperature, particulate contaminents, shock and vibration that PCs just don't match. PCs need fans & therefore preventative maintenance to last in many enviroments. Shock is often not considered until the problems show up.

3. System Stabilty: Lets face it, the "Blue Screen of Death" is a fact of life. The sheer size of the operating system is 10x or 100x the size of a PLC operating system. Add the software reliability concerns to the fact that PCs have huge amounts of additional electronics which are NOT required for PLC logic control functions (like video, mmx extensions and the 2 trillion gates in a P4 CPU ..) and you pay for things which just are not used and which reduce reliability.

4. PLCs are also available from 8 I/O to 80,000 I/O so a price point can be found for the most cost effective control. Not many PCs for under $100 but there are PLCs.

PCs have found niches where they deliver a better solution... for example you want to do vision based inspection and reject parts, your vision system will almost certainly add a PC to the project and using it for control makes sense. You want to build to order (like a Dell PC) and want to interact with a computer directed manufacturing system to select parts, deliver kits to work cells, and assembly to order. Needs heavy custom programming, and would likely be better achieved in a PC based system.

But don't expect that an industrial PC, plus software, I/O interface etc. are cheaper than a PLC system sized for the same job...

Regards
Michael

By Anonymous on 27 July, 2003 - 11:47 am

basically plc based controllers and pc based controller are similars. plc based contrllers have also a mini computer with keyboard, any computer program can put as per the requirements.
plc has the limited memory to store the data and ram also. it has the processor is also for certain programmed as per the attached machine.
while in pc based contrller has more memory and fast processor. by pc based controller user can join more machines to operate from the same machine. easy for networking and dcs.

By Reza A. Naini on 11 December, 2003 - 11:55 pm

in many cases PCs and PLCs have same charactristics except two important points.

PLCs are very easy for maintain, eg: you can simply add/remove hardware cards to/from PLC in a few seconds. and the 2nd one which is very important to industrial automation, PLCs MUST NOT have a chance to hang. it means that in a PC, if you write an invalid opcode, you will get an exception which may be handled or not, but in some cases (even one) the PC may be crashed. which is a bad thing in industrial automation. in such cases a PLC STOPs and reports all errors by detail.

By Curt Wuollet on 14 December, 2003 - 11:09 pm

But again, that's not the PLC, it's the software run on the PLC. If the same software were ported to a PC motherboard, which is not very far-fetched as some use the same processors, it would have the same features when used with a totally controlled set of peripherals. Again, you confuse your experience with one particular OS as what a PC is capable of and limited to. This is simply not the case. A SBC coupled with a bus that does only automation things could provide all the same attributes.

Regards

cww

By Anon emouse on 22 March, 2004 - 11:20 pm

You try and explain to a production manager why the PC crashed. Bad enough explaining PLC failure. Then again, PLC very rarely crash in my experience from bad software programming.

By Curt Wuollet on 25 March, 2004 - 12:53 pm

And in my experience, you don't have to explain crashes if you don't run crashware. And you _can_ crash PLCs with software, believe me :^) Usually it's right away though. You need 4.5 billions lines of cruft to get the really subtle crash mechanisms. I've found on Linux code that if you run for a week and there's no sign of memory leaks, you're in pretty good shape. Windows leaks core without any user programs running. That says something (bad) for the long term.

Regards

cww

By Bob Peterson on 26 March, 2004 - 12:06 am

I would say that is not my experience. At least with SLC5s. Its quite easy for errant application software to cause a CPU fault, and if appropriate action is not taken before the end of the scan, the processor exits run mode.

I see this a LOT, usually with inexperienced or just bad programmers.

Bob Peterson

By Eduardo Manuel C. Cipriano on 16 October, 2003 - 5:07 pm

Hi Guys,

It's really very clear that PCs are made for information purpose only, while PLCs are for Control purposes...

thanks

By Jonathan Teh on 29 October, 2003 - 11:38 am

It seems that using PLCs as a base with PCs as operating and programming interfaces seems to be where today's control systems are heading towards. Consider the reliablity, durability, and ability of the PLC, the flexibility of the PC, and the accessibility of both.

I think PLCs are best suited for relay replacements. They are best at high speed single bit ON/OFF control logic. When using them for slower analog control then the resolution and accuracy is usually limited to 12 bits.

PCs are best at high resolution computations (64 bit), recipes, HMI displays, data logging, networking.

When properly selected and installed in a clean cool environment, and have not been loaded with all kinds of junky unstable software, then they are just as reliable as PLCs.

The hard drive is the lowest MTBF component, but this could be replaced with a Flash drive. This also depends upon the software. If the program only uses the HD to load the program at startup and then does not use the HD, then the HD should last a long time. If you have a Norton Ghosted backup HD available, a HD crash can usually be repaired in a few minutes. And the PC hardware is cheap and readily available at you local PC store.

We have been using PCs to control temperatures in plastic extruders for over 5 years with few problems. This is a high resolution - high accuracy - high computation application where millisecond response is not needed. This also provides HMI, recipes and data logging in the same software package.

Warren
http://www.pc-pid.com
"the PC-based Temperature Controller people"

By Nathan Boeger on 28 October, 2006 - 2:02 am

An interesting property that I haven't seen mentioned is the fact that PLCs program can be edited in runtime. This is equivalent to recompiling a running program on a PC, which is not possible to my knowledge.

For example, in a PLC based system, you can edit a running manufacturing process, commit the change, and seamlessly run a new one. I don't see why this wouldn't be possible on some emulation layer on a PC based control, but in all the systems that I've ever seen PLCs handle this well while PCs don't

Hope this helps,

--
Nathan Boeger
http://www.inductiveautomation.com

By Jordan Clark on 19 November, 2006 - 4:00 pm

KW-Software's MultiProg (PC-Based) will let you perform an online edit. Conversely, a low-end PLC, like an AB MicroLogix will not.

A good (read "stable") PC-based control runs under it's own kernel and uses Windows (or KDE or <insert favorite GUI here>) as a nice clean interface for those of us who don't have time or inclination to do command-line type programming. Can I do it? Sure! Do I want to? Not really! :)

For what it's worth, this opinion and a dollar might get you a can of soda.

Regards,

Jordan

Yeah, but.
PLCs are usually made with close to mil spec components.
PCs on the other hand...

If AB or Modicon puts out a PLC with a code defect that costs someone their life, they are responsible.

No one is responsible for open source.

This is the first time I've been to this site and I'm quite amazed how engineers are comparing a PLC and PC-based Control System.

I'm not sure of what you mean by PC-based system. Guys, correct me if I'm wrong, the PC-based system is the DCS or the Distributed Control System.

It is a fact that a PC cannot and should not control a process. It is only used for configuration, Man-machine interface (MMI), historian or event loggers, etc.

In both PLC and DCS systems both uses PCs or programmers to configure the operation and download it to the controllers. PCs for MMIs, etc.

Both have advantages and disadvantages i.e. trade-offs.

The main point of the discourse now is reliability against functinality and flexibility. (Not to consider the $$$ for this functionality.)

PLCs have the reputation of reliability, robustness and even life-cycle because once programmed it is already there in the controller.
With respect to system crash, comparing it to PC-based, it is true that the PLC quickly reboots with just a click of a button called system reset.
The problem does the process quickly resets. It has to start-up again!

DCS has the reputation of being fairly reliable but is also flexible. New functionalities can be added to the system easily using open-system configuration, i.e. OS platform like NT, XP, LINUX.
The problem with open-systems is, it prone to attacks intentional and unintentional. Life-cycle with respect to hardware is comparable to the PLC but with the PC, every now and then MS is releasing new OS versions. NT is no longer supported by MS. So users will have to upgrade to XP, then to VISTA, then who knows!

There is really no comparison with PLC and PC-based or DCS.

It is up to user on what he wants on his process!
There will always be trade-offs.

By Curt Wuollet on 25 February, 2007 - 10:51 am

It's interesting that one could even generalize that PCs are unsuitable for PLC tasks. These days they are more similar than ever and the ultimate PLC, when they finally gain all that they are lacking now, will _be_ a PC. With the right software and a few hardware selections to eliminate the hdd, etc., there is no reason a PC can't be a Super PLC. You are confusing the machine with the crappy software that comes loaded on it. I have several PCs that have no idea that they aren't PLCs. And the applications don't know the difference either.

Regards
cww

Your assumption is incorrect. PC control is not the same as DCS.

PC based control refers to systems like AutomationX, LabView, or SoftPLC.

Once you understand the definitions better, I leave the comparisons to the previous posts.....

--Joe Jansen

Personally I am never touching a traditional DCS or PLC system again. Seriously it gives me a headache to work on that stuff.

Over the past decade, we've been doing installations of fully PC based "PLC/DCS-like" systems. We run entire plants on a PC server pair, or complete process areas in larger plants. The PC's are throttled direct to the I/O without PLC processors, controller modules etc.

Advantages are: less hardware, more reliable much less wiring, as we are mainly using Profibus efficient setup and maintenance easy upgrades Great ROI with long life cycles and protection against obsolescence. Servers and/or OS are commodity items and are swapped out ~ 5-7 years. Software upgrades typically we do annually for sites under contract.

Speaking from experience - The PC servers doing the job have never been hacked, disrupted or tinkered with in anyway by anyone. Only respected and appreciated. With the redundancy, PC system uptime has been remarkable, close to perfection and on par with the DCS and PLC systems that they run alongside.

A lot of IT missions these days are as or more critical than traditional industrial, in terms of impact of downtime. So the IT products reflect that.

Cheers,
Paul Jager

By Ken Emmons Jr. on 26 February, 2007 - 11:52 pm

It all depends on what you are doing. Windows is not deterministic in the "Hard-Realtime" sense of the word, and Profibus is fast, but not as fast as a backplane of a PLC (I'm sure there are exceptions to that, but you get my point). PLCs also have the advantage that the popular ones are supported for decades and not in single digit years. The hardware of most good and popular PLCs will outlive just about any computer with a standard PC power supply and a mechanical hard disk. And yes, you can make operating systems more robust, get rid of hard drives, and do all sorts of things with redundant power supplies, but most people don't do that because it is more work to maintain and set up.

I'd like to sum it up and say that if all of your control is slow enough and not dependent on things happening in a certain time (seconds) you can use a distributed PC based system and be very happy with it.

If on the other hand you are running fairly high speed equipment (1ms response) that needs to run the same day after day, don't use a DCS system.

~Ken

On February 25, 2007, Paul Jager wrote:
> Personally I am never touching a traditional DCS or PLC system again.
> Seriously it gives me a headache to work on that stuff.
>
> Over the past decade, we've been doing installations of fully
> PC based "PLC/DCS-like" systems. We run entire plants on a PC
> server pair, or complete process areas in larger plants. The
> PC's are throttled direct to the I/O without PLC processors,
> controller modules etc.
>
> Advantages are:
> less hardware, more reliable
> much less wiring, as we are mainly using Profibus efficient
> setup and maintenance easy upgrades Great ROI with long life
> cycles and protection against obsolescence. Servers and/or OS
> are commodity items and are swapped out ~ 5-7 years. Software
> upgrades typically we do annually for sites under contract.
>
> Speaking from experience - The PC servers doing the job have
> never been hacked, disrupted or tinkered with in anyway by
> anyone. Only respected and appreciated. With the redundancy,
> PC system uptime has been remarkable, close to perfection and
> on par with the DCS and PLC systems that they run alongside.
>
> A lot of IT missions these days are as or more critical than
> traditional industrial, in terms of impact of downtime. So
> the IT products reflect that. <


( Complete thread: http://www.control.com/thread/941648158 )

Here's what we are doing for installations:

Major process industry: Paper, Steel, Oil and Gas, Nuclear Power, Food,
Mining, Waste treatment
Major manufacturing: Auto sector, Consumer goods, Electronics, Equipment
Transportation - Roadway Tunnel management/cotnrol, Big ships, Railways
Large Building and Facility Automation
Electrical Utility Systems

I think the record for one server pair is over 6000 I/O. That's huge and I mean REAL I/O - analog and digital wired inputs and outputs. Typical
installations are anywhere from a low of 100 I/O to 4000 I/O with about 4-12 client stations. Clients can be anything - remote view only to full
engineering stations - all depends on setup and login.

The SERVER scan times we are running are ~ 20mS but typically set at 200 mS. System response is in the PLC range and superior to every DCS I've used. For faster scanning or nesting of functions the engineers divert to a distributed "device" arrangement. Using the Profibus coupler module as a control CPU, or a small compact industrial PC unit managed from the server.

Client response or what the people use and the display update is almost instant because everything is on the server ported via X-windows.

For most operations, the priority is not about working the details of hardware. In most cases, the priority in designing a system for operation is about the efficiency of the people and process using the system. If the in-between can be as open, efficient, effective, transparent and simple as possible (but allowing the very complex to take place) with the least amount of hardware and other barriers, then that's progress.

Personally, my hands will never touch a keyboard related to a traditional PLC or DCS. Too long to spec, setup, & cumbersome work with, pain to commission - just wretched. OK if you like OT I guess.

Paul Jager

I have just built a system with a PLC and touch screen for my company. It a packaging check that checks a part with a seq. number through 4 stations. It is to make sure that the part went through all the stations. I also capture all the variable data in a database in the screen (leakage rate, date time, part number). The screen runs javascript so the sky is the limit. All over ethernet.

2 months earlier I built a similar system with
an industrial PC. My finding was there was a lot less coding in the PLC system than in the VB one I did. It was also much easier to handle the data transfer from the different stations to the screens database than with the PC. When something went wrong in the VB app (runtime errors for no reason), the maintenance crew could not fault find it. The PLC system on the other hand is still running with no "run time errors".

Regards,
Craig

PCs have to come a long way to be as easy to integrate as PLCs.

PLC vs PC? Wow, hasn't anyone seen the Xycom computers used to provide FASTER control, more reliable control, and are even integrated into a PCI interface with an AB plc backplane.

this literally is the best of both worlds, easy to troubleshoot, and program editing is a sinch through Wonderware.

Climb out of your holes....

By Anonymous on 18 May, 2007 - 9:23 pm

Well, in the old days, we always concerned the blue screen and long boot up time from PC. However, now in market, there are seveal good PAC (Programmable Autoamtion Controller). It over came these PC's issues including blue screen and long boot up time because these PC based controllers use Windows CE.net. Check these two companies.

ICP DAS USA, Inc.
http://www.icpdas-usa.com/pac_programmable_automation_controllers_.html
Their PAC can run logic control and HMI all in one with standard VGA monitor port. You can program them in ladder logic and many Microsoft software.

NI, http://www.ni.com/pac/ You can program them in Labview. Most of everyone knows Labview.
Both of these controllers belong to PC based control but with PLC robustness.

By G.J.Dreijer on 12 June, 2007 - 12:00 am

If you want robust control use a tank.
If you want to distribute large amounts of data use a truck.

If you want both, use both: a PLC and SCADA or an advanced MMI.

By tugalsan karabacak (Turkey) on 12 August, 2008 - 1:25 am

PLC code runs smoothly, it is so old, and cannot do complex algorithms. And it takes too much time to code it.

On the other hand, PC is more friendly with a full-screen SCADA (PC-monitor), with a very cheap price.

In my opinion, one should use both. With least memory PLC (for uninterruptable processes like motor controls), a Modbus connection, and with a Java enabled PC. :) There you can get most robust, most clever, and cheapest system one can ever have.

PC vs. PLC: both have strengths and weaknesses BUT I don't think there is much of a debate if one is worried about mean time between failures (MTBF).

By Fred Gjoertz on 27 November, 2008 - 8:54 am

PC doesn't necessarily mean running a buggy Windows OS. We've made advanced control systems on standard PC HW and using standard SW for years. Our Control Design Platform allows you to use stable Linux or real-time oriented RTOS-32 on industrial PCs for the control system. Programming is done in C++. Redundancy is achieved using the platform and the redundant hardware may even run a different OS. Check out the possibilities: http://www.icd.no.

In my opinion, nature gives very nice examples of control systems.

In nature, complex decisions are done by brain. simple and fast decisions are done by cerebellum.

I think automation systems will behave in same manner in future.

PC will act as the brain for complex decisions. And PLC will act as cerebellum to manage reflexive processes such as mechanical movements, emergency stop etc.

So, they can't compete; they will work together and support each other with their different capabilities.

By Curt Wuollet on 18 March, 2009 - 3:57 pm

Just curious, I may well be out of the printing business.

Regards
cww

By Curt Wuollet on 19 March, 2009 - 2:51 pm

I agree, but there would be enormous savings even for the big vendors if you could get even any two to avoid developing their own from scratch. And some I've seen would be much better off not developing their own.

Regards

cww

Hi Don...Well d guys have already given brilliant replies to ur query...
it ws indeed a vry good nd logical qustn...
I would like to add one more point.
Normally, in any industrial procs, there r many inputs which need to b simultaneously appld to d controller.
Now, a PLC can have dozens f inpts and outpts whr z a PC allows only a limitd nmbr f inpt nd outpt points.

hello

----- snip ----
> I would like to add one more point.
> Normally, in any industrial procs, there r many inputs which need to b simultaneously appld to d controller.
> Now, a PLC can have dozens f inpts and outpts whr z a PC allows only a limitd nmbr f inpt nd outpt points. <

Today that's not the case. There are DIN rail PCs ( e.g. the Wago I/O PC) which are extendible with a lot of DIN rail I/O modules.

PC controllers have also access to the fieldbus technology ... most fieldbusses are supporting 32 - 256 remote I/O modules.

Best Regards

Armin Steinhoff
http://www.steinhoff-automation.com

Interesting....
How little this has changed in 12 years.

By William Sturm on 28 January, 2012 - 10:12 am

One thing has changed, 12 years ago I would have replied to your message :)

Bill Sturm

By William Sturm on 28 January, 2012 - 10:14 am

Maybe everything that can be invented has already been invented?

Bill Sturm

Why few navies world over still prefer VME based IPMS over PLC based systems?