PC based Control .vs. PLC

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

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.
 
(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
 
(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
 
(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
 
(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!
 
(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 Mon, 31 Aug 1998)
[email protected] 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
 
(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.<<
 
(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.
 
(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
 
(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.
 
(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 :cool:

> 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, 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.
 
S
(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
 
(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
 
D
(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
 
H
(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.
 
H
(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
 
J

Johnson Lukose

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