Hi Larry

> From: ScienceOfficer
> To: [email protected]
> Subject: Re: PLCS: When will PLCs catch up...!
>
> Curt---
>
> I'd love to see that Linux CD fix the failures I've seen in monitors, power supplies, pointing devices, hard disks, memory sticks, video cards, IDE interfaces, etc., that are in PCs and NOT in PLCs, and that are the reasons why PC reliability cannot approach PLC reliability.


Have you seen my writings on selecting reliable PC components? PC quality is a very manageable quantity seldom achieved by buying packaged systems. And easy to achieve by watching the boards you're interested in for a while before selecting one. That said, I've had very good luck with machines cast off as being unstable or too slow under Windows or even just plain dead. Something must account for the difference, and I've had customers remark that they have far fewer failures of any type running Linux. And I had nothing to do with building and selling those PCs. I would be most curious to see the figures from people who use massive amounts of both, like ISPs. This machine is running on two hard drives that were given to me as unusable. They were scribbled on and needed TLC but were certainly no dead. I'm not sure Linux could fix all those problems, but I've got a strong feeling that stability and lower resource use can prevent many of them. And that software trips to lalaland can be very hard on hardware.

> My own anecdotal evidence is that Windows systems properly set up run for years as well, until something breaks. Right behind me here is a Win95 PC that did nothing but run SETI@HOME units for three years nonstop, because I had nothing else for it to do. I replaced its hard disk three years ago; last month the power supply went. Meanwhile, PLCs that I installed during my integrator days in the eighties continue to work without a failure to this day.


Some will, some won't. Even MS readily admits that some versions were crashware, prompting a "crash" program on reliability that has shown very noticeable improvement. But your anecdotal evidence that PCs are unreliable is, no doubt, on MS platforms as well.

> I think a more important reason why PLCs eternally fail to meet the needs of many who complain is that they don't really want a PLC. The remaining PLC manufacturers are shipping more units than ever; declining revenues are in large part because the newer products are significantly cheaper than the older stuff. The user base for PLCs continues to expand. So does the user base for automation outside of the PLC world!


There is also the factor that an awful lot of PLC applications these days have a PC in the mix. And that's redundent as well as providing a vibrant contrast in bang/buck.

> I have several clients that use *nix solutions, Windows solutions, PLCs, embedded controllers, and even all of the above at once. Dogs and cats living together!!


Yes, and I see that as a very healthy situation. Much better than those who are absolutely monotheistic. Outside automation, I found 90% of selling Linux and other alternatives was simply getting to where folks could make a comparison. Inside automation, I suspect it would be more like 99%

> I seem to stay on good terms with my clients while admiring their choice of the correct solution set for the problem at hand. If it ain't a PLC, I can live with that, as long as it's the right choice.


I agree, but my customers tend to be biased and sometimes even want total absolution from the past. This isn't always the right approach

Regards

cww

 

Thanks all for you criticisms (be it constructive of destructive). Some interesting points raised although I think a few missed the point that I was not proposing a PC as such, just something developed with the PC ideals, ie. open architecture to which anyone can develop components/software. I was worried some might get their backs up by hearing PC mentioned in the same sentence as PLC. Before it is dismissed completely keep in mind AB Control Logix use the Strong ARM processor which is the same as many PDAs, seems that it would not be a big step to take to the next level for AB at least.

Regards Doug

PS. Special thanks to those who feel it nessesary to make comment with insult rather than inteligence.

 

On May 24, 2003 09:37, Doug Panacea wrote: <clip>
> Thanks all for you criticisms (be it constructive of destructive). Some
> interesting points raised although I think a few missed the point that I
> was not proposing a PC as such, just something developed with the PC
> ideals, ie. open architecture to which anyone can develop
> components/software. I was worried some might get their backs up by hearing
> PC mentioned in the same sentence as PLC. Before it is dismissed
> completely keep in mind AB Control Logix use the Strong ARM processor which
> is the same as many PDAs, seems that it would not be a big step to take to
> the next level for AB at least.
<clip>

A "PC" is a "personal computer". You are essentially looking for a computer suitable for industrial application which comes without any operating system or application firmware. This is essentially what Compact PCI, and several other designs (PC/104, etc.) offer.

>keep in mind AB Control Logix use the Strong ARM processor which
> is the same as many PDAs

"ARM" stands for "Acorn Risk Machine" and originally designed by a PC manufacturer (Acorn) as the CPU for their line of PCs. Acorn was a major PC manufacturer in the UK. ARM derivatives were later used in embedded devices where low cost, small size, and low power consumption were important.

The type of processor is only relevent in the sense that it defines your available choice of pre-packaged software. The essential difference between an oridinary "computer" and a "PLC" is the software. A PLC comes with all the necessary software pre-loaded and ready to accept your ladder (or other) program. A PLC is designed to suit most industrial applications without any further preparation.

Essentially, your problem is software, not hardware. The hardware exists. The software exists also - there are soft logic systems on the market. A few years ago soft logic systems were widely touted as being ready to take over the PLC market. This didn't happen. The real question is, does the demand exist?

--

************************
Michael Griffin
London, Ont. Canada
************************

 

There's a built in conservatism in the automation market, and it exists for good reasons - in this it differs significantly from the desktop market. The key requirement from people implementing automated production facilities is that the production systems are delivered on time so that the new facility is on line and producing when it is required - the costs of not getting plant online on time (in terms of lost production) are massively greater than the cost of the physical automation hardware (at least the PLC and controls side). So risks are reduced where possible, and an easy way of doing this is simply to do what worked last time. Since contractors and SIs are often employed to do the controls, and they are under contractual obligation to deliver to strict deadlines, even if the end user is inclined to experiment, the integrator may not be.

I don't argue this is specifically good or bad, but it does limit the ingress of new technologies. Fundamentally anything new has to provide something additional of such massive merit (e.g. large scale cable cost reduction by replacing point to point wiring with fieldbus, which is the one big technology shift we've actually seen over the past 5 years) that the risks of change are massively outweighed by the benefit. New stuff such as PC based control, general "openness", IEC1131, and so on are neat, yes, but in themselves probably don't provide the critical benefits needed to force change through.

In contrast, the PC market for desktops is a true commodity market in which the commodity pricing is now pretty much turning the devices into disposable items. The cost of something not working is pretty low, and most of the applications running on them are not business critical so no-one is too worried about upgrading (with the exception of CFOs!). So the technology cycle is allowed to run much faster.

In essence, although the technology looks similar, the application areas and requirements are very different. I think this has to be understood before attempting to draw analogies between the two areas.

Cheers

Tim Linnell

 

Tim, I completely agree with your argument regarding the conservatism in the control/automation industry. I don't think there is much question of this and I think there is good reason for it.

I also agree whole heartedly with the argument that PLCs are very different from PCs and that reliability issues of PLC carry a far greater risk that that of the PC. I don't think there is or should be any question that the PLC needs to be industrialised. Moreover, current PC standards, in their current form, such as PCI, are perhaps not appropriate for a PLC application. Though the concept of such open standards are.

I do also think that a lot in the PC verses PLC camps are arguing different points. I for one do not think PCs are appropriate for PLC applications. This article was not posted as a pro-PCs in controls spiel.

However in saying this, I would like to reiterate that I would like to see some of the ideals of the PC world visit the PLC world. And for this to happen, I think the big names in the PLC world need to take some action.

As an example, (hypothetically) I would like to choose to use a Siemens CPU and rack as it is faster/cheaper/bigger (hypothetically) than any other on the market. I would like to program this control system with an Allen Bradley IDE package as it is far easier to use than the Siemens equivilent (and I can program in a OO language, hypothetically). I would like to use Schneider analogue input modules in the system as they have the fastest sampling rate and accuracy. And I would like to use a 3Com(??) ethernet module as they seem to be very reliable and cheep (hypothetically).

Choice. The problem is choice (…there is no spoon).

 

In order for one brand configuration tool to program a control strategy and download into another brand controller, you need not only a standard communication protocol, but also a standard programming language, which moreover is integrated with that communication protocol. As far as I know, only FOUNDATION(tm) Fieldbus does this.

Moreover, this permits different brand controllers to communicate with each other peer-to-peer. As far as I know, only FOUNDATION(tm) Fieldbus does this.

Jonas Berge
==================
[email protected]
www.smar.com

 

Just curious, when you buy a Ford car do you demand that they put a Gm air conditioner in it because they have a better feature?

With competition between any product or business you will have progress. That is why there are great advances in the PLC controls and industry. Also with the open networks like Devicenet, Profibus, etc., these individual companies can use their own advance technologies to tie into other systems.

 

What was the last “great advance” in PLCs? If compared to the PC world, PLCs move at a snails pace! And while PCs are obviously driven by much larger demands, why not take advantage of this instead of every PLC manufacturer trying to re-invent the wheel (or a new wheel that can do the same job, only a bit different to the last one you used and that requires a different set of tools to ones you just purchased and spent time getting use to).

And how can you claim there will be no competition or progress. I don’t see PCs at a stand still!!

The PLC vendors try to do it all themselves, which while some features of a particular system are good, it is at the expense of other features.

In PC land, there are plenty of big vendors (HP, Compaq, IBM) who flog complete high-end systems, fortunately I’m not stuck using their OS as that is not what they are good at. They all compete with each other and with other more specialised companies, the systems and components progress (rapidly) and prices fall as technology becomes easier to develop.

Also, I think your analogy may be looking at too low a level. If I were to buy an AB processor card (or a ASUS motherboard as a PC example), I would not expect to unsolder a component and replace it with that of a Siemens processor card. Also, as for cars, I am generally not stuck using genuine parts, I can use the same set of skills to drive any of them, and they all are compatible with “roads” whether I use the concrete, tar/ashfelt or dirt varieties, my choice.

(again I’m not suggesting a PC to do a PLCs job…)

 

My point is primarily about standard configuration/diagnostics tools. My experience is that users want a single tool for all the parts of their system, package units, including instruments, i.e. the ability to configure and troubleshoot hardware from different suppliers.

I'll try to put it in the perspective of your car analogy: in the past you could adjust the carburetor of a Ford with the same screwdriver you used to tune a GM. Today you need special tools and skills for diagnosing different brands of cars. What I am looking for is a standard that enables a software tool to work with different cars.

I agree with you in the sense that mixing modules that are really part of the same box is pushing it a bit too far (at least what I see today). I.e. I don't agree with "Anonymous" that you should be able to use Schneider I/O modules with a Siemens CPU, but I do think it should be possible to configure a Siemens CPU with a tool from Allen Bradley. Anyway, the notion of I/O modules is hopefully soon gone as more and more sensors etc. are networked instead.

Standards do not kill competition or stifle innovation. Standards come about when innovation is no longer innovation, just annoying tweaking and reinventing the wheel. At this stage a standard makes sense. Standards allow us to move to the next level, and make new true innovation with the established standards as a base. Without standards for nuts and bolts, and RS232, etc. we would not move forward and would not have seen all the innovations that rely on the function these provide.

You seem to be speaking in favor of open network (standards) to tie things together. This is exactly my point. The next logical step is then to have a standard that permits the creation of standard tools to configure the different devices that share the same open network. It is not very helpful to have different PLCs, drives, remote I/O etc. on the same bus when they each need their own configuration tool for parameterization and building control strategies. There are standard buses, and a standard for programming languages (IEC 61131-3), but no standard for downloading of an IEC 61131-3 control strategy into devices on a standard bus.

FOUNDATION(tm) Fieldbus uses the IEC 61804 programming language (function blocks) and also defines the protocol for downloading it and communicating the links across distributed devices. You can read about how this is being used in chapter 4 of the book "Fieldbuses for Process Control: Engineering, Operation, and Maintenance" (buy online in hardcopy or download immediately in softcopy). If your email does not support this hyperlink feature correctly, please copy the URL and paste it into your Internet browser. Mind the line wrap, make sure to get the complete path all the way to the 3036: http://www.isa.org/Template.cfm?Section=Shop_ISA&Template=/Ecommerce/Product Display.cfm&ProductID=3036

An overview of the whole picture is in chapter 1 which you can download for free in softcopy form. Mind the line wrap, make sure to get the complete path all the way to the 4585: http://www.isa.org/Template.cfm?Section=Shop_ISA&template=/Ecommerce/Product Display.cfm&ProductID=4585

If you want to know the internal details of HOW the protocol/language works see the Foundation(tm) Fieldbus technical overview from the Fieldbus Foundation: http://www.fieldbus.org/pdf/techoverview.pdf

Jonas Berge
==================
[email protected]
www.smar.com

 

I think the more apt analogy is that at one time it was quite common to skip the factory auto options because you could do much better with aftermarket equipment for much less money. It was this specialty competition that produced the vast improvements in automotive amenities noted recently. It was not Ford's crappy options VS GM's crappy options. I am quite convinced this industry would see similar quality and value improvements if true competition were enabled by Open protocols and interfaces. Very few discriminating consumers would pay big bucks for a factory sound system until they got a little serious about quality. And AC is still perhaps the least reliable part of today's cars. If it were made reasonably easy to integrate, I'm sure the aftermarket would be booming.

Regards

cww