Hi All

As you know I've been working towards a PC compatible PLC form factor processor that runs Linux. This arrived in my Inbox.

http://www.softplc.com/nr_splc4.php

Close, but it's proprietary and pretty spendy. Still it shows it can be done in a manner that should be acceptable to "NO PCs" customers. And it should establish Embedded Linux as suitable for control. It even caters to the AB crowd.

Disclaimer: I have no relationship whatsoever with the company. I just think this is a step in the right direction.

Regards

cww

 

So? What are the advantages? Can this Linux PLC also run an HMI like Wonderware or RSView without a PC? Can it datalog gigbytes of info? Can it write data to an Excel spreadsheet?

Is it an 'open' controller that can communicate using an open standard such as OPC over Ethernet? Can it operate with any brand of I/O modules? A step in what direction?

I don't really care how a PLC works or what OS it uses - so long as it does what I want reliably - and most PLCs today do just that.

Warren
http://www.pc-pid.com

 

What about Wago's industrial compact PC?

http://www.wago.com/wagoweb/documentation/758/eng_dat/d287000e.pdf

Full blown PC (video, usb, etc.) running "RT Linux embedded", whatever that means. You an either use their programming software or write your own.

I haven't tried it, but we're very happy with their other products.

-James Ingraham
Sage Automation, Inc.

 

Curt,

How about this?

http://www.wago.com/wagoweb/documentation/758/eng_dat/d287000e.pdf

List starts around $1200.00.

 

I'm not sure it really is what you have been thinking about. The link is to proprietary software running on proprietary hardware, but using an open embedded OS. I think that what you have really been thinking of is open
software on commodity hardware using an open embedded OS.

For logic hardware, use a low powered fanless mini-ITX computer, a solid state disk, and Linux. There are mini-ITX boards intended for diskless operation.

For the OS, you can use a full featured distribution (i.e. with X and KDE or Gnome) instead of a stripped down embedded version. You can use a low cost flash card to hold a "live-CD" style distribution (i.e. Knoppix) instead of a failure prone hard drive. There are tools to create your own customised ISO of this type. Compact flash cards are much cheaper than wear levelling flash drives, so this detail is rather important.

For I/O, use commodity I/O (e.g. Beckhoff) on Ethernet. Separating the logic engine from the I/O means not locking yourself into an I/O supplier. Remote I/O points also seems to be the direction proprietary PLC vendors are evolving in as well.

The big lack at the moment is an open soft logic system and programming software, but then you already know that.
--

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

 

Hi Warren.

> So? What are the advantages?

The vast power and facilities that come along with Linux. Good commms, a vast selection of languages, World Class networking, excellent text handling and messaging, in short, all the stuff that is difficult and very expensive to do with PLCs. And a great many that are impossible with the closed PLCs we have to choose from.

Can this Linux PLC also run an HMI like > Wonderware or RSView without a PC? Can it datalog gigbytes of info? > Can it write data to an Excel spreadsheet?

Yes.

> > Is it an 'open' controller that can communicate using an open > standard such as OPC over Ethernet? Can it operate with any brand of > I/O modules? A step in what direction? >

Why not? It should be able to do anything a PC can do as well as run your Ladder Logic.

Bear in mind this is not an "open" or Open controller, it's still closed. But then, OPC isn't Open by any reasonable definition. And a controller that uses MS licensed technology can never be Open. Your remark on IO is interesting as PLCs very seldom support _anyone_ elses IO. A truly Open machine would certainly be far more likely to support any given brand of IO than a competitive closed machine. The concept is to have the functionality of a PC in a PLC form factor. SoftPLC on Linux on Tealware isn't Open, but it's a step closer. And there's absolutely no reason that it couldn't be done in a similar manner with _all_ Open components.

An Open hardware design of something like this is obviously possible. I've done much of a backplane that could be packaged like that. I lack only time and money to complete it at the moment.

Linux is already Open.

And the software on top can obviously be Open as we are doing it.

> I don't really care how a PLC works or what OS it uses - so long as > it does what I want reliably - and most PLCs today do just that.

Your tone seems to belie your disinterest. But it's good you are agnostic, as this is probably the tip of an iceberg. The advantages for a vendor using Linux are fairly compelling. Think of what they get for free rather than paying for licenses, royalties, runtimes or inhouse development and maintenance costs. That's a pretty big savings.

Regards

cww

 

Yes, exactly.

I would have to check if I can run _my_ choice of software on top, but it looks just like a Wago implementation of the concept. I like the Wago products I have used too. They have had a PC product out for a while (TwinCat) but it was tied to Windows and thus not Open. But if I can write my own logic system on top of this hardware. it would come pretty close. I would consider the hardware Open enough if it came with all the info needed to write drivers and interface to other hardware. After all, I would have to use commercial chips, etc. The difference is that I would publish the schematics and any firmware so that there are no secrets. Open is being able to know what you need, or simply want, to know. I think we are going to be seeing a lot of hardware with embedded Linux and varying degrees of "Openness". More Open will prevail because there is really not much reason to buy a closed system if an Open one is available.

Regards

cww

 

There are several products out there that fully support multiple programming structure, have embedded HI and can be accessed via any computer, bring VUI, TUI to the table, have multiple comm. ports, integrated radios or GSM units and do not run a off the shelf OS such as windows or Linux, they lots of flash memory, are rugged can be Modbus master, slave, communicate DF-1, ASCII, etc... Have integrated Ethernet, serial and RS-485/422 ports and only cost $1800 to $3000. They also offer Universal inputs- (TC, RTD, 0-20ma, 0-10vdc), true DI, which accept 5 to 48vdc, AO's and relay type DO.

I believe the rest of the PLC manufactures are going to be left behind, their software is expensive, they don't allow programming in other than their own Ladder, FB or STL, do not have integrated communications and drivers and are expensive to expand the I/O, do have embedded Modbus slave or Master protocols, only speak their protocol, have limited memory (16 to 25Kbytes, vs. 16 to 120Mb). I have recommended to the company I consult for to drop their Siemens and AB PLC products and use these newer products. All the code can be written in C and transferred from one device to the next without having to translate AB ladder to Siemens Ladder. Meaning we will write the code once, build some nice front-end stuff around it and cut our development time by 60 to 70%.

PLCs are very reliable and robust; a Linux based system will do what for me? Why do I need Linux? What are the advantages? Cost considerations? Heck, I will spend less writing code in C, and putting one of these units on the air, than doing a lot of development in Linux and potential not having the product support or acceptance I presently enjoy.

Besides, will this Linux based systems meet or exceed all required standards and industry specifications? UL, CE, FM listed? Class I Div. II rated? How many special drivers do I have to write?

Sorry, but I don't think a Linux based PLC is the way to go, why do I want to run an OS on a PLC? I have PLC/RTU’s, which do not run an OS of any kind and offer all the features and functions I could want from a PLC/RTU and are accepted and listed by UL, FM and CE. Have industrial temperature. ratings, are Class I Div II certified, can be accessed from a supervisors office or home PC, which does not require any HMI software (IFix, RsView, WonderWare), all he needs is an IP address and a password. Oh, and there are no license/support agreements to contend with either.

Got Consulting?

 

We can do all of that and more of course, in Linux or Windows. No PLC required, just a box with software talking to I/O.

I don't know why those that frequent this list never mention aX. We have an object-based design, does all the tasks required by PLC or DCS, scalable and available at a very fair price. Proven with years of use too.

What's up?

Paul Jager
www.automationX.ca

 

> There are several products out there that fully support multiple
> programming structure, have embedded HI and can be accessed via any
> computer, bring VUI, TUI to the table, have multiple comm. ports,
> integrated radios or GSM units and do not run a off the shelf OS such
> as windows or Linux, they lots of flash memory, are rugged can be
> Modbus master, slave, communicate DF-1, ASCII, etc... Have integrated
> Ethernet, serial and RS-485/422 ports and only cost $1800 to $3000.
> They also offer Universal inputs- (TC, RTD, 0-20ma, 0-10vdc), true
> DI, which accept 5 to 48vdc, AO's and relay type DO. <

And each one is different and require a learning curve, tools, etc. In short you are gaining little if anything over the status quo. And you are single sourced and dependent on one vendor which gets very expensive simply beceause that's why they do it that way. An utter refusal to standardize is the root of most of the problems we see on these pages.

> I believe the rest of the PLC manufactures are going to be left
> behind, their software is expensive, they don't allow programming in
> other than their own Ladder, FB or STL, do not have integrated
> communications and drivers and are expensive to expand the I/O, do
> have embedded Modbus slave or Master protocols, only speak their
> protocol, have limited memory (16 to 25Kbytes, vs. 16 to 120Mb). I
> have recommended to the company I consult for to drop their Siemens
> and AB PLC products and use these newer products. All the code can
> be written in C and transferred from one device to the next without
> having to translate AB ladder to Siemens Ladder. Meaning we will
> write the code once, build some nice front-end stuff around it and
> cut our development time by 60 to 70%. <

Well, yes and no. C for different products is likely to be non-portable, at least without the same kind of effort to translate ladder. If those vendors were to agree to standardizing at some level over the hardware say, a standard IO map or hardware call interface this would be true. If history is any guide, I wouldn't hold my breath. Even the much touted IEC languages aren't portable in the real world.

> PLCs are very reliable and robust; a Linux based system will do what
> for me? <

Yes, it is in the plans at NASA for further mars exploration

http://www.newsforge.com/article.pl?sid=04/09/25/188215

and is currently being used hundreds of hi rel applications. As far as hardware is concerned, many current PLCs _could_ run embedded Linux so it's obviously possible to make robust hardwre for that purpose

> Why do I need Linux? What are the advantages? Cost
> considerations? Heck, I will spend less writing code in C, and
> putting one of these units on the air, than doing a lot of
> development in Linux and potential not having the product support or
> acceptance I presently enjoy. <

That is simply not true or embedded Linux wouldn't be as popular as it is. Embedded Linux is seeing stellar growth because it costs less to develop on and support. You write far less code with a complete OS than with executives or a minimalist OS. I'm not sure what these devices are that you are talking about, but give me an example and we'll
compare. My toolchain and thousands of utilities and libraries are free. And I can use the vast quantities of source already written. There is some question about the usual automation languages, but I'll guarantee I can write C for complex applications faster and cheaper on Linux. I speak from personal experience here, having developed machine vision and communications stuff on Linux with no budget.

> Besides, will this Linux based systems meet or exceed all required
> standards and industry specifications? UL, CE, FM listed? Class I
> Div. II rated? How many special drivers do I have to write? <

Those are approvals for hardware and if equipment running foo can pass them, obviously similar hardware running bar shouldn't be a problem. I haven't had to write a driver (except as an exercise) yet. But, unlike most closed systems, I _can_ write a driver without prohibitive source
licensing. And I can know exactly how each driver I do use works. This is one of the greatest advantages of OSS for automation. Huge amounts of time are spent trying to deduce how the black boxes really work and if it turns out that it doesn't do that one extra thing you need, you start over with something else. If I can get a deal on IO cards that aren't currently supported, I can find a driver that's close and change it to suit.

But the concept would be best served if hardware were somewhat stadardized as well. And explicitly documented so I could build a special card if needed. PLC busses tend to be pretty simple and one that supports the vast majority of automation needs wouldn't be rocket science. With _one_ vendor neutral bus as a target, and no licensing or secret BS needed to implement, the selection of IO and special functions that would appear would be staggering, just like the PC busses.

> Sorry, but I don't think a Linux based PLC is the way to go, why do I
> want to run an OS on a PLC? I have PLC/RTU's, which do not run an OS
> of any kind and offer all the features and functions I could want
> from a PLC/RTU and are accepted and listed by UL, FM and CE. <

They do run an OS of some kind, either home grown or licensed. And that is a cost that could be greatly reduced or eliminated.

> Have
> industrial temperature. ratings, are Class I Div II certified, can
> be accessed from a supervisors office or home PC, which does not
> require any HMI software (IFix, RsView, WonderWare), all he needs is <

The Internet was developed on UNIX. At last count there were at least a couple dozen means of remote access available at no cost and many are far more secure than what he would be using. And again, you're talking about hardware certifications. For all you know, some black boxes you use could already be running Linux under the covers. As I sit here, I can securely connect to any one of my customers, and I have been doing that for decades :^)

> an IP address and a password. Oh, and there are no license/support
> agreements to contend with either. <

You do have to fill me in on which ones those are, especially the non-licensed ones.

Regards

cww

 

Hello,

You need an OS in there to handle all the features you listed - Ethernet and other communications, multiple programming structure, HI, remote access, etc.

You may not think there's an OS in there, but *something* has to be providing the foundation for all those services. The conventional name for that something is "operating system".

Now, the vendor can start from linux and cut it down to size, or start from scratch and build up from nothing. The two approaches have different advantages and disadvantages, of course. The vendors mentioned upthread have chosen to go the former route - linux cut down to size.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

 

<clip>
> PLCs are very reliable and robust; a Linux based system will do what for
> me? Why do I need Linux? What are the advantages? Cost considerations?
> Heck, I will spend less writing code in C, and putting one of these units
> on the air, than doing a lot of development in Linux and potential not
> having the product support or acceptance I presently enjoy. <

Linux is an operating system, PLCs are a hardware plus software package. They are not equivalent. An advanced PLC could contain some form of embedded operating system (e.g. Linux), although this may not be visible to the end user.

> Besides, will this Linux based systems meet or exceed all required
> standards and industry specifications? UL, CE, FM listed? Class I Div. II
> rated? <

It is up to the system (PLC) vendor to get the appropriate certifications. This is true regardless of the embedded OS used. Most if not all of the certifications you have listed are hardware related, not software.

> How many special drivers do I have to write? <

One of the points of using a popular OS like Linux is to be able to use the drivers which have already been written.

> Sorry, but I don't think a Linux based PLC is the way to go, why do I want
> to run an OS on a PLC? I have PLC/RTU’s, which do not run an OS of any
> kind <

How do you know they don't have an OS? Is the system more or less dead until you burn your own boot EEPROMs and plug them into the board? Most complex microprocessor based devices have some form of OS. For example, all mobile (cell) phones have an OS. Do many people know (or care) what OS is in their phone? Some Motorola (among others) phones use Linux. Is this a problem for anyone?

There are two separate issues which are getting confused in this discussion. One issue is using Linux as a typical embedded OS in an otherwise proprietary system. This is nothing new, and there are already a number of industrial
products on the market which do this. This should be expected, as Linux is rapidly edging out proprietary embedded operating systems in all but a few niche markets. The OS is there to assist the product designer, not as
something for the end customer to be directly exposed to.

The other issue is "open" control systems. Putting Linux into an otherwise proprietary system does not make it "open" as it is only one piece of that system. Mr. Wuollet has confused this discussion by stating "this is what I've been talking about, kinda", while in fact what he has mainly in the past talked about has been using Linux as the supporting OS for an open soft logic system running on commodity PC hardware. This something which is very
different from the link he pointed us to in the original message.

--

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

 

Hi Paul

That's what you are here for :^)
This is an OPEN thread. What will make the difference in my view is the unbundling of hardware and software to allow multiple, arbitrary, software packages to run on PLC type hardware. If the hardware is x86 based and PC compatible, aX would certainly be an option. Or if it's not x86 based but has a Linux port, for that matter. But, I could standardize on the hardware and also run dedicated motion control software or some other system. This would allow "best of breed" solutions.

It would be great if the hardware was as well documented and understood as the PC model. It's the secrets in both hardware and software that cause a lot of the headaches.

Regards

cww

 

Hi Michael

Yes, we have come far afield. My point originally was that someone was running embedded Linux now on hardware that is a spitting image of a well known line of PLCs. This means that we could run Linux based automation software on a platform acceptable to "NO PC" type clients. This would be a larger step forward if such hardware were commoditized. And indeed, PLC hardware running embedded Linux and a suitable software application would _be_ a PLC. The MAT software will run on PCs or any suitable Linux host. My vision is to produce a completely Open PLC by designing similar PC compatable hardware to be placed in the public domain with full documentation. We have the other parts in Linux and MAT. The trick will be to get it manufactured.
or get venture capital to manufacture it. An existing SBC house could do this quite easily as it is really only a different form factor. It's a little too deep for me to do a whole PC backplane so I have been working on a backplane that accepts a PC104 processor and provides a bus that
makes plugin IO module design as simple and straightforward as possible. This has the advantage of using any PC104 processor depending on the job and makes all the PC104 analog and special function modules available. But an "all in one" design would be considerably cheaper and is the ultimate goal. I just can't fund the R&D for that out of pocket, so I'm doing what I can. The bus design can then be grafted onto a standard SBC cell. I've been hoping that someone with the means would see the potential and do the thing, but, in the meantime, the Tealware shows that it can be done. This is the context for the original post. I got off track with some of the strange statements Matt made.

Regards

cww

 

>From cww-

"More Open will prevail because there is really not much reason to buy a closed system if an Open one is available."

I'm not sure I agree with that. The story isn't over yet, but Windows still has a 90%+ share of desktop OSes, and VxWorks still out-sells embedded Linux. Eclipse is sure taking over the IDE market, but even then you have SlickEdit as a non-open option for an editor. Heck, SPARC chips are defined by an open standard, but people still pay for licenses from ARM.

I'm not convinced that "open" has a value to many (or even most) users. I think even tech-savy controls engineers aren't interested in looking at the guts of the OS or the source code of their compilers. Certainly I'm not. And while "free as in beer" has its advantages, I have no problem buying software when it provides value.

-James Ingraham
Sage Automation, Inc.

 

With regards to Mr. Wuollet's comments on hardware designs, I am of the opinion that hardware isn't the issue - the problem is software. Vendor lock-in comes from software, not from hardware. If the PLC logic engine and programming software were completely portable between hardware systems, then you could rely upon normal market competition to produce good hardware at reasonable prices.

I believe that the proper business model for your open control system would be for vendors to embed an independent open (GPL licensed) soft logic engine in their proprietary hardware. Distribution, spares, and support would come from the hardware vendors. People would be able to get whatever degree of support they were willing to pay for. This really isn't any different from the IT industry, where you can buy a server platform with complete vendor support for the open source software which runs on it.

If you become sufficiently dissatisfied with one hardware vendor, you could switch to another without having to switch programming packages. Your PLC programs would not require re-writing when moving from one hardware platform to another. You would use the same programming software in all cases.

The problem with IEC-61131-3 is that a somewhat compatible "standard" is really no standard at all. The ideal solution would be for everyone to use the *same* software - which avoids standards compatibility problems altogether. A GPL license for the logic engine and programming software would be important, as it would help prevent vendors from permanently "forking" and creating their own incompatible version. Instead, any genuinely useful improvements that they created would tend to get folded back into the main line version.

At this point in time, hardware is a red herring. Yes, the link that you pointed out shows that it is practical to design hardware with the necessary resources to support the type of software we are talking about. However, the GPL soft logic software doesn't yet exist in a form which is comparable to the proprietary offerings.

I believe that your market plan for your project should concentrate on first producing a high quality soft logic and programming system for PC based hardware (which could be diskless and fanless). Embedding it into a more traditional PLC form factor shouldn't happen until the project has settled down into a more stable form.

On October 7, 2004 23:42, Curt Wuollet wrote: <clip>
> My vision is to produce
> a completely Open PLC by designing similar PC compatable hardware to
> be placed in the public domain with full documentation. We have the
> other parts in Linux and MAT. The trick will be to get it manufactured.
> or get venture capital to manufacture it. An existing SBC house could do
> this quite easily as it is really only a different form factor.
<clip>

 

Hi James

It does depend somewhat on what you do, straightforward stuff can really be done with just about anything. It's when you try to color outside the lines or do things not forseen (or frowned upon) by the vendors that the information difference can be crucial.

Would you agree that what is not known about the proprietary gear is a major source of problems? Folks here seem to do a lot of adapting and converting and many questions ask how to use x with y or is this possible? And it seems like more people want to do more stuff that is
not supported. I think this will be key to the uptake of OSS, it may not matter to some folks, but anyone who has run into dead ends on a feature needed or wanted by a customer could really use some options. And when you need or want to integrate stuff that isn't made to be integrated, something that a lot of people seem to want to do, the (deliberate) inflexibility of proprietary stuff really gets to be a PITA.

More and more of the work out there is going to be of this nature and it would be much better to say yes than to say no or have to suggest that they throw it all away and buy all new stuff from only one vendor to be compatible. A truly Open chunk in the middle can do this, at least until vendors see the light.

Regards

cww

 

Hi Michael

> With regards to Mr. Wuollet's comments on hardware designs, I am of
> the opinion that hardware isn't the issue - the problem is software.
> Vendor lock-in comes from software, not from hardware. If the PLC
> logic engine and programming software were completely portable
> between hardware systems, then you could rely upon normal market
> competition to produce good hardware at reasonable prices. <

Agreed! As I mentioned, the people who do commodity hardware now could do this far more easily and with far more marketing muscle. The best I can hope for is to demonstrate that it's a good idea. I remember a time when PC's were anything but standardized, this is similar to where the automation hardware vendors are today. It doesn't take a rocket scientist to guess where the PC industry would be today if that had prevailed. The burning question is how to get the ball rolling.

> I believe that the proper business model for your open control system
> would be for vendors to embed an independent open (GPL licensed) soft
> logic engine in their proprietary hardware. Distribution, spares, and
> support would come from the hardware vendors. People would be able to
> get whatever degree of support they were willing to pay for. This
> really isn't any different from the IT industry, where you can buy a
> server platform with complete vendor support for the open source
> software which runs on it. <

I can get along with that since there really isn't such a thing as Open Hardware in the same sense that there is Open Source Software. It doesn't make that much difference who makes it as long as it comes with all the information you need. Since we as automation types are often working at, or just above, the hardware level, some standardization would be necessary to avoid today's chaos and realize the benefits. The drivers should be the same on any vendor's box and a standard published bus that third parties could build hardware for would be among those. The success of those ideas is self evident from the PC world. Really, what is important is that we get the benefit of those extremely successful models from the commodity world.

> If you become sufficiently dissatisfied with one hardware vendor, you
> could switch to another without having to switch programming
> packages. Your PLC programs would not require re-writing when moving
> from one hardware platform to another. You would use the same
> programming software in all cases. <

Or not, if you so choose.

> The problem with IEC-61131-3 is that a somewhat compatible "standard"
> is really no standard at all. The ideal solution would be for
> everyone to use the *same* software - which avoids standards
> compatibility problems altogether. A GPL license for the logic engine
> and programming software would be important, as it would help prevent
> vendors from permanently "forking" and creating their own
> incompatible version. Instead, any genuinely useful improvements that
> they created would tend to get folded back into the main line
> version. <

Exactly, we could all advance together to our mutual benefit.

> At this point in time, hardware is a red herring. Yes, the link that
> you pointed out shows that it is practical to design hardware with
> the necessary resources to support the type of software we are
> talking about. However, the GPL soft logic software doesn't yet exist
> in a form which is comparable to the proprietary offerings.
>
> I believe that your market plan for your project should concentrate
> on first producing a high quality soft logic and programming system
> for PC based hardware (which could be diskless and fanless).
> Embedding it into a more traditional PLC form factor shouldn't happen
> until the project has settled down into a more stable form. <

I don't disagree, but the software has gone a little beyond my poor hacker's abilities and resources. This is something I am able to contribute. And like most Open projects, it scratches my own itch. I want it to happen and I can do it. PLC hardware is far from sophisticated in it's present form, contrary to popular belief. It's really very pedestrian as far as embedded systems go. If they ever published a schematic, almost anyone could understand it. Maybe that's what the Big Secret is :^) I am well qualified to judge and I see nothing that justifies the price tag. It's commodity class hardware at spacecraft prices.

Regards

cww

 

With regards to Mr. Wuollet's comments on PLC costs - I would imagine that the manufacturing cost of PLC CPU hardware is a very small fraction of the selling cost. The majority of the cost would come from product development,
marketing, distribution, support, etc.

Part of the problem is that every manufacturer has to develop a complete product from top to bottom (hardware to software), and in a dozen or more model variations. A vendor which could simply integrate off the shelf
components would have much lower costs. A PLC CPU is really just a single board computer with a power supply in a custom case, together with a good deal of special firmware.

There is no reason why assembling PLC CPUs could not be like assembling PC computers. The problems though are two fold. The first is the lack of a commonly accepted open soft logic system that could be embedded in them. The second is the requirement for proprietary I/O interfaces. This tends to lead to the use of proprietary firmware and hardware. The use of an open logic engine and open more standard I/O interfaces would likely lead to a less vertically integrated PLC industry.

This however, doesn't mean that everyone would be building PLCs in their basement. Most people would buy them already assembled and ready to program. However, I would expect to see the industry segmented somewhat differently than it is today. I would expect to see some vendors concentrate on high volume markets, while others concentrated on more specialised applications. Specialisation would come from the use of different hardware, and from packaging additional software with the standard fare.

 

Hi Michael

Or perhaps I should use the more formal Mr.Griffin :^)

On October 14, 2004, Michael Griffin wrote:
> With regards to Mr. Wuollet's comments on PLC costs - I would imagine that the
> manufacturing cost of PLC CPU hardware is a very small fraction of the
> selling cost. The majority of the cost would come from product development,
> marketing, distribution, support, etc. <

Indeed and these are the costs that could be largely saved by using a common platform rather than each company reinventing the wheel in a functionally identical way.

> Part of the problem is that every manufacturer has to develop a complete
> product from top to bottom (hardware to software), and in a dozen or more
> model variations. A vendor which could simply integrate off the shelf
> components would have much lower costs. A PLC CPU is really just a single
> board computer with a power supply in a custom case, together with a good
> deal of special firmware.
>
> There is no reason why assembling PLC CPUs could not be like assembling PC
> computers. The problems though are two fold. The first is the lack of a
> commonly accepted open soft logic system that could be embedded in them. <

Developing for a common target with excellent PC compatibility would be much easier than rolling their own and much cheaper than buying a toolchain, etc. from a specialty house.

> The
> second is the requirement for proprietary I/O interfaces. This tends to lead
> to the use of proprietary firmware and hardware. The use of an open logic
> engine and open more standard I/O interfaces would likely lead to a less
> vertically integrated PLC industry. <

Exactly. And the "need" for proprietary interfaces is mostly lock in and financially driven anyway. Developing for a few common interfaces and protocols would save a great deal of effort on their part and a great deal of grief on our part.

> This however, doesn't mean that everyone would be building PLCs in their
> basement. Most people would buy them already assembled and ready to program.
> However, I would expect to see the industry segmented somewhat differently
> than it is today. I would expect to see some vendors concentrate on high
> volume markets, while others concentrated on more specialised applications.
> Specialisation would come from the use of different hardware, and from
> packaging additional software with the standard fare. <

The road to Hell... Everyone would promptly decide they were "special" and we would be back at square one. I thought a bit about your "hardware as a Red Herring" statement and the willingness of people to buy black boxes, mulling over just what was wrong with that picture. Here's what I came up with.

Everyone here understands _exactly_ why most customers want a wire print and usually a copy of the program. And why many will buy the tools to monitor the logic. Troubleshooting is extremely difficult to impossible
without these and your provider has you over a barrel.

Why then, do we buy PLCs and accept that we will never get a schematic, exhaustive documentation or source code. Are we that much dumber than our customers? :^) And we need them. on occasion. just as badly. Think how many problems on these pages could be answered trivially if we just had as much documentation as our customers demand.

Regards

cww