When will PLCs catch up...!

D

Thread Starter

Doug Panacea

When are PLC manufacturers going to catch up with the rest of the microprocessor based technology community. I am continually frustrated when having to use and program PLCs.

Of course every PLC manufacturer thinks that their PLC is the only way forward (typical Engineers outlook). Every PLC manufacturer runs its own OS, programmed with it's own programming software and development tools (which generally costs as much as the PLC itself), used only its specially made and expensive modules/cards and generally communicate by its own special comms protocol (although comms issues are improving).

Is it not time the PLC manufactures get together to develop a standardised and dare I say open architecture, similar to what IBM did with the PC. Something based on a PC type processor so costs are kept down and speed up due to the PC market. Something with an expansion bus similar to the PCI bus to which I/O, comms etc, cards from any manufacturer can be plugged into. Something that is fast, ie. has a scan rate of more than 10ms (which realistically, in microprocessor terms it 'ken slow). And something where an increase in just only tens of kilobytes of memory doesn't cost hundreds of extra dollars, why can't I have hundreds of MB of memory on my PLC, long gone are the days where memory was a significent cost of a computer. When will PLCs catch up.

And lets not start carrying on with the old excuse of the reliability of a PC compared to a PLC. We are not talking about a PC here, it is not running Windows XP with a million background tasks and applications, one of which may or may not crash the machine. As far as the hardware goes, it will be no less reliable that a normal PLC, this machine is just based on a different architecture, an open one. Its job will still be to run a single program to control stuff, the difference being is I can run the same program on a machine manufactured by Siemens, AB, GE, Modicon etc.

A particularly fustrating issue is that while a particular PLC may provide all the features one might need in a PLC, the programmer is stuck using the manufactures programming software to programming (which is generally crap). A good point in case is the Quantum PLC, while a reasonably good PLC, the programming software is hopeless.

With an open architecture, as for the PC, a programmer may choose to use any of a variety of software to develop a program. This would lead to some much better development enviroments. We would also be free to program in languages other than ladder (if the end user electrician is capable of reading it!), maybe even a real OO language.

With all this in mind, I see no reason for the PLC manufacturers to be nervous or apprihensive, afterall they will still be manufacturing PLCs and PLC components. And as with PCs, the open and standardised architecture doesn't limit development of units with new and improved features, it will more likely encorrage it. The manufacture of choice will still be therefore based on features, cost, reliability etc. Nothing will change other than a bit of healthy competition.

I'm just a mere Control Engineer and so can do nothing more than write snotty letters about what I would like to see done. I do however hope PLC manufactures will soon see the merits in what I am proposing (which is by no means a new idea), and take it upon their collective selves to co-opererate.

I think they are all a long way off the mark at the moment and it doesn't stop at the PLC level. The current trend continues through to SCADA packages although that is entierly another topic.

When will the PLC catch up, I think it is about time!!!

Doug Panacea
Controls Engineer
Melbourne Australia
 
Well!!!!! Quite a mouth full and will no doubt bring very mixed and emotive responses. This one is not emotive but states how I feel about all things PLC.
I agree with you about software. Some of it is so hard and unfriendly to use that one would be better off without it. Some manufacturers charge the earth also.
I like the software for my preferred PLC brand, Omron. CX-Programmer 3.1 is really very good, powerful, easy to use and not expensive. One set of software does all PLCs, except the very small programmable relay the ZEN.
The newer Omron PLCs are very powerful with over 400 functions to make life easier and the higher end processors are very quick. (CS1 & CJ1). Omron also have CX-Protocol software so that one can write protocols easily to communicate with any serial device. No fancy languages required.
I do not agree with using "OO" languages for industrial control. Companies are generally trying to move away from that direction as no one in the plant can understand them. I totally agree with this view. Many consultants are now trying to get BMS systems based on PLCs and SCADA systems so that they are not tied to a particular company that has the source code, preventing anyone else from accessing the system and allowing then to rip the client off whenever a change is required. Many people can programme in ladder and this is very much becoming the preferred method so that the end client does not get ripped off.
April had a PLC many years ago that was programmed in C or C++. Have never seen one used.
Omron had a PLC some years ago that could be programmed with a mixture of ladder and C. Have never seen one used and in fact it was a complete disaster sales wise.
You mention communications as being an issue. I have no problem with proprietary networks as long as they are fast, reliable and token ring based with redundancy built in for the controlling card to "move". Omron Controller Link is a perfect example, not all that expensive, easy to set up and use and WORKS very well. Cannot say the same for Ethernet, although many PLLC manufacturers are now either incorporating or planning to incorporate another communications layer running on TCP/IP but below the Ethernet layer. This may prove to be reliable but I still maintain Etherenet is NOT and will not use it. Have been forced to use it on several projects with different brands of PLC and got sick and tired of having to hard wire signals from PLC to PLC because I could not rely on getting consistent signals from the Ethernet layer. Damn thing falls over from time to time also. Maybe Ethernet IP may be better but I will wait and see. I need speed and reliability as there is no time to wait if you need to get a diesel generator offline in a hurry. For example, generating at 11kV, lose the earthing switch, 11kV is floating way above ground (I have seen 8kV above ground) and blowing all up all things earthed at the other end. Not much time to act I can assure you.
There are some fairly good I/O networks out there that are reliable. ASI is OK for small digital I/O networks, Profibus is OK if you like it (I don't), Device Net is my choice at the moment due to the great variety of devices available and the ease of use. Once again, my preferred brand is Omron and I have not used Device Net on any other platform.
I cannot see what you propose happening, despite it's merits, and drawbacks. The Americans and Japanese have their own ways of doing things and the Europeans are hell bent on the software being "click and drop", causing one to finish up with RSI. They are also hell bent on using function block programming. I personally find it limiting, slow and a pain in the "A" and prefer to stick with ladder. I can develop programmes very quickly with CX-Programmer and set the software up to work the way I want to work and I guess that is half the battle.
I will be very interested to see the varied reaction to your rather large needle.
Regards
 
A

Anthony Kerstens

Perhaps that can happen when everyone has a PLC
on their desk and at home instead of a PC. I
suspect that if PLC's were sold in enough volume
to make them the sort of commodity that PC's have
become they would be less expensive.

Just imagine it. Logic controlled pencil sharpeners and staplers. Or even automated tilt positioners for displays... and chairs!! Screen savers brought to new and amazing dimensions!!!!

Oh, and last but not least...
*** the mother of all boss keys ***

:)

Anthony Kerstens P.Eng.
 
M

Michael Griffin

On May 13, 2003 15:52, Doug Panacea wrote:
<clip>
> When are PLC manufacturers going to catch up with the rest of the
> microprocessor based technology community. I am continually frustrated
> when having to use and program PLCs.
<clip>
> Is it not time the PLC manufactures get together to develop a standardised
> and dare I say open architecture, similar to what IBM did with the PC.
<clip>

IBM did not design the PC as an "open architecture". It was a closed, proprietary design that other companies cloned. Its current status arose more or less by accident.

> Something based on a PC type processor so costs are kept down and speed up
> due to the PC market. Something with an expansion bus similar to the PCI
> bus to which I/O, comms etc, cards from any manufacturer can be plugged
> into.
<clip>
> As far as the hardware goes, it
> will be no less reliable that a normal PLC, this machine is just based on a
> different architecture, an open one.
<clip>

This hardware exists - its called Compact PCI. This is a passive backplane industrial computer where the cards (including the CPU) plug into a rack. This hardware is available from multiple vendors. For an operating system you can use QNX, and for a softlogic system, you can use ISAGraf.

What you are asking for is available. However, are you sure it is what you need?


************************
Michael Griffin
London, Ont. Canada
************************
 
In a message dated 5/13/2003 4:06:02 PM Eastern Daylight Time,
Doug Panacea writes:

> When are PLC manufacturers going to catch up with the rest of the
> microprocessor based technology community. I am continually frustrated
> when having to use and program PLCs.

You're new to the list, Right? (Or I'm just too old to the list...) This has been discussed
before and may be in the archives.

< The usual beefs Java/Basic/C++ programmers have against PLC's snipped.>

I was of those opinions once. Actually, I still am, but it's tempered somewhat.

Other than the apparently self-serving reason of locking a customer in, there are several reasons, and I'll give you a few off the top of my head.

Reliability. Not just "don't stop running" reliability, but reliability in wet, dusty,
electrically noisy environments. Reliability that on I/O failure doesn't cause problems in neighboring I/O. Engineering this into a product may very well prevent you from using the newest whizbang processors.

Product Life. With CPU updates every 5 years or less, how do you maintain a system that will likely be in service over 20 years?

Determinism. Someone is counting every cycle of every instruction in the operating system to ensure that a scan is a scan is a certain amount of time and no more and probably also no less.

"Hot Updating". Many PLC applications are in liquid processing, for example, where you can't bring the system down simply to change part of the control algorithm. The programming language and operating system are designed to be able to make changes on the fly. Building this capability into a system programmed in a
multithreaded "real" OOP language with automatic variable storage and stack/heap usage is, shall we say, a challenge.

"Non-intrusive" monitoring. All (?) PLC programming systems have the capability of monitoring the state of the I/O and data tables and give you a view of the steps of your program with on/off states or data values in a graphic view.

The biggest commercial reason, of course, is fear of commoditization, which may be ultimately inevitable. Then manufacturing goes to a country where wages are the equivalent of $10 a week and domestics can't compete.

You're kidding yourself when you think "new and improved" features will be enough to keep manufacturers in business. That "new and improved" feature now makes the product not completely compatible and we move back to proprietary again, which will steer all the customers who don't need that feature away, so the developer has no way to fund the "new and improved" feature development.

Another problem is that "healthy competition" will force vendors to keep creating new models and where does that leave me, the user, if I want to use the same component in my system each time I build a new one? Eventually they'll have to drop the model I used in system 1 so I can't have it for system 50.

You can do more than simply write snotty letters, though! You're not the only one with this beef, and some PLC and I/O manufacturers have done work to connect hardened I/O to "real" computers (the above issues notwithstanding).

You can find products that can be used you way you describe (but none go so far as to create a "brick" PLC with those capabilities). But you can slap together some PC/104 boards together, for instance, with Serial or Ethernet or Parallel I/O to solid state relay rails and have what you want.

The best effort for open source control is at sourceforge.net. Look up MAT
Hold on, let me get the link...

Here it is:
http://sourceforge.net/projects/mat/

And one system that caught my eye a few years ago when I was actively looking for what you want is OpenLine controller from Grayhill:

http://www.grayhill.com/products/control_products.htm

Sixnet recently has some great looking Linux-based controllers:

http://www.sixnetio.com/html_files/products_and_groups/io_controllers.htm

So take heart, and look around. The truth is out there.

Rufus

Rufus V. Smith
Software/Hardware Design (esp. Automation)
Recently available for full, part-time, or contract work.
Contact at: [email protected]
HomePage: members.aol.com/rufusvs
 
Many of the smaller plc manufacturers have been following an IEE program standard for many years, so in theory you can transfer logic between brands that follow the standard. Sounds good in theory, don't know how it works in practice.

Ladder logic = relay logic, and that's all it was designed for, and that's all it's good for

i was using the Reliance Automax 15 years ago (now called A.B. Control Logix), was multi-threaded, multi-tasking had 3 languages, ladder, a visual control block language for math, motion and register stuff, and basic (which for some reason A.B. felt compelled to change to some scripting language)

and best of all the ladder logic only had contacts, coils, timers, and counters. although now A.B. marketing people have felt it was neccessary to put the rest of the crud back into the ladder logic, and for some reason have decided to pull a lot of features out of the control block language (but good news is they seem to have put back the stuff they pulled out) and at the same time charge a lot extra if you want to use the visual contol block stuff, and make you pay a fortune for software upgrades, which are needed when ever they decide to put the removed features back in

arrg - marketing people should be shot...
 
R

Rafael N. Jacomino

>> A particularly frustrating issue is that while a particular PLC may provide all the features one might need in a PLC, the programmer is stuck>using the manufactures programming software to programming (which is generally crap). A good point in case is the Quantum PLC, while a reasonably good PLC, the programming software is hopeless.<<

Curious that you chose the Quantum PLCs 'cause as an IT (CIS B.S.) guy "converted" to the world of control, I tell you the Quantum's IEC programming is the closest thing to “modern” programming languages you might find. Its six languages can take you from BASIC, to Pascal, to Assembly, to even today’s Booch DFD flow-chart like environments, which can compile, integrate, & run simultaneously (try doing that efficiently & deterministically in a similar-cost PC environment) with all your documentation resident in the PLC. I think you might be suffering Ladder Logic Pangs, which control engineers endure because of its familiarity & ease of trouble-shooting that it affords to the ALL-IMPORTANT process/ELE/maintenance technician (are you a permanent fixture in every system you build?). If I can have a control system that lets me use languages best suited for specific tasks while they maximize uptime & foster Continuous Improvement (no matter how clever I think I am, they never seize to amaze me with innovative out-a-the-box solutions), I’ll take it. Get a free DEMO copy of their Concept software & check it out.
 
C

Curt Wuollet

Hi Doug

Amen!

But you can do more than write letters! Help MAT/plc change the world. http://mat.sf.net
Vote with your checkbook for the most Open products available. Make it an issue with your suppliers and manufacturers, before the purchase. Turn down the more offensive examples. A good way to start is to demand Linux tools. :^).
If you want Open you have to reject the closed monopoly. If everyone on this list did a few of these things, change would occur. Quickly.

Regards

cww
 
L
PCs and PLCs are like Apples and Oranges.
If a PC (that is not directly controlling something that could be dangerous or costly) goes a foul, then at worst you've lost some data. In the other case; if a PLC (that is controlling something that could be dangerous or costly) goes a foul, then someone could get hurt or equipment could be damaged. A PLC has or should have checks to determine if it has gone a foul and take appropriate action. I will not ignore the reliability of a PLC to save money. So, As far as I am concerned, I don't want to see the PC used as a model of what a PLC should be.

The Market for PLCs is nowhere near the size of the market of the PCs. So, the PLC manufactures are looking at a limited number of units that they can sell compared to PCs. They must be able to recover their cost of development. There are a lot of man-hours put into writing a PLC Programming Software Package and testing it. I know because I've done it. PLC manufactures are in business to make money like we are. One balance is the competition between manufactures. You can't expect competitors to cooperate.

I've heard the arguments for a standardized PLC language and a common open architecture. You mention the similarity to what IBM did with the PC. Well we still have UNIX, QNX and MAC systems out there. There is no commonality there. Even with in the Windows OS we have problems with incompatibility of products. How many times have you had problems moving to a new version of Windows (NT to W2K to XP)?

For a PLC Manufacture to adopt a standard IO Bus would not be a good business decision. Other Manufacture would be able to make competing products and sell them for less. This would put them out of business. Yes it would be good for the end-users until one of the manufactures has cornered the market and starts raising the prices. It's economics.

Profibus and Device Net have not caught on and there is a lot of differences between competing manufactures.
 
C
Hi BobB
I regret to inform you that you are a victim of bad software if you find
both PCs and Ethernet unreliable. I have demonstrated and can provide
references for uptime in years for systems that depend heavily on both
in a challanging industrial environment.
I'll bet I can even guess where your bad experiences originate.

Regards
cww
 
I am very new to the PLC world but I have been doing a lot of research and I have been using new technology from Germany from Moeller. One of the reasons I went with them is because they follow the international standard for PLCs, IEC/EN 1131-1, also available in the German version as DIN 61131.

I agree there should be standards and I only support companies that follow open source standards. Check http://www.plcopen.org/ for more information...
 
Sounds as if you are fairly uneducated as to what plcs do and are required to do, as well as not very informed on the programming software that is available.

You refer to Modicon Quantum programming software as crap, when in fact their Concept software is the most IEC61131-3 compliant (open standard) software sold by any PLC manufacturer currently. I think what has happened at least in the case of the Quantum project that you did, is one of two things: Your customer required you to use old obsolete software because they are familiar with it, or you own the old obsolete software and were to cheap to upgrade to something that offers most if not all of the features that you want.

Software is not cheap, you mention PC software, but I bet you do not actually buy legally all the software you have on your pc, but instead pirate some of it, otherwise you would find that the software you purchase to run on a single pc is much more expensive than the standard PLC software. (Windows, Office, Cad, ------, etc.) This is just my opinion that I wish to express.)
 
G

Gerald Beaudoin

Reliability:
In 20 years of working with PLC's, I have never had to change a processor because of failure, and have only seen 3 outputs which failed to operate(easily corrected by switching to one of the spares) . As for PC's, I could not count the number of those that I have seen on the junk pile because of blown out motherboards or whatever because of some line surge or who knows what.

Programming:
For sure some of the programming schemes range from absolutely terrific to absolutely terrible. Hopefully the bad ones will fall by the wayside and the good ones will thrive. Personally, I take pride in writing a program which will meet the needs of the application and also fit into 16K of memory with 50% still available for future expansion. Writing programs that will fit into megabytes of memory seem to be the order of the day and I guess with the cheap availablity of memory, perhaps us "old timers" are "out of it".....I will never fail to appreciate a program which does the same job and utilises less resources!

Gerald Beaudoin
 
L

Lynn at Alist

Doug Panacea wrote:
> When are PLC manufacturers going to catch up with the rest of the
microprocessor based technology community. I am continually frustrated when
having to use and program PLCs. <

You obviously haven't been watching the market for very long. Literally dozens of small companies in the last decade have TRIED to create a better PLC using object-oriented methods and/or more open designs. But botton line is most of the buyers don't share your love of "new" and most of these innovators either go bankrupt or are still struggling along with miniscule market shares. Maybe you can help them thrive?

No doubt YOU get stuck using existing AB/SE/GE/Siem/Omron PLC because that is what you end-user demands. There are many alternative out there - go look, but don't expect your customers to understand your desire to no longer buy what they know & trust.

- Lynn
 
It is interesting to note a comment about various other solutions being available but that buyers keep going back to what they know. That is why I made the comment that I have never seen an implementation utilising the April that can be programmed in C++ and that Omron's attempt to introduce a PLC that could be programmed in a mixture of ladder and high level language appears to have failed. In fact, the Omron version only required 2 rungs of ladder, the first calling a function that was written in C where all the program resided and a rung with an end instruction.

There also seems to be a misconception that if a piece of software is IEC compliant the program can be transferred from one brand of PLC to another. NOT TRUE!!! The IEC software has a similar "look and feel" but one still requires to buy the software for each brand of PLC.
There are many reasons for this, different processors, some PLCs parallel process, different functions etc etc etc.

Interesting that we have some Concept devotees here. Hated it from the first version and never bought an upgrade. Apparently, Schneider are discontinuing it and are releasing something better later this year. My Schneider man did not even try to argue with me when I told him I hated it and why. Rather interesting. Most people I come across that have used it seem to be of the same opinion. Much prefer PL7.

I still find my main objection to IEC software is the lack of function keys. Too much drag and drop. Function blocks are really nice, if you are doing building automation or some process where you can use repeat blocks that have been tried and proven over time.

My other objection is that the IEC directive has failed to completely accomplish what it set out to do. The general look and feel is there but some brands of software have some really peculiar things about them. The last set of Siemens software I used, several years ago mind you, was pretty poor. There was an "online" screen and an "offline" screen. You could only perform "online" changes in the "offline" screen. By the time you got back to the "online" screen it had all happened and it was to late to see how your changes affected the rung. The other thing I did not like was that when you downloaded a change, the software downloaded the whole program. Stopped using online programming straight away. Too dangerous by that method.
I will probably wrinkle a few hairs from the Siemens people but don't get upset. I have not had a Siemens to program for some time and I am sure they have fixed a lot of things with their software.

The last set of Hitachi IEC type software I used had the same peculiar "online" and "offline" methodology that Siemens had. Probably written by the same software house.

Congratulations Doug on really setting the cat among the pidgeons. Whether people agree or disagree with you it is certainly the most lively debate I have seen for some time.
Regards
 
C
Of course, it must be said that standards compliant and crap aren't mutually exclusive. I can show you some crap that is very compliant,
it's just horrible to use. :^)

Regards

cww
 
C
Hi Gerald

You wouldn't believe how many I've resurrected with a Linux CD. The only bonafide MB failure I've seen in the last 5 years had water dripped on it. This wouldn't be recommended for PLCs
either. Perhaps I use them differently, but at the last job I had, the reliability was at least equal to the GE 90/30 stuff. And the GE guy will back me up on that.

Agree on the software though, bad software knows no bounds. Some of the worst lives on through heavy advertising and familiarity ( the devil you know....) I've known people who boot their systems
a couple times a week for years, just so the software will keep running. Sometimes every day. And some is just plain nasty to work with.

Regards

cww
 
S

ScienceOfficer

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.

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.

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!

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

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.

Hope this helps!

Larry Lawver Rexel / Central Florida
 
Top