i have been working with microcontrollers a lot, especially the PIC16F87x and the PIC14000 series. i have just come across plcs. to my imagination, microcontrollers can do all that plcs can do and more. also it is much easier to implement a microcontroller network than it is to implement a series of plcs, not to mention the cost. are there any reasons why plcs are prefered over microcontrollers?

You are right! you can control any proccess by your own microcontroller but there are two big diffrent

1. plc has a oprating system and user program you can chang its program easily

2. in plc,all input and outputs are scaned in each cycles each part of program is executed sepratly and simultantly but in your microcontroller you program run from first line to end when your progran in for example line10 it cannot see an input that use in forexample line20!

It might, but you have to remember that a PLC _is_ a microcontroller, with an executive and hardware that deals with many of the imperfections of the real world, like contact bounce, horrendous lead dress, noise and general cruft. This makes it much more stable, easier to apply and bulletproof. It also has a simple and well known programming paradigm, protection against ESD and modest electrical overstress and carelessness. One of my few accomplishments has been to design circuits to add these to microcontroller and PC card I/O. To make use of speeds greater than kHz requires _much_ greater care in wiring, even to the point of using transmission line techniques, differential signaling, impedance matching, etc. The heavy filtering and controlled rise and fall times that make PLC slower serve the purpose of working with long wires and high noise levels. But, provided you have a much more controlled environment and you attend to the details, a microcontroller can go way beyond what you can do with a PLC. In a big box with a couple VFDs, a motor starter or two, many feet of square dressed wiring and very questionable grounding, you would probably wish you had used the PLC.

From the programming point of view, PLC manufacturers has developed standards such as statement list, structured text, ladder, function block diagram, sequencial function chart. With this standards user can concentrate on how to make their factory work and let the PLC manufacturer doing the circuitry and programming of the microcontroller inside the PLC and do thetesting for the whole unit.

4. It should be easier for electricians to use the ladder logic representation of PLC programs.

My personal opinion is that this is true as long as you use only simple digital logic. When it comes to timers, counters and analog signal, I hate to see all the function blocks, where you have to look up and forget again what they do in detail. I prefer instruction lists and they are close to a uC's assembler code.

All the comments above are valid but for me the main advantage is relaibility and uptime. I have had experience of both PIC, 8051 etc and a wide range of PLC's. In my opinion i spent a lot of time dealing with faulty chips or dealing with some quirk on the micro. I have found PLC's to be incredibly reliable easy to use.

If i had to choose to run a massive production system there is NO way a micro would get a look in, it would be one of the Bigguns, Siemens, Rockwell, Omron etc.

Let me reply to two answers, which seem to say that something a PLC can do cannot be done with a microcontroller. A PLC is nothing but a microprocessor application.

1. It was said that a microcontroller would not see an input in line 20 that was read in line 10. That is not true. The thing is consistency, i.e. the program should "see" the same state in lines 10 and 20. The way to achieve this is to read all inputs at program start and copy the to memory. Subsequent instructions then read the memory. This is what existing PLCs do.

2. It was said that you cannot change parts of the program while running. You can: You would need an operating system or a monitor program that accepts the new instructions and stores them to free space in program memory. This system also keeps a list of addresses for each program block. These addresses must also be used to call the program blocks when running. After complete reception of the modified block, the system changes the address in the list and marks the old block as free. This is in principle how PLCs achieve this feature.

Yes, obviously. Since a PLC is simply a microprocessor with a given set of peripheral hardware, any differences are in software. There is absolutely no reason they couldn't function in an identical manner with the same or similar software/firmware as they would be identical. It's the PLC executive that does the PLC things.The corallary is: The notion that PLCs are inherently more reliable is hogwash as well. If you use the same grade of components and goodmanufacturing practices, there is no reason the results shouldn't be similar. You can't "test in" reliability, you can only weed out infant mortality and manufacturing defects. Experience does count. In short, there is nothing magical about PLCs. They are simply a highly engineered microprocessor based solution. They have beenbased on a variety of very common processors and support chips with none, as far as I know, unavailable OTS. This may well have changed in this day of inexpensive ASICs, but the principle still holds. The hardware design is driven by requirements and the modular backplane and the software design is driven by features and the need for PLC like behaviour. It can't be that difficult as there are hundreds of designs competing and few real turkeys. The biggest concern, as with most embedded designs is cost.This is not to downplay what these folks do, merely to stress that they are working engineers, not magicians and they could do the same thing for Joe Smith as Allen Bradley.

Lets not trivialize the amount of engineering man hours that have gone into the plc design as far as hardware/operating system that has made it suitable for real time control and 24/7 operation. The simple task of inserting a contact on the fly while the program is excuting has been engineered to the point where custoers do not even consider questioning whether it works or not.

Having just come off of a project where the customer was using a java based system in a micro controller that had to be re-compiled every time a change was made... well... my programmers wanted to take gas after that startup.

AB, Modicon, Siemens, Omron, etc., have hundreds of thousands of plc's in the field in all kinds of mission critical applications and have supported those products pretty well. Not to mention the fact that their products continously take advantage of newer technologies to improve their price/performanc curves. A Modicon 584 used to sell for 20K to 30K and now you can get more capabilty in a product that costs a few thousand or less.

Cetainly there are applications that require a custom solution and need to be addressed as such. We developed one for advanced process control ourselves. But if a PLC can do it, I would go there first.

> Lets not trivialize the amount of engineering man hours that have gone> into the plc design as far as hardware/operating system that has made it> suitable for real time control and 24/7 operation. The simple task of> inserting a contact on the fly while the program is excuting has been> engineered to the point where custoers do not even consider questioning> whether it works or not.

I'd be the last to trivialize the time spent in engineering these systems. In fact, what's staggering is that the time was spent by each and every company in parallel producing functional duplicates. What I was getting at is that this high standard is pretty much thenorm these days, with few exceptions, for even commodity goods. When even the cheapest WalMart TV can be expected to run until it's picture tube degrades, the standards for industrial controllers can be very high indeed.

> Having just come off of a project where the customer was using a java> based system in a micro controller that had to be re-compiled every time> a change was made...well....my programmers wanted to take gas after that> startup.>> AB, Modicon, Siemens, Omron, etc., have hundreds of thousands of plc's> in the field in all kinds of mission critical applications and have> supported those products pretty well. Not to mention the fact that their> products continously take advantage of newer technologies to improve> their price/performanc curves. A Modicon 584 used to sell for 20K to 30K> and now you can get more capabilty in a product that costs a few> thousand or less.

And comparable reliability in electronics at absurdly low commodity prices. Software is much more of an issue these days than hardware. The limitations seem to be the mechanical parts.

> Cetainly there are applications that require a custom solution and need> to be addressed as such. We developed one for advanced process control> ourselves. But if a PLC can do it, I would go there first.

I quite agree, within the scope of what the PLC does well and especially standalone applications. Once you've got a PC in the system things are a lot less clear. Even here, I agree mostly with the status quo of using them as a display only unless they are running software of comparable quality to the PLC. But with the new demands for systems integration, some functions are far better implemented on the PC and what the PLC does well isbecoming a smaller part. What we need is comparable engineering on the PC side, not simply using whatever is popular.

Yes, One BIG one. "Anybody can program a PLC"Actually a PLC _is_ a microcontroller plain and simple with the support structure to eliminate any need for engineering and experts (at least that's the sales pitch). Eventually, people figure out that, for non-trivial systems you still need engineering and experts. But, by that time they are effectively locked in. It's a very prevalent marketing method. And even when you've got the talent you really need, it's still less that that needed to roll your own. For people who can do it, raw hardware will always be much more cost effective. It's all about talent.

A microcontroller is a chip. A PLC is a finished product which happens to use a number of chips. You could use a microcontroller to built a PLC. Aperson who buys a microcontroller wants to build an electronic controller. A person who buys a PLC wants to build a machine which uses an electroniccontroller.

PLC's over Microcontrollers you ask...welll for ONE MOST Individuals id say 60% of then that use and program PLC's Prob Only Know Ladder Logic andthrowing Code at them Blows there mind..they belive Code is DUMB and useless sooo PIC and 8051 Assembly Language is a definate BRAIN buster to them..LADDER LOGIC is EASY and its simple to program a few rungs to get the job done...instead of 8051 and PIC assembly inwhich would take1000 lines to get the same task performed PID's SCALING / graphics ect...we RIP out and replace Microcontroller equipment all the time.and replace it with PLC's.

Mubeen - The reason to use PLC's over microcontrollers, is because after you leave a factory site, someone will have to maintain, backup, replace failed parts, and upgrade/add to the sytsem.

In my business, integration of automated factories and chemical processes, it is more profitable to complete the project, and move on to another large construction project. The service/support business needs more people andhas lower profit margins.

So I always put in systems where my client can take over the service themselves, or subcontact to any one of my competitors who is willing to doless profitable work.

Every system I install includes all development licenses and software, left on site as part of the deliveryables.

Do you leave a PC with the compiler at your cusotmers sites??, Can they call at least 3 different companys/consultants to get service within 24 hours?

This is why we stick to AB / Modicon / Emerson DeltaV, and for HMI... iFix and AB Panelview for 95% of our projects.

I always knew I was unique, but maybe in this case I'm uniquely qualified to answer this. I have designed and marketed micro based industrial control solutions, and I've used PLC's for more than 20 years. The last of my micro based systems were replaced as a part of a Y2K effort (remember Y2K?). I could not certify the units (which had been in service for more than 10 years) were Y2K compliant. The writer of the real time kernel I used was no longer around. While I sold a fair number of the controllers I never recouped the original development effort. Sometimes I find it really annoying to have a project cost accounting system - it'd be soo much nicer just to revel in the satisfaction of a product well done .

The PLC's I've used have these standard features:1. On line programming.2. Self documenting code (there is nothing you can write that I can't figure out).3. Modularity in the hardware structure.4. Modularity in the software design.5. Clean failure mode.6. Ability to design a strategy for failure mode.7. Self-inspecting for valid opcode during execution.8. Rigorous testing of each module to industry standards.9. Traceability of components used.10. Availability of programmer/troubleshooters on every continent.11. Availability of replacement hardware in most major centers.

Whatever you design using a micro, you can achieve items 1 to 4 with some effort. The remaining 64% are considerably harder. But that is what customers buy, a complete solution - not a micro.

Hugo Ahrens:> The PLC's I've used have these standard features:...> 2. Self documenting code (there is nothing you can write that I can't> figure out)....

No, no, no! This is a pernicious lie - pernicious, because it leads people into not documenting their stuff when they should.

Languages vary in their balance of readability and other attributes, but there is no language that would be self-documenting in any meaningfulsense. Good comments tell what a section of code does, and possibly why, and good code (in any language) tells the how.

Bad code, of course, can be written in anything.

Even figuring out whether a rung will ever activate is an NP-complete problem, so you're incorrect also on the formal level.

I second that motion... Arduino's are the hot ticket right now. The cool thing about the Arduino is that you buy one for cheap money and hook up a USB cable, install the programming package, and you are starting to program in C/C++ like environment with already written libraries for IO and commonly used devices.

I wish there were a 32 bit ARM microcontroller platform that was as easy to use as the arduino, but so far there haven't been any that have emerged that seem very strong (Please correct me if I'm wrong, I'd love to know of such a thing!). That with an RTOS, industrial 24V IO, and optional LCD would be a very, very cool little device for simple to intermediate control needs.

Ken Emmons Jr. said > (I wish there were a 32 bit ARM microcontroller platform that was as easy to use as the arduino, but so far there haven't been > any that have emerged that seem very strong (Please correct me if I'm wrong, I'd love to know of such a thing!).)

These both look interesting. I'll have to bookmark these and check them out when I get out of work. I noticed at least one with an Ethernet offering which was interesting. If they have a TCP/IP driver stack that would enable a lot of applications.

> I wish there were a 32 bit ARM microcontroller platform that was as> easy to use as the arduino

Google "Maple". Or "Iteadmaple". Cortex M3 based Arduino-like platform. A bit problematic programming tools comparing to "pure" Arduino on ATmega, but 70 MHz and the ARM architecture with the same price...

It really comes down to where you want to spend money. If you're experienced with PIC programming and can design and build the I/O interface without too much trouble, that will likely be the cheaper route. If you're in a hurry, have the money, and know how to work with them, a PLC will be faster to develop and implement, and may be easier to market if you're trying to go that direction.

Users of this site are benefiting from open source technologies,
including Linux,
PHP,
MySQL and
Apache. Be happy.
This page served by Yesod4 in the beautiful
Blackstone Valley of Massachusetts, the home of the American Industrial
Revolution.

Fortune"Nine years of ballet, asshole."
-- Shelly Long, to the bad guy after making a jump over a gorge that he
couldn't quite, in "Outrageous Fortune"

You have clicked on the "?" button for search help. To search the
site, enter your search terms in the box labeled "search the site"
and hit Enter.

Some tips for better search results...

Precede each search term with a "+", as follows:

+Modbus +TCP

Otherwise, any post with either term will match.

Use double quotes around phrases, as follows:

+"Allen Bradley" +ethernet

Otherwise, posts containing these words in separate locations will match.

To exclude a word, precede it with a "-", as follows:

+Modbus -Plus

This will return only posts containing "Modbus" but NOT containing
"Plus".

Note that common words (and, that, etc.) and words shorter than 2 characters
are automatically excluded from searches.

Your subscription request is being
processed.

You must be a Control.com member
to subscribe to threads. Please log in and try again.

If you're not already a member, consider joining. It's free,
and you can customize the content you view, as well as being
able to subscribe to threads and topics, getting new posts
delivered to your email as they appear.

Username

Password

Remember me on this computer

Select the categories for which you would like to
see messages displayed...

Applications

Application Questions and Problems

Automation Business

The Business of Automation and Control

Communications

Communications systems and equipment.

Engineering

Engineering and workplace issues.

HMI

Human-Machine Interface and SCADA.

Information

Information resources, documentation.

Languages

Programming languages.

Motion Control

Motion control, servos, steppers, etc.

Networking

Local and wide area networking in factory automation.

Open Control

Open interfaces, software and hardware

PCs in Automation

Computers in manufacturing; also hardware discussion.

PLCs

PLCs and related questions.

Power Generation

Power generation equipment control.

Process Control

Continuous process industries, DCS questions.

Sensors

Sensor technologies.

Software in Automation

Software, including programming, OS issues, etc.

You must be a Control.com member
to vote on a post. Please log in and try again.

If you're not already a member, consider joining. It's free,
and you can customize the content you view, as well as being
able to subscribe to threads and topics, getting new posts
delivered to your email as they appear.