PLC versus embedded control

M

Thread Starter

Marc Sinclair

I am looking for guidance, have any of the list members actually migrated from an embedded system to a PLC control? What are the considerations? I can imagine that the advantages include lower inventory, ease of programming, reliability, speed of development and the automatic standards compliance. On the down side I can imagine that the price per unit is higher, the ‘over specification” of components, the loss of spares revenue plus the perceived problem of giving away the ‘know how’

marc sinclair
 
If you have a standard control application then a PLC is the solution, provided the number of units does not get too big.

However if you are going to mass produce a control product in quantities then an embbedded controller will be the cheaper solution. You will have to do the math to find the break point.

Remember a PLC comes packaged and usually has a large support base, consisting of various communications options, drivers, distributed structures and programming utilities for ongoning maintenance and changes.

Embedded systems sound cheaper but the cost of the engineering is still to come.

My suggestion is to stick with a PLC, especially in the early cycle of the product. When the control philosophy is tried and tested and the sales start picking up, then you can do the math and consider a unique embedded solution.

I hope this helps.
 
M

Michael Griffin

Are you referring to customers who have replaced embedded computers with PLCs in existing machines, or are you referring to machine manufacturers who have changed their designs of new machines to do so?

As for "the perceived problem of giving away the know how", this is typically over rated. Very few companies have their worth tied up in one or two top secret ideas that can be hidden in an algorithm. Even fewer algorithms of this nature can be easily performed in a PLC. Generally, what makes a machine better than its competitors is the sum of many small things throughout the machine, rather than one or two hidden ideas.

--

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

My personal opinion hinges on a single factor - Cost of Ownership (or Life Cycle Cost). This, in turn, depends on how many copies of same application you need/expect over time. In other words, you can opt for a low NRE then a
relatively high recurring cost, or vice-versa. There is a break even point for each application.

Meir
 
R

robert trask

In defense of PC based control....

>If you have a standard control application then a PLC is the solution,
>provided the number of units does not get too big.

How is it the a PLC *IS* the solution? And what in the world is a 'standard
control application'? There are very capable, low cost controllers out there
that use recent Intel processors running slimmed down versions of Windows XP
(XPe)and CE. Get a PC control software such as TwinCAT, which has been around
for awhile, is an 1131 thing, has Windows nailed and guess what...you have a
scalable platform and can start developing code using standard, proven
control languages for ALL types of applications. You will never worry about
memory, speed, update rates, and most important NETWORKING - some of the many
things that have plagued almost any PLC application I have ever been a part of.

And you can even run other programs concurrently such as an HMI - on the same
processor. Boy does that save time in 'handshaking' information.

>Remember a PLC comes packaged and usually has a large support base,
>consisting of various communications options, drivers, distributed structures
>and programming utilities for ongoning maintenance and changes.

So do many PC-based software packages. And you will have far less trouble
actually getting things to communicate. And even better, you're not locked
into one particular vendor and their 'approved' sub-vendors. You pick and
choose the components that are best for you. No one company has all the best
answers. And you risk missing out on smaller companies with smart guys
designing things you need but never thought were possible.

>Embedded systems sound cheaper but the cost of the engineering is still to
>come.

I respectfully disagree. An 'embedded' system is, or should mean, a fancy way
of saying 'a PC with a small form factor and dedicated hardware that can run
off flash memory and can be feed from a 24VDC supply'. And if the automation
community would more strongly embrace IEC 61131-3, we would find that all the
tools are there. I have a store bought book on 1131 and use it extensively in
programming *any* 1131 compliant system. My favorite right now is Beckhoff
TwinCAT as it does a great job of motion control.

Please don't be afraid to learn something new. There are many new things
available that we just seem afraid of for some reason. Join the 21st century
(and stay employed).

Robert Trask, PE
Los Angeles, CA USA
[email protected]
 
C

Curt Wuollet

I agree wholeheartedly with all of this, except the Windows part. And the more I work with PLCs the firmer my conviction becomes. A lot of automation problems are cured by horsepower and real world communications. Of course, another chunk are cured by really knowing what the software does, which won't happen with TwinCat and the various WINCE flavors. They wouldn't even tell me how it works to get me to buy it :^)

Regards
cww
 
F

Frank Carney

> How is it the a PLC *IS* the solution? And what in the world is a 'standard
> control application'? There are very capable, low cost controllers out there
> that use recent Intel processors running slimmed down versions of Windows XP
> (XPe)and CE. Get a PC control software such as TwinCAT, which has been around
> for awhile, is an 1131 thing, has Windows nailed and guess what...you have a
> scalable platform and can start developing code using standard, proven
> control languages for ALL types of applications. You will never worry about
> memory, speed, update rates, and most important NETWORKING - some of the many
> things that have plagued almost any PLC application I have ever been a part of.
>
How many lines of code exist in a Windows CE based control solution? What is the scan time (repeat rate), and is it deterministic? What is the licensing per copy of CE in the field?

> And you can even run other programs concurrently such as an HMI - on the same
> processor. Boy does that save time in 'handshaking' information.

How much overhead does this incur? Does this affect the determinism?

> >Remember a PLC comes packaged and usually has a large support base,
> >consisting of various communications options, drivers, distributed structures
> >and programming utilities for ongoning maintenance and changes.
>
> So do many PC-based software packages. And you will have far less trouble
> actually getting things to communicate. And even better, you're not locked
> into one particular vendor and their 'approved' sub-vendors. You pick and
> choose the components that are best for you. No one company has all the best
> answers. And you risk missing out on smaller companies with smart guys
> designing things you need but never thought were possible.

Who do I call when card A wont work with card B running on OS C in machine D? Who is at fault? Who needs to supply the fix? The answer is E, you.

> >Embedded systems sound cheaper but the cost of the engineering is still to
> >come.
>
> I respectfully disagree. An 'embedded' system is, or should mean, a fancy way
> of saying 'a PC with a small form factor and dedicated hardware that can run
> off flash memory and can be feed from a 24VDC supply'. And if the automation
> community would more strongly embrace IEC 61131-3, we would find that all the
> tools are there. I have a store bought book on 1131 and use it extensively in
> programming *any* 1131 compliant system. My favorite right now is Beckhoff
> TwinCAT as it does a great job of motion control.
>
> Please don't be afraid to learn something new. There are many new things
> available that we just seem afraid of for some reason. Join the 21st century
> (and stay employed).

It is not that people are afraid of learning something new. It is many solutions are for companies that are afraid of losing 1 Million dollars a day because of a software glitch. PLC programming is standardized at the conceptual level. PLC vendors provide equipment that is garanteed to interoperate. This allows the integrator to concentrate on functionality rather than interoperatbility. Yes, this costs money, failure costs more.

Using a PLC versus an embedded PC or even a full size PC depends upon many factors:

-Cost per unit
-Total units to be sold
-Development costs
-Customer comfort

I have used PLCs for very large single solution systems. I have also used embedded systems for single solutions systems. Both have their place.

One other thing to consider when using a PLC versus a PC. Complexity. A PLCs firmware is an order of magnitude less complex than a PC based OS. You will also find when using a PLC that the responsiveness of the vendor to firmware problems is excellent. I doubt you will get answers quickly (or at all) for a CE firmware glitch. Remember, MS is a media company. Any perceived problems with their stuff is bad and they take forever to admit any problems.

Thanks,
Frank Carney
 
On September 26, 2003, Frank Carney wrote:
>What is the scan time (repeat rate), and is it deterministic? <

Here's where the differences start to shine. You will need to start forgetting about the very limiting 'PLC cycle times.' _You_ are in complete control of task cycles and there can be multiple cycles, all operating at different rates. No reason to have a temperature loop execute every 1ms second is there? But you sure want your synchronized motion loop in that range. I work with stuff that will go down to a 500us cycle time.

And the processing power in any computer bought these days so far outstrips what you can do with it from an industrial control standpoint including the 'sequential control', the motion control (all of it, no need to separate the processing), the interface, whatever else you want. It-just-is-not an issue. Check it out if you don't believe me. I work with this stuff everyday. It just blows my mind. I don't know the marketing info, I don't care. I just know that I am able to do things and tie things together in ways that I NEVER could with a PLC. It just took too much effort in handshaking and synchonizing and configuring and tearing my hair out.

>What is the licensing per copy of CE in the field? <

I'm sitting here looking at an embedded computer from Beckhoff. It runs CE.net, has enough hardware for a simple two axis application (including I/O). It cost a little over a thousand dollars and INCLUDED a PLC and NC runtime license. And you can download the development software (1131) from the internet at no cost. (They ask if you start developing applications for money to buy a development license).

>> And you can even run other programs concurrently such as an HMI - on the same
>> processor. Boy does that save time in 'handshaking' information.
>
> How much overhead does this incur? Does this affect the determinism? <

Again, because processors are such horses AND you have companies that know how to manipulate Windows on a fundamental level (real-time kernels) you don't much care 'bout these things like we used to.

I can set the amount of time I want the 'control' (PLC, motion) to occupy the processor, then it gives the rest to Windows and whatever other applications are running. I usually set this at 50%. I rarely see an application, no matter how stringent, that takes more than 25%, and that was on a Celeron. A PentiumIV? You could probably run 100 closed loop motions and not even reach 10%. Again, I don't know the numbers, I can just plow ahead without these things hindering what my job is, CONTROLLING THINGS.

>Who do I call when card A wont work with card B running on OS C in machine D? Who is at
>fault? Who needs to supply the fix? The answer is E, you. <

Do what I do, send it back. Buy another one from somebody else.

Robert Trask, PE
Los Angeles, CA
USA
[email protected]
 
R

robert trask

Yeah, I went through that phase. But I also listened to the arguement of "Don't worry about it, let *us* worry about how it works, you do the control and learn IEC 61131-3 and learn networking and learn motion."

I _now_ don't even sweat to allow the 'Windows Automatic Updates' on machines, production machines no less. It has never been an issue. Although this violates a big tenet of "If it works, don't change it", I think it is more
important to have access, even remote, which means allowing Windows updates, if that is your route of choice. I'm not pushing Windows. I'm pushing making the most out of the incredible processors at our fingertips. If that entails Microsoft OS, so be it.

Actually, Beckhoff several years ago sent me a link to a US patent that described how they do what they do. It went over my head in about two sentences. So it's out there.

Robert Trask, PE
Los Angeles, CA
USA
[email protected]
 
J

Joe Jansen/TECH/HQ/KEMET/US

You're a PE, and you are willing to relinquish control of your equipment to that degree?

You realize that when the updates automatically roll out, they are not in the least focused on production systems, right?

You realize that potentially proprietary information is sent back to MS in the form of MP9 and IE reporting, right?

What "access" are you gaining by leaving your system open like this, that you don't have by even taking the simple measure of turning off the auto-update?

Why are your production systems on a network that is "in the wild"?

Are you sure you understand what you are doing? Your description violates not only the "don't fix what ain't broke" tenet, but also violates _SEVERAL_ security policies and recommendations made by people that actually do know what they are doing.

How you can openly admit that you not only don't know how your stuff works, but then brag that you don't care how it works, and cite a potentially huge security risk as evidence of your enlightenment is beyond me......

--Joe Jansen
 
R

robert trask

On October 5, 2003, Joe Jansen wrote:
> You're a PE, and you are willing to relinquish control of your equipment to
>that degree? <

The PE means I have a responsibility for the health and safety of the public. A properly designed machine or system is not dependent on the control system for safety. Therefore, I can live with it.

>You realize that when the updates automatically roll out, they are not in the
>least focused on production systems, right? <

Yep, but historical precedence of my own experience and the experience of others who know a lot more than I do have proven to me that it is not an issue. Of course this is *absolutely* dependent on the company developing the
control software. The software company of choice for me knows what they are doing, has been doing it for years, has a large installed base of Windows based systems, AND is able to manipulate (a patented technique) a kernel that
controls the lower levels of Windows at the processor so machine control is outside of the OS interface. I would not do this for just anybody, but I have complete confidence in the one I work with.

And I'd be lying if I said it wasn't always on the back of my mind. But I have had absolutley no first-hand experience to date to get unduly concerned with the particular software I use.

>You realize that potentially proprietary information is sent back to MS in
>the form of MP9 and IE reporting, right? <

I help people make machines that are easily networkable with open source tools. What people do with them after that is up to them.

>What "access" are you gaining by leaving your system open like this, that you
>don't have by even taking the simple measure of turning off the auto-update? <

Again I help create a machine with connection options. What the end-user does with it after that is solely their responisbility. I run control software and do development on my own computers. I have never had a Windows Update affect any control issue, at all, ever - at least with the particular company I deal with now.

>Why are your production systems on a network that is "in the wild"? <

Who says they are in the wild? Again, I help create machines with the option of access and the option of exporting valuable manufacturing data, easily. There are many techniques to protect things which a good IT person knows. I do not; I am an electrical engineer *not* an IT professional.

>Are you sure you understand what you are doing? Your description violates
>not only the "don't fix what ain't broke" tenet, but also violates _SEVERAL_
>security policies and recommendations made by people that actually do know
>what they are doing. <

The price of progress. Thank God there are people who do understand this. Henry Ford once remarked that he didn't know much of anything, but he knew where to go find it. Sometimes I think I understand machine control - I know
I would never be the one to setup a secure network, but I _do_ have resources I trust implicitly.

And for what it is worth, I have no idea what I am doing. I constantly feel like I am running after a train that has left the station and is already going faster than I can keep up. Luckily I have met a lot of smart, gifted people
over the years - and I rely heavily on them for advice and knowledge of the technical world. And perhaps they call me from time to time asking something I might know. It's the way of the world as far as I'm concerned.

I don't understand how my car works, either. I used to, when I drove a 1968 VW beetle in high school.

>How you can openly admit that you not only don't know how your stuff works,
>but then brag that you don't care how it works, and cite a potentially huge
>security risk as evidence of your enlightenment is beyond me...... <

Per this logic I can't drive my car down the interstate because I don't know how every component in my vehicle (a device capable killing and maiming) works and affects each other. And I REALLY have no idea what goes on in the solid state devices that control the engine, brakes, etc... And when that guy at the station hooks up to my car with a computer, I have no idea what he might be downloading, or even worse uploading. Better go buy some bus tokens, oh wait, that guy probably knows less than I do. I guess I'll have to walk. Oh wait, I don't even know how my own body works. I'm in big big trouble. Yet,
I will still walk, talk, program control systems, and drive down the road despite your incredulousness.

Joe, I ask you, how can any ONE person possibly have all the knowledge needed to do _anything_ these days? It simply is not remotely possible. I take my car to a mechanic because I don't know how to fix it. I call in an IT person because I don't know the security and network tools necessary to properly protect and secure networked computers, be they a database server or a machine.

All I know, is I am able to write code to make machines work. I can do everything on a single platform. And I am able to do it with off-the-shelf hardware. That to me is remarkable. And unprecedented.

Robert Trask, PE
Los Angeles, CA
USA
 
Top