I have been going through recent posts, in the light of this announcement and it has raised a number of concerns about the way this project has been 'run' from the start.

> AN ANNOUNCEMENT FROM THE LPLC TEAM

Who are the LPLC team?

My understanding was that this was a community effort. As such that makes everybody who has contributed, and by that I mean in the wider and more important sense of the word (i.e. not just code). As far as I can determine there has been no discussion amongst the general community so I can only guess that the definition of the word team does not encompass the wider meaning of all who have contributed to this project but only the self appointed elite.

The decision to move to Sourceforge is not a bad one. The way the decision has come about says too much about the way the project 'leadership' operates and thinks. I wish you luck, I take exclusion from any decision making process literally.

I am afraid I cannot raise the enthusiasm to explain myself fully but basically working (or not) with you guys has not enhanced the usefulness of Open Source/Community Development in my eyes one bit.

I did have ideas once upon a time, before my involvement in this project, that the formattion of virtual companies and e-project teams would be an interesting and exiting way to do business. I can see that most of us are not ready for it.

> Recently, there has been growing concern within the LinuxPLC
> project and in the wider community that our continued association
> with control.com may compromise our independent, open-source
> status.

Where has this concern been evident? Again I have seen no discussions, of course this doesn't mean there haven't been any just that I haven't seen
any.

Here are a few parting shots.

As a software engineer producing applications for machine and process control, the most important thing to me is that the PLCs that I use work out
of the box, accept my application and do what is intended.

How do you prove due dilligence, when you are suppliying a system that has numerous sub-components and systems (both hardware (including firmware) and software), each of which may be supplied from a different source and may
have been developed by diverse parties who have never met and whos where abouts may be unknown? How can you show due diligence on something when
there is no clear ownership of design?

In other words why should I use your 'product' if in the event that something goes wrong the buck will necessarily stop at me. How can I sue the
person who supplied a faulty piece of softyware if it is impossible to know who wrote it?

I think Linux heads should be able to make a great deal of capital out of Microsoft's new supply model.

I have one last thing to say. This is regarding OS wars.

Computers are only a tool. A very flexible, adaptable and exiting tool, but a tool none the less. They are only any use for what can be done with them. The important thing then is the data that is stored on the computer system and the applications that generate and manipulate that data. When are we going to remove our selves from the cul de sac where the most important thing to us is the operating system that we are running these applications on?


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

This is not intended as a flame, but lawyers are the main problem in the USofA today!!
As Mark Twain said "Two lawyers will get fat in a town where one would starve."

First, I have followed the threads as a lurker and squatter for some time and agree with everything that has been done. I like it and will use it.

Second, Where should the buck stop if not with the implementer? Why do you want to sue someone else just because you don't understand it and can't make it work??

Third, I have received buggy software from Allen-Bradley, General Electric, Modicon, and every other supplier of PLCs that I have used. I started in control before Struthers Dunn brought out their first Programmable Logic Sequencer and even got bugs with it. Never have I thought of sueing a provider of software and if I did sue one of the big suppliers they would just say "you don't have the latest upgrade". oh WELL, that off my chest back to open source...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Curt:
> > AN ANNOUNCEMENT FROM THE LPLC TEAM

Mark:
> Who are the LPLC team?

> My understanding was that this was a community effort. As such that makes
> everybody who has contributed, and by that I mean in the wider and more
> important sense of the word (i.e. not just code).As far as I can
> determine there has been no discussion amongst the general community so I
> can only guess that the definition of the word team does not encompass
> the wider meaning of all who have contributed to this project but only
> the self appointed elite.

I apologise for that - unfortunately, under the circumstances I don't think I could have done anything much better. If I had brought up my concerns on the list, it would have still been a /fait accompli/, only it would have been decided by me alone.

Given that, I preferred to take my concerns to Curt and a couple of other people privately, to make sure I was not overreacting. It also allowed us to make sure the project had somewhere to go - in some ways the pragmatism of that question overrode the ideal of the general consensus.

I hope you will reconsider and join us at SourceForge. We have decided without you not out of any desire to exclude anybody, but simply because putting the question publically would have forced the issue.

Jiri
--
Jiri Baum <[email protected]>
"[Microsoft] cleverly associate the word 'open' with XML. What they don't
mention is that to see the XML file definitions for Microsoft Word, you
have to sign a file license that says you will never use the code."
-- http://www.itworld.com/Man/2685/IDG010503source2/

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Frank:
> Third, I have received buggy software from Allen-Bradley, General
> Electric, Modicon, and every other supplier of PLCs that I have used. I
> started in control before Struthers Dunn brought out their first
> Programmable Logic Sequencer and even got bugs with it. Never have I
> thought of sueing a provider of software and if I did sue one of the big
> suppliers they would just say "you don't have the latest upgrade". oh
> WELL, that off my chest back to open source...

One advantage with open source software is that, with the responsibility, you also get the power to actually do something about it. If there's a bug that's giving you trouble, you can go fix it (or have it fixed). True, that requires some skill, but so does inventing klugey workarounds.

Jiri
--
Jiri Baum <[email protected]>
"[Microsoft] cleverly associate the word 'open' with XML. What they don't
mention is that to see the XML file definitions for Microsoft Word, you
have to sign a file license that says you will never use the code."
-- http://www.itworld.com/Man/2685/IDG010503source2/

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi Mark

Mark Hutton wrote:
>
> I have been going through recent posts, in the light of this announcement
> and it has raised a number of concerns about the way this project has been
> 'run' from the start.

I take full responsibility for the way it has been "run". As this is a completely new phenomena in this market, it began as utter chaos and is
still a wide open democracy/meritocracy. To the extent that I can direct and influence that I will, but I am not the benevolent dictator of this
group because I do not have the most merit and have not produced the most code. We have better coders and I concern myself with the philosophy and publicity. When my views don't reflect those of the meritocrats I suppose I will be deposed. You might say I carry on the vision. Direction tends to be set by the folks doing the heavy lifting and if I have influence it is by their leave. That is exactly how I think this should be run at this point as that will attract good people who have ideas on how to do this. If those ideas align with the others producing the code we move faster. Others contribute where they fit and as long as they agree with the direction. In a sense it is self running because it requires the
approval of a quorum of the activists to act. What you saw was entirely consistent with that. It was not done the way I would prefer, in full public view, as the issues involved unfounded rumor and innuendo and could do damage to those who were blameless within their frame of reference. It was a perception problem and we acted to dispel any plausible theory of
influence.


>
> > AN ANNOUNCEMENT FROM THE LPLC TEAM
> >
>
> Who are the LPLC team?

In this particular case a quorum of the major/current contributors.

> My understanding was that this was a community effort. As such that makes
> everybody who has contributed, and by that I mean in the wider and more
> important sense of the word (i.e. not just code).As far as I can determine
> there has been no discussion amongst the general community so I can only
> guess that the definition of the word team does not encompass the wider
> meaning of all who have contributed to this project but only the self
> appointed elite.

See above, our reasons were just and accountable to all in the project. I will take personal responsibility for acting in this manner.

> The decision to move to Sourceforge is not a bad one. The way the decision
> has come about says too much about the way the project 'leadership' operates
> and thinks. I wish you luck, I take exclusion from any decision macking
> process literally.

Duly noted.

> I am afraid I cannot raise the enthusiasm to explain myself fully but
> basically working (or not) with you guys has not enhanced the usefulness of
> Open Source/Community Development in my eyes one bit.

Please elucidate, our shortcomings are a starting point for frank, honest and open discussion. I for one have asked many times for input to steer
around the rocks and on the problems we face. It is likely that as our makeup and conditions change, the way things happen may be more to your
liking or not.

> I did have ideas once upon a time, before my involvement in this project,
> that the formattion of virtual companies and e-project teams would be an
> interesting and exiting way to do business. I can see that most of us are
> not ready for it.

Mark, the way I see it, it may be for us to create the system and others to build businesses upon it. We have extensive evidence that mixing the two or emphasizing business over engineering produces short sighted, limited, closed solutions very much resembling the status quo. This is only my opinion, but that is the problem not the solution. I consider business instincts secondary to creativity and sound engineering at this point

> > Recently, there has been growing concern within the LinuxPLC
> > project and in the wider community that our continued association
> > with control.com may compromise our independent, open-source
> > status.
>
> Where has this concern been evident? Again I have seen no discussions, of
> course this doesn't mean there haven't been any just that I haven't seen
> any.

You saw what we saw, perhaps from a different perspective. As I may have mentioned, what is seen as synergy in business would be seen as
collusion in some circles. Both correct in their respective frame of reference and neither necessarily "wrong". We must be absolutely neutral and independent in the view of potential contributors as far as the automation frame of
reference is concerned. Our only ties are to the Open Source and Linux communities which are ambivalent to automation entities.

> Here are a few parting shots.
>
> As a software engineer producing applications for machine and process
> control, the most important thing to me is that the PLCs that I use work out
> of the box, accept my application and do what is intended.

We intend to get there, we certainly are not now, we are coming up on an alpha developer's release.

> How do you prove due dilligence, when you are suppliying a system that has
> numerous sub-components and systems (both hardware (including firmware) and
> software), each of which may be supplied from a different source and may
> have been developed by diverse parties who have never met and whos where
> abouts may be unknown? How can you show due diligence on something when
> there is no clear ownership of design?
>
> In other words why should I use your 'product' if in the event that
> something goes wrong the buck will necessarily stop at me. How can I sue the
> person who supplied a faulty piece of softyware if it is impossible to know
> who wrote it?

I suggest you read your software agreements and licenses and resolve those questions for your present situation. You have little or no recourse
now.

I would counter with the advisability of depending heavily on known unreliable software for automation and control purposes which
underwriters are derating for security and downtime. But that's a general discussion and has I believe, been covered.

> I think Linux heads should be able to make a great deal of capital out of
> Microsoft's new supply model.

We are anticipating this.

> I have one last thing to say. This is regarding OS wars.
>
> Computers are only a tool. A very flexible, adaptable and exiting tool, but
> a tool none the less. They are only any use for what can be done with them.
> The important thing then is the data that is stored on the computer system
> and the applications that generate and manipulate that data. When are we
> going to remove our selves from the cul de sac where the most important
> thing to us is the operating system that we are running these applications
> on?

I am guilty of using anything from assembler on the bare silicon to using Linux as a PLC. Both are extremes. But when you look at whole real world solutions today you see a lot of boxes to provide services better provided by one larger box running an OS designed for communications and the other things that get assembled around the PLC. It must be robust and reliable, reliable, reliable. To build these services easily and economically you must have greater access than is afforded by the OS's that I didn't choose.
The whole automation list is about the difficulties of stringing together expensive black boxes that are welded shut with indifferent support. Our project was conceived as the obvious ( to us ) solution to that larger problem with engineering taking the front seat. True Openness, greater than any alluded to by the status quo is fundamental to this plan as is avoidance of that which is well marketed but questionable engineering. We believe that the current proprietary mess is not in the best interest
of anyone but those proprietary entities. We are using the pieces that best fit our concern for the customers and the public interest. Open vs
closed, it's not a war it's a matter of who you are serving.

Regards

cww

PS We are trying to be the Babelfish :^)

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

>How can I sue the
>person who supplied a faulty piece of softyware >if it is impossible to know who wrote it?

You're not going to find any "deep pockets" to sue among volunteer contributors. If that is your concern, you need to pay the "big bucks" and
use A-B, Siemens, etc.

Accepting something free and requesting the right to sue if it isn't perfect doesn't compute with me. Is it a reflection of the sue happy society that we are fast becoming?

Tom Bullock

 

>Jiri:
> One advantage with open source software is that, with the responsibility,
> you also get the power to actually do something about it. If there's a bug
> that's giving you trouble, you can go fix it (or have it fixed). True,
that
> requires some skill, but so does inventing klugey workarounds.
>

Although (I like to think) I have plenty of skill. I don't get paid to and don't have time to fix things that are part of the black box that I am buying. If a product doesn't do what is required of it then I either don't use it or the customer (who specified it in the first place) pays a huge premium for the best work around I can give him.

I have rarely had a problem. The only time the latter has happened is when the customer spec'd an AB PLC-5 for a SIL-3 ESD system. Despite being
informed that it was not designed for the application we were forced to go ahead with it. The job would have been perfectly suited to Ge Fanuc, Triconex or Siemens, LinuxPLC wouldn't have got a look in.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

I am not planning on suing any body, but I reserve it as my right.

The designer of a given system is responsible for that system. S/he is responsible for selecting components and designing how they fit together. The designer is responsible for making sure that the components selected are right for the job and that they are being used in the way that the manufacturer of those components intended them to be. The implementor who maybe the designer, is responsible for making sure that the letter of the design is fulfilled.

Only an idiot, and I am sure that there are no idiots here, would give up the right to sue a supplier of a component that was bought in good faith, was used in the way the manufacturers intended, to utilise an advertised feature of that component, only to have that component fail in its duty. Particularly if the failure of that component results in a suit against the
aforementioned designer/implementor.

An object that is sold must be 'fit for purpose', that is the law here in the UK at least. And yes software 'manufacturers' have been succesfully sued under its aegis. In fact, if I remember correctly, there was a very interesting ruling (c1996/97) against Microsoft, when a university
proffessor sued stating that Windows 95 was 'not fit for purpose'. I can't remember much about it, except that the ruling stated that there was no
statuted of limitations on fittness for purpose (the professor had had the software for well over a year before the writ was issued), and that the UK version of the EULA was changed for the release of Win98.

In Europe, the employers are also responsible for the equipment they purchase, under the Provision And Use of Work Related Equipment. Any equipment sold has to carry a CE mark. It is unclear how the software content of such a product would be assesed.

Like most people I would preffer NOT to put myself in the situation where I can get sued. There are various ways of doing this including only using components that I understand or have a reasonable chance of understanding; components that are produced to measurable standards and have traceable paths of authority and responsibility. I prefer to purchase proven
technology and to be sure, that is what my customers want.


----- Original Message -----
From: "Frank Gross" <[email protected]>
>
> This is not intended as a flame, but lawyers are the main problem in the
> USofA today!!
> As Mark Twain said "Two lawyers will get fat in a town where one would
> starve."
>
> First, I have followed the threads as a lurker and squatter for some time
> and agree with everything that has been done. I like it and will use it.
>
> Second, Where should the buck stop if not with the implementer? Why do
you
> want to sue someone else just because you don't understand it and can't
make
> it work??

Fine, if that is the case but what about a product that doesn't do what it is supposed to do. Linux, or to make my point even more forcefully, GNU/Linux is not a single product. It is a very complex mish-mash of numerous products some more stable than others.

If I bought a PLC from Allen Bradley on the basis that an output would be held in a particular state by my application program, why should I be
accountable if it didn't. Allen Bradley have the same responsibility to me as I have to my customer.

> Third, I have received buggy software from Allen-Bradley, General
Electric,
> Modicon, and every other supplier of PLCs that I have used. I started in
> control before Struthers Dunn brought out their first Programmable Logic
> Sequencer and even got bugs with it. Never have I thought of sueing a
> provider of software and if I did sue one of the big suppliers they would
> just say "you don't have the latest upgrade". oh WELL, that off my chest
> back to open source...

The burden of proof to be sure. But software providers are continually found to be at fault. Would that I could turn round to my customer and say sorry about your plant doing a Piper Alpha but you should have installed the upgrade. There is a difference between the development software that you have and the firmware released in the actual PLC.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Mark Hutton wrote:
>
> >Jiri:
> > One advantage with open source software is that, with the responsibility,
> > you also get the power to actually do something about it. If there's a bug
> > that's giving you trouble, you can go fix it (or have it fixed). True,
> that
> > requires some skill, but so does inventing klugey workarounds.
> >
>
> Although (I like to think) I have plenty of skill. I don't get paid to and
> don't have time to fix things that are part of the black box that I am
> buying. If a product doesn't do what is required of it then I either don't
> use it or the customer (who specified it in the first place) pays a huge
> premium for the best work around I can give him.
>
> I have rarely had a problem. The only time the latter has happened is when
> the customer spec'd an AB PLC-5 for a SIL-3 ESD system. Despite being
> informed that it was not designed for the application we were forced to go
> ahead with it. The job would have been perfectly suited to Ge Fanuc,
> Triconex or Siemens, LinuxPLC wouldn't have got a look in.

Hi Mark

Sorry to butt in,

But that's the whole point. The LPLC isn't a black box. True, you can use it that way, but you can also customize it and add that one thing you need. It does depend on what you are doing. If all you need is vanilla RLL stuff any of the PLC's will do fine. I integrate systems from existing equipment. That can be very close to impossible with the PLC product lines and
certainly prohibitively expensive. ( We know, we just tried) Having a PLC with really good communications and no vendor bias saved the day. Logic was just sort of a given. The PLC's handled that fine. It's when you try to color outside the lines that regular PLC's become a liability. The
non logic part of the Linux solution was the enormous time saver. If you are an all one vendor house, no you don't need LPLC. If you want to
be confident that you can handle anything and everything that comes your way, the LPLC would be an excellent way of covering all the bases. The folks who need LPLC already know what I'm talking about and why it would be very valuable to them. If you never have any problems, stay with what you've got. If you're like the rest of us who run into walls and roadblocks and gotcha's galore, that's what we are trying to address. And the price is right too.

We can only provide the freedom, it's up to you whether you use it or not.

Regards

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

You don't have to post this if you don't want to.
I for one have long since found that avoiding lawyers is most beneficial both to the programmer and all other parties (except lawyers). As the
saying goes "you can catch more flies with sugar than with vinegar". Many software packages from top suppliers have had at least portions
misrepresented; I fault marketing and over zealous tech writers for taking the best of all possible worlds approach. I have found over the last 42 years in the control field that even the threat of suit gets the law department of a supplier involved. Nine nines of the time a telephone call or a letter to the concerned engineering department will get everything
straightened out. This I believe is the point of "Open Source" soft ware, to be able to communicate with others and solve problems quickly and mutually. Maybe I'm old and old fashioned but I still believe that almost all problems will be solved without third party intervention.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

As an additional note (I know this have been around before)
The LPLC by itself will be a product that doesn't cost anything that are open and all other such things, including "no warranty" and unsueable, but:

There is nothing preventing a company putting this code in some nice rugged hardware, put a price tag on it and sell it including warranty
and being sueable. What they get money for is the part of giving you, as an end user, someone to blame. That is part of the rights given in the GPL.

How do you think companies like red hat makes any money at all?


/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

I think some people may be missunderstanding my point (or even several of them) here.

It is interesting to note that even though I have been in on this thing from day one (though I have had a very quiet spell until recently), the most
interest I get in any of my posts is when I appear to be knocking the project.

It is not my intention to knock the project even if I do not necessaruily agree with every thing Curt and the boys say (when did you ever agree with every thing anyone said). That doesn't detract from the usefulness of the project. Mostly I am playing devils advocate and asking questions that I feel are long over due.

Personally I do not, as I say, have any intention of suing anyone. However, I sell my products and my services to customers who are in business to make money. If I sell them a product that does not fullfil the terms of their agreed requirements you can bet your life they will sue me (and that is with out getting into the area of personnel safety). The down time on a printing
press can cost from between $10,000 to $100,000 an hour, on a Gas Dehydration plant with compression into an oil well head the loss of the
train can cost $1,000,000 per day.

So, in order that I do not get sued, or if I do I can prove due dilligence, I have to have confidence in the products that I use. A risk assesment of a solution based on something with as many variables as a PC based control system based on a standard desktop operating system, on standard PC hardware is something I feel I would have difficulty accepting. I feel the same about
any SoftPLC solution.

If forced to go the SoftPLC route, well to paraphrase ' nobody ever got fired for buying Microsoft...'.

And it is not only civil suites that you have to worry about. You could end up with a criminal record and even a custodial sentence if life is lost through lack of due dilligence.

The trouble with the suggestion that the Open Source model allows problems to be fixed 'quickly and mutually' is that it is often too late when the problem appears at all. If the afforementioned printing press crashes because of a driver conflict or a process crash, it may not matter that the problem can be fixed 'quickly and mutually' because the print house has already lost money, and lots of it.

We are not talking about wordprocessors, or even PLC software development tools here we are talking about software that controls real world
manufacturing processes.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi Mark

I understand your concerns, but those concerns apply to every other bit and piece of an automation system. And while it may be comforting to think that you have recourse under the law or that buying from established vendors absolves you from responsibility, the fact is that it doesn't. The licenses and warranties I've seen specifically disclaim all disclaimable liability.

If you examine everything in this kind of detail you would quickly learn that you shouldn't do automation at all because there are risks involved
that can't be completely mitigated. That's what insurance is for.

What I am having a problem with is your implication that anything but PLC hardware has this problem and that it is somehow immune. This is especially ironic with the A-list that talks a lot about the idiosyncracies of PLC hardware including some fairly total failures that occur on a regular basis. In my plant stuff happens more often to PLC's than my Linux boxes. Should I use the more reliable of the two or the "safer" of the two?. What's the right thing to do?

You are applying a general widespread issue only to the LPLC and PC automation. This is a classic FUD technique. Something like saying "GE lightbulbs always burn out" which, while true, is misleading since everyone elses always burn out too. It's just like saying generic drugs are dangerous because Smithkline isn't there to back
them up. It is impossible to qualify or quantify any additional risk so it raises the desired fear, uncertainty and doubt without the
possibility of being refuted. Good propaganda works this way too. Since there are ever more PC automation companies and all seem to be
surviving and all started somehow I'm going to assume this is not a killer issue.

I recognize this readily because we are all being subjected to a massive, well concieved, well financed, carefully and painstakingly engineered
FUD campaign from the folks in Redmond regarding Linux. You'll notice that they stay to topics that can not be easily resolved and are more
emotional than technical. It seems we have added new features to Linux. It is now a cancer, eats intellectual property and last but not least
eats businesses like PacMan. All of which are absurd, or would be if they didn't have lots of people actually believing it. I wondered if
the timing of this was less than purely coincidental, but I have not seen anything to indicate that it was. I'm not sure why you are
spreading FUD but I do detect an undertone of anger at me or the project or ?

Incidentally, Linux is well on the way to being certified by the FAA for aircraft (which means life/safety) use. It is the only OS that can
be totally audited as all the source is available.
This is propaganda too, but there's more truth to it than the FUD :^)

So, what is your point? We should give up because we can never provide the surety that a multinational megacorporation can provide? That no one will ever use LPLC unless thay missed the FUD? That you wouldn't dare to use LPLC. That we are irrational dreamers outside of reality?
There is no solution other than that we operate in the public interest and we mean well. And that someone using LPLC needs to consider that
it is unlikely that we can be sued for giving our software away. Microsoft of course, can be sued, with less chance of success than us.

To continue this thread might I suggest possible solutions or some other constructive end?

Regards

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Mark:
> Mostly I am playing devils advocate and asking questions that I feel are
> long over due.

Fair enough.

> So, in order that I do not get sued, or if I do I can prove due
> dilligence, I have to have confidence in the products that I use. A risk
> assesment of a solution based on something with as many variables as a PC
> based control system based on a standard desktop operating system, on
> standard PC hardware is something I feel I would have difficulty
> accepting. I feel the same about any SoftPLC solution.

> If forced to go the SoftPLC route, well to paraphrase ' nobody ever got
> fired for buying Microsoft...'.

- With commercial SoftPLC systems: your options for proving due dilligence
are very limited. You can read the fine print on the products you use[*],
but you really have no way of affecting it. In the end, you simply use
them and hope for the best.

- With an Open Source SoftPLC system: you can commission a code review (or,
more likely, buy a code-reviewed version from someone). Depending on the
level of risk and the way it is apportioned between the software
component and the rest of the system, you may choose a more or less
thorough code review, with corresponding differences in cost, or you may
forgo it altogether if the risk is sufficiently small (eg a minor machine
with a hard-wired ES).

(Don't forget to have your own code reviewed while you're at it - you do
currently have your PLC code reviewed, don't you?)


By allowing you to commission additional code review (or to perform code review in-house, if you have the expertise), open source provides much
greater flexibility in the degree of confidence in the product. Where confidence is not required, this is reflected in a lower cost. Where
confidence is paramount, much greater levels can be achieved than are possible with most closed-source programs.

> The trouble with the suggestion that the Open Source model allows
> problems to be fixed 'quickly and mutually' is that it is often too late
> when the problem appears at all.

This is more with problems that surface during development and commissioning.


Jiri

[*] For instance:

(1) NATIONAL INSTRUMENTS PRODUCTS ARE NOT DESIGNED WITH COMPONENTS AND
TESTING FOR A LEVEL OF RELIABILITY SUITABLE FOR USE IN OR IN CONNECTION
WITH SURGICAL IMPLANTS OR AS CRITICAL COMPONENTS IN ANY LIFE SUPPORT
SYSTEMS WHOSE FAILURE TO PERFORM CAN REASONABLY BE EXPECTED TO CAUSE
SIGNIFICANT INJURY TO A HUMAN.

And so on, and so forth. This one from the LabVIEW manual, July 2000. Not sure what the situation is with Windows itself, but its warranty is pretty weak too.
--

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Curt Wuollet <[email protected]> writes:

> Incidentally, Linux is well on the way to being certified by the FAA
> for aircraft (which means life/safety) use. It is the only OS that can
> be totally audited as all the source is available.

I just have to nitpick here. Yes, Linux does have all the source available, but do many *BSD Unix variants, eCos and several other operating systems.

Of course this does nothing to weaken your argument against closed source operating systems.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi Dan

I _said_ it was propaganda :^)

Point well taken and apologies to the other zealots:^)

I do see license issues ahead for the BSD folks. It sounds like some commercial firms are going to use commercial variants to drive a wedge between BSD and Linux by only supporting the one they can embrace, extend, and destroy. it'll be interesting to watch what happens.

The licenses have been grouped together until now. My guess is that everyone will be familiar with the differences before too long.

Regards

cww

--
Free Tools!: Machine Automation Tools (LinuxPLC) Free, Truly Open,and Publicly
Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation and ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business and Automation to Linux.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc