Linux longevity (was MS 'Monopoly'?)

J

Thread Starter

Jiri Baum

Jeff Dean:
> As another person touched on - longevity is also important. I would not
> use or recommend Linux, because I do not believe it will last as the
> underdog's darling...
...
> While Linux may never fade into oblivion, I believe peoples interest and
> its use will fade. That's reason enough for me not to build an automation
> solution on top of it.

Hmm...

- With a commercial product: the product is supported as long as the author
chooses to support it. When it chooses to discontinue support (or the
company itself folds - though in the case of MS that's unlikely), there's
nothing you, as an individual user, can do about it. The software itself
will still run [*], but without the backing of its author support will
become increasingly difficult (eg finding compatible hardware).

Eventually, support becomes impossible.

- With an open-source product: the product is supported as long as anyone
chooses to support it. When no-one supports it any longer, you, as an
individual user, still have the source code and the right to hire
programmers to modify it. The software will run, but you will have to
maintain it yourself (eg drivers for new hardware).

Support becomes more expensive, but never impossible.


[*] That's assuming a traditional `sale'. If the product is leased, it will simply stop when the licence runs out (or when the central licence server shuts down, in the case of on-line licences and a folded business).

Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sourceforge.net
 
S

Sam Moore Square D Company/Groupe Shneid

Jeff Dean:
> As another person touched on - longevity is also important. I would not
> use or recommend Linux, because I do not believe it will last as the
> underdog's darling...
...
> While Linux may never fade into oblivion, I believe peoples interest and
> its use will fade. That's reason enough for me not to build an automation
> solution on top of it.


Good points Jeff.

You can go with a few people that claim that they know more than every major software company in the industry. And I am not talking about the
desktop industry. I am talking about the automation industry. Do you want to stand in line and wait for one of the good fellows that is making the next greatest Linux solution because it is "free". Or do you want to get behind a software vendor like, well, let's see every major software vendor in the automation world is providing their primary solution for NT, or do
you want to follow these good fellows on the list and bank on the "free" solution?

I remember when I was writing Linux device drivers and the only printed document was the Linux Bible. I hit a problem and I went to the "Bible" and it said that information was available later. I contact the author and he
said he didn't have time to work on it. He and I worked for universities. He said I might want to contact this other guy, but he was not sure that he was into it anymore.

I figured my problem out eventually. You can bank on these good fellows until something happens in their life like a new kid or a job change or
their current employer finds out what they are working on.

All of you freebies will do a lot better if you do a better NT. They maybe you can have a marketable product and something that people can count on being around. Right now we have just your good word.
 
R

Ranjan Acharya

As far as Linux lasting, what about the ridiculous life cycles of M$ software. NT lasted a while, 2000 was here yesterday and is already on its way out. XP will be here tomorrow and gone the day after. At least with open-source programming, you still have something to fall back on.

The life-cycles of the underlying hardware are also a problem. All the open-source programmes in the world will not help you if you cannot compile them.

I think we have to learn to live with M$ in the forefront, with two-hour life cycles and Linux in the background. The Linux kernel is also evolving.

Our customers have to learn to live with perfectly functional products that cannot be supported because the hardware or software to support them is no longer around.
 
J

Joe Jansen/ENGR/HQ/KEMET/US

Sign me up! get me the source code to NT, and I will hack on it as much (or more) than Linux!

Unfortunately, MS will not let anyone touch their code, and if I were to try to "do a better NT" I would be sued by MS. Besides, secret API function calls, NDA's and others would make this option impossible, wouldn't it?


Sam Moore Square D Company/Groupe Shneider wrote:
> All of you freebies will do a lot better if you do a better NT. They maybe you can have a marketable product and something that people can
count on being around. Right now we have just your good word.<
 
C

Curt Wuollet

Sam Moore Square D Company/Groupe Shneider wrote:
>
> Jeff Dean:
> > As another person touched on - longevity is also important. I would not
> > use or recommend Linux, because I do not believe it will last as the
> > underdog's darling...
> ...
> > While Linux may never fade into oblivion, I believe peoples interest and
> > its use will fade. That's reason enough for me not to build an automation
> > solution on top of it.
>
> Good points Jeff.
>
> You can go with a few people that claim that they know more than every
> major software company in the industry. And I am not talking about the
> desktop industry. I am talking about the automation industry. Do you want
> to stand in line and wait for one of the good fellows that is making the
> next greatest Linux solution because it is "free". Or do you want to get
> behind a software vendor like, well, let's see every major software vendor
> in the automation world is providing their primary solution for NT, or do
> you want to follow these good fellows on the list and bank on the "free"
> solution?

Believe it or not, We at the LPLC project would rather you did neither. First of all, unless you are in education or a non-profit where free
could be an imperative requirement, free in cost is not a reason for selecting our work. It is a benefit and byproduct of our operating in the
public interest and avoiding the financial pressures that tend to produce poor quality software. We also avoid any incentive to force you to upgrade or to lock you in to our project. This is in fact just about the only way that those ends could be met. Anyone who has worked at a software house knows what that is all about.

Free as in freedom is another matter, we believe that offers tremendous benefits for some types of projects and may not be relevent to others.
The type of work I do, in particular, integrating disparate systems, is nearly impossible with closed products as they support only that which
_they_ want you to do which seldom includes working with competitive product lines. We are not likely to replace a micro and a few hours
code.

Having a product that you can modify and extend and that is vendor neutral solves a lot of compatibility and interoperability issues which
are a major cause of project failures or their being deemed unfeasible or impractic The project I am finishing is a good example. Feasibility that
is limited only by your talent and imagination in combination with drastically reduced costs opens up a whole new area of applications that are simply not feasible with the proprietary model. When you have to propose that they replace almost everything to gain compatibility, you might as well stay home. If you do it anyway, the costs soon become a big issue. We would prefer that you don't sit on the sidelines and and "follow the
good fellows" or "bank on the free solution". We would prefer that you join with us to produce a solution that meets your needs so closely that
you can select it for the very best reasons.

On longevity, you will _own_ our solution and the source and it's a good bet that it will run on any PC made in the forseeable future. You have
the means to use it indefinitely. The community aspects surrounding the project means that you can access others that are interested in your
problems and willing to share solutions. It's a different model than those involving your credit card, but has been working well for other OSS projects. Working together is a better environment for support long term.

> I remember when I was writing Linux device drivers and the only printed
> document was the Linux Bible. I hit a problem and I went to the "Bible" and
> it said that information was available later. I contact the author and he
> said he didn't have time to work on it. He and I worked for universities.
> He said I might want to contact this other guy, but he was not sure that he
> was into it anymore.
>
> I figured my problem out eventually. You can bank on these good fellows
> until something happens in their life like a new kid or a job change or
> their current employer finds out what they are working on.

My current employer is deploying Linux technology as we speak. There is safety in numbers. The more "key people" we have, the less chance that
anything like that can happen. This is unlike companies that lose key people or outsource work where you can't find anybody who really knows
what you're talking about. With a modest base of involved users, the project can go on forever. Turnover at commercial companies is a much bigger problem.

> All of you freebies will do a lot better if you do a better NT. They maybe
> you can have a marketable product and something that people can count on
> being around. Right now we have just your good word.

We do have a better NT, and we are absolutely committed to treating our users better. We want to try a different way of doing things with
everyone pulling the same direction. If that makes sense to you, we can make this the best solution in automation and solve a lot of problems
with the present model. I am absolutely certain there is enough talent reading this to do that. Would you bet against it? A couple hundred
people would make that "good word" good as gold.


Regards

cww
 
Sam:
> All of you freebies will do a lot better if you do a better NT. They
> maybe you can have a marketable product and something that people can
> count on being around. Right now we have just your good word.

Well, no. You have our good word plus the source.

If you were the last person on the earth still using Linux, you'd still have the source and still have the right to hire someone to fix it for you (or fix it yourself - it's a lot of source, but it's not *that* hard).

Like I wrote, support becomes more expensive but never impossible.

If you were the last person on the earth still using NT, good luck to you.


Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sourceforge.net
 
M

Michael Griffin

At 22:02 07/07/01 -0400, you wrote:
>As far as Linux lasting, what about the ridiculous life cycles of M$
>software. NT lasted a while, 2000 was here yesterday and is already on its
>way out. XP will be here tomorrow and gone the day after.
<clip>
>Our customers have to learn to live with perfectly functional products that
>cannot be supported because the hardware or software to support them is no
>longer around.
<clip>

Rather, I think customers can tell their suppliers to take their consumer market junk and stuff it. It is simply not economic, practical, or
even (often) physically possible to rebuild control systems on machines every year or so. It is also not practical to have a machine which is not quickly repairable. Once a machine is in production, there is no excuse for requiring any control system modifications or "upgrades" for at least 10 years (or more) unless either the production process itself changes, or minor problems which were not discovered during testing and commissioning are fixed.
The above addresses typical machine controls. Computerised test systems often can't meet this target, but this is a problem that needs to be solved, not an excuse for extending the problem everywhere.

A customer buys a machine to make profits, not to aquire a continuous financial drain.


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

Ranjan Acharya

I would agree that the following would be ideal:

&lt;clip>
Rather, I think customers can tell their suppliers to take their consumer market junk and stuff it. It is simply not economic, practical, or
even (often) physically possible to rebuild control systems on machines every year or so. It is also not practical to have a machine which is not quickly repairable. Once a machine is in production, there is no excuse for requiring any control system modifications or "upgrades" for at least 10 years (or more) unless either the production process itself changes, or minor problems which were not discovered during testing and commissioning are fixed.
&lt;/clip>

But in practicality, I still have to advise customers about support obsolescence. I am not aware of any customers that have the power to change the world.
 
M

Michael Griffin

At 11:09 10/07/01 -0400, Ranjan Acharya wrote:
&lt;clip>
>But in practicality, I still have to advise customers about support
>obsolescence. I am not aware of any customers that have the power to change
>the world.
&lt;clip>

Customers don't have to change the world, they just need to take a serious look at what they are buying. If the choice is between a controller with a ten year product life cycle and one with a six month product life, the obvious choice is the one with the longer life.
This is one of the factors which for example, would make me favour a PLC over the typical soft logic systems available today. I know that even when a particular model of PLC becomes obsolete, the original manufacturer will continue to support it with comparable spare parts for many years to come. For the typical soft logic provider, critical parts of the system are completely out of their control. This means that after a certain point they can't help you, regardless of whatever good intentions they may have. I don't want to damn soft logic systems in particular, this was just an example which occurred to me.
Length of the product life cycle is one of the critical differences between the consumer and industrial markets. In the industrial market,
obsolescence is something which should happen much less often.


**********************
Michael Griffin
London, Ont. Canada
**********************
 
B
[email protected] wrote:
> As far as Linux lasting, what about the ridiculous life cycles of M$
> software. NT lasted a while, 2000 was here yesterday and is already on its
> way out. XP will be here tomorrow and gone the day after. At least with
> open-source programming, you still have something to fall back on.
>
> The life-cycles of the underlying hardware are also a problem. All the
> open-source programmes in the world will not help you if you cannot compile
> them.
>
> I think we have to learn to live with M$ in the forefront, with two-hour
> life cycles and Linux in the background. The Linux kernel is also evolving.
>
> Our customers have to learn to live with perfectly functional products that
> cannot be supported because the hardware or software to support them is no
> longer around.
>

And whats wrong with this? We have to use refrigereants that do not work real well for no good reason, that basically has made every exisitng perfectly good cooling device obsolete or in need of expensive rebuilding to remain useful. The benefits from this particular shift are dubious at best.

The same thing happened in cars. perfectly good cars that ran on leaded gas can no longer be sold forcing a major shift backwards in both fuel economy and performance, major league benefits came about because of the car thing though. cars now need far less maintenance and the pollution they spew out has dropped dramatically, possibly leading to improved quality of life for many people who live in urban areas as the air became cleaner.

The shift to "better" operating systems (whether from MS or someone else), has minimal benefits to automation people, and can be a real pain, BUT for
the rest of the computing world there are some substantial pluses. For us it is a nusiance cause we have to keep track of what software and drivers will work on what level of hardware and OS. But this is a problem with ALL software (including stuff you roll yourself).

The price of progress is that perfectly good stuff becomes obsolete long before it wears out.

Bob Peterson
 
B
I do not know what world you are living in but I know for a fact that the overwhelming majority of the control systems I have designed get changed and updated on a constant (even daily) basis. Things are added, changed, taken out. Its one of the major benefits of PLCs that you can make minor changes to improve the process as you go without requiring any nasty side effects.

This is not so of any Linux based controls. The open system is extremely closed to the end user; requiring difficult to come by, expensive and time
consuming service from the people that programmed it. At least with a name brand PLC the end user can always (at least for the forseeable future) find someone with the expertise to make the changes he wants, usually within his own plant. With an "open" Linux based system, the end user is screwed, unless he is willing to pay through the nose to have the OEM make the changes for him. I know of no cases where any end user I work with would ever allow this. These things evolve and you have to be able to change the way the thing works as you go, and in an economical and timely manner.

Think of it this way. How many experienced Linux programmers with substantial automation experience are there in the whole US? A few dozen is my guess. Maybe a hundred tops. How many people can add a time delay to a typical PLC program? A few hundred thousand perhaps? A million maybe? Do you want to be the end user relying on getting those few people that are
competent into your plant to add an alarm to the system (something any instrument tech or electrician could do in ten or fifteen minutes on a PLC based system).

It may be possible to create a small control system for a limited machine or process that might not change in ten years, but that would be rare for the kind of stuff I work on. Think about why PLCs were invented. It was strictly so that GM did not have to rewire relay panels anymore to make modifications to the way stuff worked. It has absolutely NOTHING to do with a religious crusade against Microsoft or AB.

Bob Peterson
 
C
Hi Ranjan

You haven't been listening. By supporting and using LPLC, for example you will have the first requirement for telling the more greedy and
indifferent suppliers to stuff it. Together we can make an extremely viable alternative. The other benefits are gravy as we say here. There is an immense difference between not having the power to change the world and not taking the opportunity to have it and wield it. If 30% of the folks on this list started using OSS and pushing for truly open protocols, you'ld be amazed at the changes that would happen. Since the automakers for example, have figured out that closed systems are not in their best interest, many marketing droids are working hard on how best to call closed systems open. There have been
whole cartels and industry groups founded, usually with "Open" in their name, to gain "openness" without changing the status quo.
A viable and truly open alternative would definitely empower customers to change their world. The key to change is cooperation and sharing your talent for the common good. And,even a modest installed base of energetic supporters would ensure the longevity of the project beyond
any commercial offering for the simple reason that the goals are different.

Regards

cww
 
>I do not know what world you are living in but I know for a fact that the
>overwhelming majority of the control systems I have designed get changed and
>updated on a constant (even daily) basis. Things are added, changed, taken
>out. Its one of the major benefits of PLCs that you can make minor changes
>to improve the process as you go without requiring any nasty side effects.
>
>This is not so of any Linux based controls. The open system is extremely
>closed to the end user; requiring difficult to come by, expensive and time
>consuming service from the people that programmed it. At least with a name
>brand PLC the end user can always (at least for the forseeable future) find
>someone with the expertise to make the changes he wants, usually within his
>own plant. With an "open" Linux based system, the end user is screwed,
>unless he is willing to pay through the nose to have the OEM make the changes
>for him. I know of no cases where any end user I work with would ever allow
>this. These things evolve and you have to be able to change the way the
>thing works as you go, and in an economical and timely manner.


You are right - IF Linux system will be written from the scratch for every application (what a strange idea!).

In reality, any practical and widespread Linux based control system will have several layers, some of them will be domain of dedicated highly qualified programmers and other - available to end user - will be as simple and user friendly as any script language / PLC program / or Labvie VI.

How often do you write PLC block in C ? But with good PLC you can if you have to. With Linux you can fine tune the system as deep as you need - but you do not have to. Most people will never need to go outside user-friendly layer. That is
why MAT / Linux PLC is being developed as far as I understand.

Petr
 
M

Michael Griffin

Excuse me, but somehow my comments seem to have been attributed to Mr. Acharya, and then somehow again turned around to mean the opposite of
what my point was.

I believe what I said was (and you have quoted as seen below) was that I (and no doubt most other people) do not want a system which requires regular, almost continuous "upgrades" for reasons that are unrelated to what we want the machine itself to do (i.e., not unless the production process changes in some way). I don't want to and will not "upgrade" the control
system on 200 machines every six months just to maintain some sort of nebulous "compatability" criteria derived from the commercial or consumer
markets. If you want a good example of that, have a look at the hardware requirements for "Windows-XP", and compare that to what most people
currently have.

Somehow though, you have construed this to mean that I don't like PLC style programmability, or PLCs in general, and Allen Bradley in particular. I do not see how this conclusion follows from what I said, or how they are related in any way. Can you please explain yourself, or did you somehow reply to the wrong letter as well as attribute it to the wrong person?
 
C
[email protected] wrote:
> I do not know what world you are living in but I know for a fact that the
> overwhelming majority of the control systems I have designed get changed and
> updated on a constant (even daily) basis. Things are added, changed, taken
> out. Its one of the major benefits of PLCs that you can make minor changes
> to improve the process as you go without requiring any nasty side effects.

Why would this be any different in a Linus based controls system that you program with the same languages and in the same manner?

> This is not so of any Linux based controls. The open system is extremely
> closed to the end user; requiring difficult to come by, expensive and time
> consuming service from the people that programmed it.

Again this might be true of a custom coded control system and I have done those. But LPLC for example, will use RLL and IL and ST, etc. the
same as a closed system. Why would it be any harder? The closed systems are all written in something running on something and you have been
happily ignoring that for years. If they simply told you what it was and made source code available, would that make their systems any more difficult?
Having that knowledge and access would make many more things possible and eliminate a lot of the guess work and experimentation that plague
systems that can't be completely documented or understood.

> At least with a name
> brand PLC the end user can always (at least for the forseeable future) find
> someone with the expertise to make the changes he wants, usually within his
> own plant. With an "open" Linux based system, the end user is screwed,
> unless he is willing to pay through the nose to have the OEM make the changes
> for him. I know of no cases where any end user I work with would ever allow
> this. These things evolve and you have to be able to change the way the
> thing works as you go, and in an economical and timely manner.
>
> Think of it this way. How many experienced Linux programmers with
> substantial automation experience are there in the whole US? A few dozen is
> my guess. Maybe a hundred tops. How many people can add a time delay to a
> typical PLC program? A few hundred thousand perhaps? A million maybe? Do
> you want to be the end user relying on getting those few people that are
> competent into your plant to add an alarm to the system (something any
> instrument tech or electrician could do in ten or fifteen minutes on a PLC
> based system).

See above, you misunderstand the project. A good rant wasted.

> It may be possible to create a small control system for a limited machine or
> process that might not change in ten years, but that would be rare for the
> kind of stuff I work on. Think about why PLCs were invented. It was
> strictly so that GM did not have to rewire relay panels anymore to make
> modifications to the way stuff worked. It has absolutely NOTHING to do with
> a religious crusade against Microsoft or AB.

As things get more and more complex, beyond relay replacement, knowing what's going on inside your PLC can be crucial to success. That's what we
provide. And people with the desire and the skills can go way beyond what a PLC can provide for integration and features. People who want an
appliance can use it that way. The best of both worlds.

Regards

cww
 
C
Hi Micheal

customers don't have to use PLC's either, but most people would agree that it was a change for the better. As solutions become more complex, the
PLC's limitations are becoming apparent. You can add functions like PID loops and even dsp, but soon, modeling everything as a special type of
relay becomes more limiting and difficult than a broader, more general model. Actually, PLCs are becoming sort of a hybrid including mixed signal
processing and networking and communications. Maintaining a PLC view of these complex functions often cripples their functionality and
flexibility. Having a PLC with a few general computing functions is far less flexible than having a full featured general computer with an
embedded PLC.

For example, in my case, running a PLC on the computer that I use for machine vision, HMI, communications, computation, SPC and interfacing
makes a lot more sense and costs many, many, thousands less than having a PLC as the center of the system and buying and adding all that extra
functionality. And the integration would be more involved than the whole project. This was an epiphany for me and the company. An extremely fast, very inexpensive Linux system with first class comms, networking, video facilities, and tools galore made it much easier to do the 90% of the system that wasn't logic solving. Adding The PLC function and integrating it with the rest was simple in comparison to the PLC-centric approach. And since I have been doing the machine vision,
interfacing and communications with Linux machines already for years and the reliability has been excellent, it is simply a much faster, cheaper, better way to build this system. You could do this all with Windows but since everything you do with windows is event driven and graphical, it would be much more complex and many many times larger, not to mention all the tools and add-ins you would have to purchase. And you would have to write much more of it. The great majority of what I used to do this came with the Linux distro and I'll bet I wrote less code than I would to do it with the PLC. The difference was so striking as to amaze the
powers that be and thats a good measure of the success of the project.

With some work and planning, this kind of power can be made available to non-programmers and PLC users and that would be the type of change
that is worth persuing IMHO. Done properly with standard computer facilities, It would drop in and run without change on a PC you buy 10 years from now because it's all software and ethernet and serial ports. Nothing special.

Regards

cww


Michael Griffin wrote:
>
> At 11:09 10/07/01 -0400, Ranjan Acharya wrote:
> <clip>
> >But in practicality, I still have to advise customers about support
> >obsolescence. I am not aware of any customers that have the power to change
> >the world.
> <clip>
>
> Customers don't have to change the world, they just need to take a
> serious look at what they are buying. If the choice is between a controller
> with a ten year product life cycle and one with a six month product life,
> the obvious choice is the one with the longer life.
> This is one of the factors which for example, would make me favour a
> PLC over the typical soft logic systems available today. I know that even
> when a particular model of PLC becomes obsolete, the original manufacturer
> will continue to support it with comparable spare parts for many years to
> come. For the typical soft logic provider, critical parts of the system are
> completely out of their control. This means that after a certain point they
> can't help you, regardless of whatever good intentions they may have. I
> don't want to damn soft logic systems in particular, this was just an
> example which occurred to me.

> Length of the product life cycle is one of the critical differences
> between the consumer and industrial markets. In the industrial market,
> obsolescence is something which should happen much less often.
>
 
R

Ranjan Acharya

&lt;clip>
Hi Ranjan

You haven't been listening. By supporting and using LPLC, for example...
&lt;/clip>

I would argue that the corollary is true. I think that a strong love of Linux might have blinded some of us to the commerical realities of the automation world and the practical realities of supporting a bespoke PLC with no commerical backers. It is after all, all about pounds, shillings and pence, not idealism.

I do indeed listen to the LPLC's progress (I do _not_ have time to be "involved"). Here are my points:

1. I would use LPLC if a customer asked me to. But I would point out to them that they could get stuck when the kid in Liechtenstien who wrote their [.... fill in the blanks ....] driver is on holiday (hope he has a Blackberry so that I can reach him up in the Alps).

2. I would be very keen about the LPLC when it becomes a "commerical" product with the same sort of support that A-B or Siemens (and so on)
provide (I am not implying that the A-B or Siemens support is 100% and bullet proof -- they are only human and they have to make a profit).

3. I do not have a favourite OS, PLC or anything. I work with whatever the customer asks for.

4. To put it bluntly I do not care about the "us" and "them" argument you use. We are all here to make a living. Full stop. I do not get all hot
and bothered about the fact that someone makes money from the PLCs I use for my customer.

5. I have not programmed in C / C++ for several years now. I do not plan to suddenly have to re-learn it to dissect 100 000 plus lines of (potentially poorly programmed or poorly documented) code to correct an I/O scan problem
(for example). I have made this point before, that a fixed cost is paid to A-B or Siemens or ... every year for support. Compare that with the bottomless pit of having to support the product myself if no guaranteed commercial channel is available. I like using products from companies that have been around for a while with a good installed base. I shy away from "new" and "one of" and very bespoke products.

6. I understand that you are very concerned about M$ and Linux and the monopoly (perceived, actual or otherwise) in OSs and so on. I am only
concerned that I deliver the best product with the best available technology AND the best support. I could not care less if it came from a co-operative or commercial corporation. I think that a ControlLogix PLC or TI555 PLC or SLC 5/04 PLC and so on are fairly good examples of PLCs that are being used on critical systems without major incidents. There are also highly
redundant controllers used in applications such as nuclear power that work just fine too. And, with all those products there is a guaranteed support channel.

RJ
 
R

Richard Higginbotham

>1. I would use LPLC if a customer asked me to. But I would point out to
>them that they could get stuck when the kid in Liechtenstien who wrote their
>[.... fill in the blanks ....] driver is on holiday (hope he has a
>Blackberry so that I can reach him up in the Alps).

Same thing could happen with Siemens, Allen Bradley, or Intellution (can't speak for the rest). I know, i've been there. If you haven't, just wait, you will.

>2. I would be very keen about the LPLC when it becomes a "commerical"
>product with the same sort of support that A-B or Siemens (and so on)
>provide (I am not implying that the A-B or Siemens support is 100% and
>bullet proof -- they are only human and they have to make a profit).

It will never make it to a commercial product if people don't work on it now. You will be stuck with Siemens (after they finish buying everyone else out and pitching thier products). I personally wouldn't care if it were a commercial product or not, only that someone was dedicated to providing some support and getting paid to do it. Thats perfectly reasonable. Again, in order to get that far work has to be done now, and it needs to be supported by those who will eventually benefit. No company is going to get rich doing it all by themselves with out selling the hardware to help pay for the development costs. Assuming you could raise the capitol in the first place. If its a shared effort, you have a much better chance to get a quality product. But I think you are right that there will have to be people dedicated to working on such a system ie. as day jobs.

>3. I do not have a favourite OS, PLC or anything. I work with whatever the
>customer aks for.

Yea, who cares what it costs or how well it works, we charge by the hour ;)

>4. To put it bluntly I do not care about the "us" and "them" argument you
>use. We are all here to make a living. Full stop. I do not get all hot
>and bothered about the fact that someone makes money from the PLCs I use for
>my customer.

I agree completely.

>5. I have not programmed in C / C++ for several years now. I do not plan to
>suddenly have to re-learn it to dissect 100 000 plus lines of (potentially
>poorly programmed or poorly documented) code to correct an I/O scan problem
>(for example). I have made this point before, that a fixed cost is paid to
>A-B or Siemens or ... every year for support. Compare that with the
>bottomless pit of having to support the product myself if no guaranteed
>commercial channel is available. I like using products from companies that
>have been around for a while with a good installed base. I shy away from
>"new" and "one of" and very bespoke products.

Why should you? Why not pay someone for support the way you do now. To get there you need a product and a company willing to do that work. Shouldn't be difficult once the product exists. I doubt anyone working on the Linux PLC project will object too heavily if you try to pay them for at least part of thier hard work. And if you're capable and you see your customers need a new feature, you can always add it (for a price of course) and then share that with everyone else. The company doing the support /
certification / testing will be more than happy to incorperate that feature in their next release because without continuing enhancements you have no reason to pay for thier support. The difference between what you do now and what you do in that case, is that if you don't like the company providing inadequate support you can swith companys with no cost to you and with out having to replace several million in hardware. If you need more futures that would be too much for you !
to do, I'm sure something could be aranged. Chances are there are other people might want the same thing and a person/group could be put together to work on it for you, for a price of course.

>6. I understand that you are very concerned about M$ and Linux and the
>monopoly (perceived, actual or otherwise) in OSs and so on. I am only
>concerned that I deliver the best product with the best available technology
>AND the best support. I could not care less if it came from a co-operative
>or commerical corporation. I think that a ControlLogix PLC or TI555 PLC or
>SLC 5/04 PLC and so on are fairly good examples of PLCs that are being used
>on critical systems without major incidents. There are also highly
>redundant controllers used in applications such as nuclear power that work
>just fine too. And, with all those products there is a guaranteed support
>channel.

Heh. I'm glad you brought up those controllers. Most of my automation experience has been with the TI 505 line now owned by Siemens. There are new features in the 505 PLC that I really wish were supported by APT but they're not. The better the 505 line sells, the less support Siemens provides (witness the Johnson city exodus) because they have thier own superior (read German) products they want you us to use. If we had the source to APT it wouldn't be a problem, but we don't, we're dependant on Siemens for changes. Go to the Siemens web site and ask the current 505/APT users what they think about thier current level of support and migration path to those *superior* German products.

I've seen the support the big automation companies provide and I'd much rather put more control in my and my customers hands. It would make both our jobs much easier and more efficient.

Richard Higginbotham
 
C
> I would argue that the corollary is true. I think that a strong love of
> Linux might have blinded some of us to the commerical realities of the
> automation world and the practical realities of supporting a bespoke PLC
> with no commerical backers. It is after all, all about pounds, shillings
> and pence, not idealism.

For me it's all about engineering. I am a tool maker. You wish to be a tool user. No problem.

> I do indeed listen to the LPLC's progress (I do _not_ have time to be
> "involved"). Here are my points:
>
> 1. I would use LPLC if a customer asked me to. But I would point out to
> them that they could get stuck when the kid in Liechtenstien who wrote their
> [.... fill in the blanks ....] driver is on holiday (hope he has a
> Blackberry so that I can reach him up in the Alps).

That would be true for the proprietary products where the kid in Lichtenstien is the only one who has seen the source code. In our case, many people, myself included, could help you out. This is another Red Herring. Illogical, if you understand what Open Source is about.

> 2. I would be very keen about the LPLC when it becomes a "commerical"
> product with the same sort of support that A-B or Siemens (and so on)
> provide (I am not implying that the A-B or Siemens support is 100% and
> bullet proof -- they are only human and they have to make a profit).

I have found the support of a community of concerned users and developers to be a much cheaper, easier and far less frustrating option.
There is no need to rely on a few harried individuals at a company with echelons of message takers who seek to delay you until it's someone else's shift. Again it's the essence of OSS and the community that you aren't considering. Again, Linux as an example. People who use the community
find support to be very good. People who use the commercial support model find it doesn't work very well for Linux either.

> 3. I do not have a favourite OS, PLC or anything. I work with whatever the
> customer asks for.

That's your way of doing business, I am more consultative, people ask me what the best solution is. There's certainly room for both although I find your way to be much more difficult. I have no-bid jobs where there isn't enough flexibility to let me do what I do well. The best class of customers are the ones who acknowledge your success and experience and let
you find the best approach. The worst are the ones who dictate everything and treat you as a mechanic and assembly help. The first type tend to get better, cheaper solutions. The last type tend to spend a lot of time in court. I avoid the latter type.

> 4. To put it bluntly I do not care about the "us" and "them" argument you
> use. We are all here to make a living. Full stop. I do not get all hot
> and bothered about the fact that someone makes money from the PLCs I use for
> my customer.

That's fine, I am speaking to those who do care. I beg your pardon.

> 5. I have not programmed in C / C++ for several years now. I do not plan to
> suddenly have to re-learn it to dissect 100 000 plus lines of (potentially
> poorly programmed or poorly documented) code to correct an I/O scan problem
> (for example). I have made this point before, that a fixed cost is paid to
> A-B or Siemens or ... every year for support. Compare that with the
> bottomless pit of having to support the product myself if no guaranteed
> commercial channel is available. I like using products from companies that
> have been around for a while with a good installed base. I shy away from
> "new" and "one of" and very bespoke products.

That's fine, but someone has to innovate. The ideals and principles are as important as the result. Our value is a new way of helping people
build solutions that is better for _them_ than the proprietary model. This is much more than just a download. We won't be very succesful by
commercial standards we will get 0% of your project costs. You'll just have to keep that money. By the way, we'll keep the IO scan working. If you don't want to, you probably shouldn't. We won't mind at all if you simply use it the way you use other products. Honest.

> 6. I understand that you are very concerned about M$ and Linux and the
> monopoly (perceived, actual or otherwise) in OSs and so on. I am only
> concerned that I deliver the best product with the best available technology
> AND the best support. I could not care less if it came from a co-operative
> or commerical corporation. I think that a ControlLogix PLC or TI555 PLC or
> SLC 5/04 PLC and so on are fairly good examples of PLCs that are being used
> on critical systems without major incidents. There are also highly
> redundant controllers used in applications such as nuclear power that work
> just fine too. And, with all those products there is a guaranteed support
> channel.

Yes, we read about that all the time on the list here. Our project will appeal more to those who understand and agree with what we are trying to
do. We will try to make it comfortable for those who don't also. Those who don't care, probably won't care. Right now, I am looking for those
who know there must be a better way and who want to help us create one. People who think the programmers at commercial companies are supreme
beings and that their chips and wire are golden are outside that audience. To them we simply wish to say, be patient, we mean well.

Regards

cww
 
J
Bob Peterson wrote:
> I do not know what world you are living in but
> I know for a fact that the overwhelming
> majority of the control systems I have designed
> get changed and updated on a constant (even
> daily) basis. Things are added, changed, taken
> out. Its one of the major benefits of PLCs
> that you can make minor changes to improve the
> process as you go without requiring any nasty
> side effects.

So what you're saying is that you take your application and go out and change the process. Okay, fine, so do you change the program that you use to program your PLC's daily? Nope, not hardly.

For example, I go out and add some new code to a system. I grab my trusty LM6 software (which hasn't been updated in forever -- and no, I don't have the source. And yes, it's buggy) and I add a contact here, take out a coil there.

Do you really believe that it's going to be different using a linux based PLC? So the guys over at PuffinPLC are going to lock you into
the program and keep you from editing it? Nope, not hardly.

Sure the package is going to be updated as necessary (BTW, are you running the 2.51 or 7.oh-something of Control Logix? Get my point?)


> This is not so of any Linux based controls.
> The open system is extremely closed to the end
> user; requiring difficult to come by, expensive
> and time consuming service

That's, umm, interesting logic. Even if this were true, and I require proof, how would it be different than from buying a system from Fori (for instance) and having to fly those guys out each time you wanted to tweak the process?

And we're going to end up putting their kids through college before we're finished getting the machine to run the way that we want it to.


> from the people that
> programmed it. At least with a name brand PLC
> the end user can always (at least for the
> forseeable future) find someone with the
> expertise to make the changes he wants, usually
> within his own plant. With an "open" Linux
> based system, the end user is screwed, unless
> he is willing to pay through the nose to have
> the OEM make the changes for him.

Any anecdotal evidence?

And by that I mean a *GPL'ed* program. You know, the ones that come with the source.

I'll take that form of "screwing" anytime to what I've been getting from the big players for all these years.


> I know of no cases where any end user I work
> with would ever allow this. These things
> evolve and you have to be able to change the
> way the thing works as you go, and in an
> economical and timely manner.

.... and Microsoft, AB, GE, & .... are timely? You're kidding me.

And as for allowing this to happen, they've stopped putting up with it -- it's called PuffinPLC.


> Think of it this way. How many experienced
> Linux programmers with substantial automation
> experience are there in the whole US? A few
> dozen is my guess. Maybe a hundred tops. How
> many people can add a time delay to a typical
> PLC program? A few hundred thousand perhaps?
> A million maybe? Do you want to be the end user
> relying on getting those few people that are
>
> competent into your plant to add an alarm to
> the system (something any instrument tech or
> electrician could do in ten or fifteen minutes
> on a PLC based system).

What does being a linux guru have to do with programming a PLC? Should I go out and get my MCSE to program a PLC-5?

And what makes you think that it's going to be so foreign that it's beyond an Electricians ability to comprehend?

Nobody said anything about emulating Modicon...


> Think about why PLCs were invented. It was
> strictly
> so that GM did not have to rewire relay panels
> anymore to make modifications to the way stuff
> worked. It has absolutely NOTHING to do with a
> religious crusade against Microsoft or AB.

Absolutely, but I don't think that GM ever intended for a company to spring up and hold them hostage either.

Seeing as I work for them, I know first hand what it takes to get something changed by any of the PLC makers (first, you start with a committee...).

And economical and timely, they aren't.

John
 
Top