On September 11, 2002 04:40 pm, Alex Pavloff wrote:
<clip>
> I am of the firm belief that to make a project sucessful, you've got to
> spend all your working hours on it.
>
> Case in point -- your Puffin PLC project has been going since (I
> believe) December 1999, and yet you are still, according to your home
> page, in pre-alpha. Imagine what one of your developers could have done
> if he could have spent all his time on developing the
> LinuxPLC/PuffinPLC/MAT.
> Major projects cannot be done in "Spare Time".
<clip>

To change the subject slightly, you seem to have some idea of the magnitude of the job involved in writing a soft logic system. This has sparked a question in my mind about a somewhat related issue. Would you (or anyone else) have a rough idea of how many man hours is involved in writing a usable soft logic system? Assume the following:

- Ladder functionality equivalent to a typical low end PLC.
- With on-line monitoring, but no on-line programming.
- Programming software has features typical of low end PLC.
- Support only one type of I/O system.
- Assume whatever development tools and target O/S you think are suitable.
- The development personnel work on the project full time.
- No user documentation.

Also, what would you guess for ongoing development and maintenance costs once the first release is out?

I am aware of several companies which have written their own proprietary soft logic systems to control machinery which they build (they don't sell the soft logic system except as part of the machine).
I'm not a big fan of any of these because they are all different from one another, have limited (or no) support, and not a single one I have seen has any user manuals at all. Many of them also tend to cut corners on reliable
hardware to save money (but that is another issue).
An obvious risk for the customer with these ultra-proprietary systems is that if the originating company later decides they don't want to write their own software after all, you are stuck with an orphan system. It also gives you vendor "lock-in" problems which makes conventional PLCs look open (you're pretty much stuck with the original machine builder for future modifications).

I've been curious as to how much money these machine companies may have sunk into their proprietary soft logic systems. It would give me an idea as to how much weight to put on their arguements that they came up with their own
system for technology reasons, and how much of it was actually because they thought they could save money on software licenses.

I guess the type of systems I am describing above are about as opposite from open control as you can get, but it is something that exists and should be talked about.


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

 

Curt:
> > What you say may well be true. But you are putting the cart before
> > the horse. Many of these folks, Linus included, worked on the kernel
> > first, before there was any company with the money to hire them to
> > do it.

Alex:
> I am of the firm belief that to make a project sucessful, you've got
> to spend all your working hours on it.

> Case in point -- your Puffin PLC project has been going since (I
> believe) December 1999, and yet you are still, according to your home
> page, in pre-alpha.

Hmm, we should probably start thinking about changing that sometime...

I'm afraid the only part of the web page that gets regular updates is the manual (because code is useless if people don't know it's there), and the white paper.

> Imagine what one of your developers could have done if he could have
> spent all his time on developing the LinuxPLC/PuffinPLC/MAT.

On the other hand, it is well known that monetary reward is a demotivating factor in creative work. At best, it's very difficult to provide it in such a way that it doesn't interfere.

> > If I can find it, I'll post a recent study of developer
> > demographics. Most of the money seems to be going to GUI
> > development and porting.

> I would be interested in seeing this.

Would that be the EU report?

"http://floss1.infonomics.nl/finalreport/":http://floss1.infonomics.nl/finalreport/

> Linux has cannibalized market share from every other Unix-like OS on
> the market. Why? Simple -- a large amount of COMPANIES poured money
> into it.
...
> How could any one company compete against ten or so major companies
> and hundreds of little companies in effect pooling their software
> development budgets? They couldn't.

I guess that's another way of looking at it, emphasising the larger guys and de-emphasising the small ones. I suspect Curt could accept it if you added the phrase `and thousands of individuals' after the ten majors and hundreds of little companies.

> That's why the only places commercial UNIX flavors are still sucessful
> is in the far upper end of computing.

It probably won't last, that's where IBM is pouring money into Linux

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

 

Alex and all

Here's the link I promised regarding Linux/OSS
developer demographics. Jiri posted the link to
the report, the analysis here is easier reading.

"http://news.com.com/2100-1001-954929.html":http://news.com.com/2100-1001-954929.html

Doesn't sound like OSS runs on big bucks to me.

Regards

cww

 

> Alex:
> > Case in point -- your Puffin PLC project has been going since (I
> > believe) December 1999, and yet you are still, according to your home
> > page, in pre-alpha.
>
> Hmm, we should probably start thinking about changing that sometime...

Since I assume you would publicize any major use of the LinuxPLC on your page, or at least mention it in a topic on mat-devel, the lack of such an
announcement would mean that you have not deployed the LinuxPLC anywhere in the Real World. To me, this means that you haven't reached beta. Alpha/pre-alpha, whatever you want to call it -- there's nothing usable yet in the Real World. (And by Real World, I don't just mean factories -- use by people OTHER than the developers is what I'm looking for here.)

> > Imagine what one of your developers could have done if he could have
> > spent all his time on developing the LinuxPLC/PuffinPLC/MAT.
>
> On the other hand, it is well known that monetary reward is a
> demotivating factor in creative work. At best, it's very difficult to
> provide it in such a way that it doesn't interfere.

I'm not talking about caviar and a Ferrari here. I'm talking about the money needed to pay one developer, for a year, so that he can concentrate on a project. This isn't a "reward", this doesn't "interfere". Its called "I don't have to worry about looking for other jobs and can spend all the time on the things that I want to do."

> > I would be interested in seeing this.
>
> Would that be the EU report?
>
> http://floss1.infonomics.nl/finalreport/

That is indeed interesting. One of the conclusions of the developer survey
is that "Project performance and leadership is primarily a matter of professionals.."

As I've said -- products that make a significant impact on an industry (eg: the Linux kernel, gcc, Xfree86, GNOME, KDE, whatever) have developers being paid to do it. They provide the drive, coordination, and expertise needed to create a usable and quality product.

Another example: Look at "http://www.kde.org/people/people.html":http://www.kde.org/people/people.html . It shows
all the people working on KDE. Find anyone labeled "Core Developer." Look at the answer to the "Are you paid to work on KDE" questions. The answer is always yes (in some form or another).

This goes together, of course, with the other folks that range from high school students writing games for KDE to a Japanese Linux Users Group doing internationalization work.

> I guess that's another way of looking at it, emphasising the larger guys
> and de-emphasising the small ones. I suspect Curt could accept it if you
> added the phrase `and thousands of individuals' after the ten majors and
> hundreds of little companies.

Linux kernel development is highly organized in a tree-like structure with Linus Torvalds at the top, his lieutenants underneath, subsystem maintainers under that, and everyone else under them. The top people do Linux full time, and the system allows the input of individual developers or small companies to filter their way into the kernel *through* the experienced professionals.

Its organized, and led by people that get paid for doing Linux.

> > That's why the only places commercial UNIX flavors are still sucessful
> > is in the far upper end of computing.
>
> It probably won't last, that's where IBM is pouring money into Linux

There is a good chance that Linux will indeed gain the capabilities that AIX, HP-UX and Solaris have. I wouldn't make any hard plans to migrate your 5 9's system at this point though.

Alex Pavloff
Software Engineer
Eason Technology

 

> > Alex:
> > > Case in point -- your Puffin PLC project has been going since (I
> > > believe) December 1999, and yet you are still, according to your
> > > home page, in pre-alpha.

Jiri:
> > Hmm, we should probably start thinking about changing that
> > sometime...

Alex:
> Since I assume you would publicize any major use of the LinuxPLC on
> your page, or at least mention it in a topic on mat-devel, the lack of
> such an announcement would mean that you have not deployed the
> LinuxPLC anywhere in the Real World. To me, this means that you
> haven't reached beta.

No, we haven't. On the other hand, we are getting close to alpha now.
Mostly it's just a question of one of the developers actually going and
controlling a real-world thing with it. (And fixing whatever comes up.)

> Alpha/pre-alpha, whatever you want to call it -- there's nothing
> usable yet in the Real World. (And by Real World, I don't just mean
> factories -- use by people OTHER than the developers is what I'm
> looking for here.)

Yes, alpha is testing by developers, beta is testing by other people.
With open source the line can be a bit blurry, but it's still pretty obvious where it falls.

> > > Imagine what one of your developers could have done if he could
> > > have spent all his time on developing the LinuxPLC/PuffinPLC/MAT.

> > On the other hand, it is well known that monetary reward is a
> > demotivating factor in creative work. At best, it's very difficult
> > to provide it in such a way that it doesn't interfere.

> I'm not talking about caviar and a Ferrari here. I'm talking about
> the money needed to pay one developer, for a year, so that he can
> concentrate on a project. This isn't a "reward", this doesn't
> "interfere". Its called "I don't have to worry about looking for
> other jobs and can spend all the time on the things that I want to
> do."

Yes - but it's non-trivial to provide money on a true no-pressure basis.

> Linux kernel development is highly organized in a tree-like structure
> with Linus Torvalds at the top, his lieutenants underneath, subsystem
> maintainers under that, and everyone else under them. The top people
> do Linux full time, and the system allows the input of individual
> developers or small companies to filter their way into the kernel
> *through* the experienced professionals.

> Its organized, and led by people that get paid for doing Linux.

Except for Linus Torvalds himself, who has a day job hacking hardware, and probably several others.

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

 

Ralph,

I read that post too. It was more of a political/moral manifesto than a control.com topic, as you pointed out.

The post seemed to centered around the writer's perspective of capitalism. I am completely incapable of politely responding to the original post, but can't just let it go either.

Redhat, a public corporation, offers shares of stock (partial ownership) to any interested buyer. The money raised in this process is called capital. Microsoft, General Motors, Amgen,
General Electric, and Redhat all rely on capital for the same fundamental reason, they can't survive and accomplish their goals alone. Anyone who chooses to buy stock in these companies can freely exercise his ethics by selecting the
stocks from those companies that meet his specifications.

Kevin's original post was right on. As engineers, we have some "juice" that investors lack. By specifying and buying control components that conform to widely accepted,
open standards, control product suppliers can be
pushed, not shoved in the direction of better interoperablity. I see that the suppliers are well their way in doing this, and some don't even need a push.

Let me give an example (of why Kevin is right). In the US market, it is practically impossible to run an automation business without running into Allen-Bradley. AB is not my favorite supplier, but they do make some excellent products. My rule is that AB products are acceptable, but under no circumstances will I put a DH+ network in a new automation project.

Jay Kirsch

 

Martinicky, Brian wrote:
>> <snip>
>>
>> ...I remember when IEC1131 was the next great
>> standard and that PLC software would be totally transparent across
>> brands...

> True enough, but it seems to me that the initial "sputtering" of the
> IEC-1131 movement in terms of vendor neutrality has more to do with the
> scope and complexity of the problem than a lack of desire for, or
> availability of, a solution. The problem took a long time to grow, and
> it will take a long time to solve...

IEC-1131 was never intended to achive cross-platform compatibility of PLC software. "Syntax" (if we dare to call it so) of the graphic languages lead to necessity of use of an image recognition subroutine... There is a lot of PhDes in the IEC 1131-3 group. To come out of the situation with credit they must shoot themself, if the solution was a fault...

Though the myth about openness of the standard is circulated, the IEC-1131-3 group never says it.... neither in the text of the standard nor in unofficial discussions.

--
Best regards,
Vladimir mailto:[email protected]

 

> Linux has cannibalized market share from every other Unix-like OS on the
> market.

Agreed.
> Why? Simple -- a large amount of COMPANIES poured money into
> it.

You have your cause and effect backwards. The money came to Linux after people left other unices for Linux.

> The money poured into Linux went into paying developers what they
> like to do, which let them focus on their various projects, which led to
> very capable software that everyone could use. How could any one
> company compete against ten or so major companies and hundreds of little
> companies in effect pooling their software development budgets?

You'll need to ask that of the investors of Microsoft or Oracle. Those companies seem to be making lots of money.

> They
> couldn't. That's why the only places commercial UNIX flavors are still
> sucessful is in the far upper end of computing.

> When I said the BSDs, I was referring to the Free BSDs. There was no
> investment there, hence (mainly) little hardware support, and therefore,
> it wasn't nearly as useful.

Again you have it backwards. Not having the money isn't what is making BSD less successful, its the BSD license. It they were successful, they might get the money, but given the choice between GPL and BSD, most developers prefer GPL. Linux became more successful and that attracts the money.

Mark Blunier
Any opinions expressed in this message are not necessarily those of the company.

 

Hi Alex

Just one point, but it does change the
whole meaning.

Alex Pavloff wrote:
>
>>Alex:
>>
>>>Case in point -- your Puffin PLC project has been going since (I
>>believe) December 1999, and yet you are still, according to your
>>home page, in pre-alpha.
>>
>>Hmm, we should probably start thinking about changing that sometime...
>
> Since I assume you would publicize any major use of the LinuxPLC on your
> page, or at least mention it in a topic on mat-devel, the lack of such
> an announcement would mean that you have not deployed the LinuxPLC
> anywhere in the Real World. To me, this means that you haven't reached
> beta.
> Alpha/pre-alpha, whatever you want to call it -- there's nothing usable
> yet in the Real World. (And by Real World, I don't just mean factories
> -- use by people OTHER than the developers is what I'm looking for
> here.)
>
>>>Imagine what one of your developers could have done if he could have
>>
>>spent all his time on developing the LinuxPLC/PuffinPLC/MAT.
>>
>>On the other hand, it is well known that monetary reward is a
>>demotivating factor in creative work. At best, it's very difficult to
>>provide it in such a way that it doesn't interfere.
>
> I'm not talking about caviar and a Ferrari here. I'm talking about the
> money needed to pay one developer, for a year, so that he can
> concentrate on a project. This isn't a "reward", this doesn't
> "interfere". Its called "I don't have to worry about looking for other
> jobs and can spend all the time on the things that I want to do."
>
>>>I would be interested in seeing this.
>>
>>Would that be the EU report?
>>
>>http://floss1.infonomics.nl/finalreport/
>
> That is indeed interesting. One of the conclusions of the developer
> survey is that "Project performance and leadership is primarily a matter
> of professionals.."

Yes, but if you read further, the great majority are paid to do something else. Which still makes them part time OSS developers. In other words, they participate in both models.

Regards

cww

 

Alex Pavloff:
> <clip>
> > I am of the firm belief that to make a project sucessful, you've got
> > to spend all your working hours on it.
...
> > Major projects cannot be done in "Spare Time".

Michael Griffin:
> To change the subject slightly, you seem to have some idea of the
> magnitude of the job involved in writing a soft logic system. This has
> sparked a question in my mind about a somewhat related issue. Would
> you (or anyone else) have a rough idea of how many man hours is
> involved in writing a usable soft logic system? Assume the following:

> - Ladder functionality equivalent to a typical low end PLC.

If it's mnemonics, then it's very little. The actual logic is so trivial that it'll be dominated by the problem of getting them from the user into a usable form, which is not much - looking up three letter codes in a table is not a big problem. I think it took me an evening to get it roughly into shape, and another to polish. On the other hand, I knew what I was doing.

...
> - No user documentation.

Yeah, that was the problem in the first few months - just announcing it on the mailing list doesn't work, people forget. Which is why I now
insist on adding everything to the manual as soon as it's added

> I am aware of several companies which have written their own
> proprietary soft logic systems to control machinery which they build
> (they don't sell the soft logic system except as part of the machine).
...
> I've been curious as to how much money these machine companies may
> have sunk into their proprietary soft logic systems. It would give me
> an idea as to how much weight to put on their arguements that they
> came up with their own system for technology reasons, and how much of
> it was actually because they thought they could save money on software
> licenses.

It's probably a combination: if they want any customization at all, they basically have to write the the whole thing, because customization fees would be prohibitive.

This is one area where OSS will shine - it's already written, including documentation and stuff, yet it allows them to tailor the software to their machines.

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

 

Brain:
> I guess that's what I was saying. It may be just a
> terminology game, but
> I do not consider interoperability within a single company's product
> families to be true interoperability. I consider that to be lock-in
> bait.
>
Neither do I.

Brain:
>Never once have we
> considered schemes to force customers to purchase our motors/drives in
> order to purchase our controller, despite the fact that the real money
> is in the drives/motors.

Because your good guys who don't want to make more money, because you dont believe your controllers are better than the others (yep, its a trick question, but one that invariably comes up), *or* because the market won't bear it (you wont sell any drives)? I'm willing to bet the market wont bear it, even if you are good guys ;-). If it were only the case that you were
good guys, we'd be in fine until a few mergers from now when all the good guys have been replaced or retired, etc. Then as customers, we'd probably have problems...

Brain:
> possible. While it is tempting to view the lock-in phenomena as an
> evil-minded offensive strategy, my sense is that it is often
> an artifact
> of trying to create products with increased value. For example, if I
> decide to create a widget, I can choose to embrace non-proprietary,
> widely supported
> technologies in its design.

As an aside, Evil is way too strong. I don't think I've ever described any vendor as evil. Underhanded, self interested, ... a whole litany of other terms, sure, but Evil I would reserve for the fringes of our society.

Now if you have a product with increased value and you want to prove to me its not some proprietary scheme, you've got two options off the top of my head. You can demonstrate this miracle of modern science and you can publish public interfaces to it. Protocols, APIs, etc. etc. *You* don't have to make it operate with other equipment (that has nothing to do with
propreity), its keeping other people from interoperating with yours via legalese and restricting of information thats what makes it proprietary. You publish the protocol that your drive uses, thats good enough for other
people to be able to interoperate with your drive. To be fair its really a matter of degrees. If you make the source for controlling your drive available and easy to use, your product is more "open" then if you don't because you provide greater accesss to it, but basically its the flow of information that is the largest barrier.

Brian:
> True enough, but it seems to me that the initial "sputtering" of the
> IEC-1131 movement in terms of vendor neutrality has more to
> do with the
> scope and complexity of the problem than a lack of desire for, or
> availability of, a solution. The problem took a long time to grow, and
> it will take a long time to solve...

I disagree, I don't think its all that terribly complex. All you need to do is define an intermediate processor (plc) independant format, program structure, common instructions, etc. and use it. Its been done before (in the PC world for one).


Brain:
> I guess this is where our viewpoints diverge. In the OSS model, the
> nature of PLCx is really an aggregation of the source and those who
> provide the services. In other words, I assert that if I hold the keys
> to the source and rely on a 3rd party to service me by
> customizing/maintaining it for me, then when I have changed service
> providers, am I still left with PLCx? I can't help but think
> that with a
> new service provider I now have something like a PLCy, since
> the service
> provider is an integral part of PLCx. They still look like
> two different
> PLCs to me in the end...

I think you're missing out on a big part. When I download OSS, i generally just use it. I don't modify it to fit my personal taste. If I see
something that is lacking and I modify it, I would then submit it to the group responsible for it and have it merged into main developement tree.
Then we can all share the benefit of my work. Someone else can take that and expand on it. Thats how the project grows and how we all benefit, by sharing. You seem to be missing out on the sharing part, perhaps because thats not how you view product developement. None of us wants every user to have a different version of the MAT PLC, we want every one "product" that we
can all use and benefit from.

Brain:
> This a difficult concept for me, since all markets eventually evolve
> into price-competitive ones. If it's the same old stuff in a different
> box, and you know enough to make that determination, are you likely to
> shop by price at this point?

So if I sell you a box with linux in it, its the same as if it comes from RedHat right? No, but *if* we offer essentially the same services, you
*should* shop by price. Isn't that how you buy everything else? That obviously has the effect of making your job selling your services harder,
but so what. Shouldn't it be? It sounds as if you basically want to take advantage of your customers. They should buy from me no matter the price? What my competitive edge? Hmm, sounds like you might need to be a little innovative...

Brain:
> Is prospering from one's ability to create novel software mechanisms
> different from another's ability to provide service? While
> some "walls"
> are no doubt up intentionally, doesn't labeling all walls as provide
> unfair advantage to service providers over product innovators?

It really depends on what you mean by "novel software mechanisms" doesn't it. A car with a "unique ride" might be smoother on the road than any other or it may explode after the first mile. Both would probably be considered unique experiences. Its starting to sound like the old "holy grail of technology", a million lines of spagetti code noone but *you* can work on.
If you have something truely innovate that people want, whats stopping you from selling it? Now, if you have stuff thats not innovative, but you want to *sell* as innovative, you might have a problem.

We're not labeling all walls as unfair advantages. We're basically picking those wall that are most detrimental to the consumer and developers. Propriety offerings can still thrive in such a market by providing truely unique products, else they will undoubtedly fail.

Brian:
>
> At what point does creating a better mousetrap cease to be an
> opportunity to prosper from one's ability to innovate and become an
> anti-competitive plot?

Well, that would be when you make it an anti-competitive plot instead of just an opportunity to prosper. Basically, when you start ripping off your customers.

Brian:
> We differentiate on expertise, capability, and relationships with our
> customers. Getting to the right person does not take an
> involved journey
> through a winding bureaucracy. Got a problem? Here, talk to the person
> directly responsible for X...

Sounds like you have services to offer that could make you stand out from the crowd. Expertise would seem to be another big draw when looking as OSS, but theres a lot of ways (but may require more effort).

No one said it would be easy, its not intended to be. Thats the whole point really, to make the people with the "products" work a little harder for the rest of us. If you have to spend more time trying to be "innovative", what is the loss to us? We're trying to tip the balance between consumers and vendors to be a littl more favorible to us. We know some of you may not
make it (though the way things are going lately, thats not so radical), but we're sure those who do will be all the better for the experience.

regards,

Richard Higginbotham

 

Jiri Baum wrote:

> > Its organized, and led by people that get paid for doing Linux.
>
> Except for Linus Torvalds himself, who has a day job hacking hardware,
> and probably several others.

I don't think Linus actually does any microprocessor work at Transmeta. I think Transmeta hired him for the name. They hired him in 1999, had him do a PILE of interviews, and he got rich on the IPO. Good for him, but I am
unable to find any thing on the internet that actually details what Linus does for a job. Quite frankly, judging by when he posts to the Linux kernel mailing list (in the daytime during the week), I find it hard to believe that he could be doing any sort of irreplaceable work on trying to salvage Transmeta's failing chip biz.

As for the "several" others, lets see:

Alan Cox: paid by Red Hat
Igno Molnar: paid by Red Hat
...
and there are more. As I've said three time now, there is a core group of Linux developers paid to work on Linux. Yes, they work for different
companies and have different goals, but these paid developers are required to keep the 300,000 lines of Linux kernel source stable and feature rich. (There's a whole other debate there about whether or not they can keep it up).

And as stated earlier, look at who does the core work for GCC (arguuably MORE complex than a kernel), and who does the core for for KDE and GNOME... all paid people.

Volunteers are great, but like all volunteer organizations, you need some place where people are paid to keep the thing on track if you want to
actually get things done.

Alex Pavloff
Software Engineer
Eason Technology

 

Michael Griffin wrote:
> To change the subject slightly, you seem to have some idea of the
> magnitude of the job involved in writing a soft logic system. This has
> sparked a question in my mind about a somewhat related issue.
> Would you (or anyone else) have a rough idea of how many man hours is
> involved in writing a usable soft logic system? Assume the following:
>
> - Ladder functionality equivalent to a typical low end PLC.
> - With on-line monitoring, but no on-line programming.
> - Programming software has features typical of low end PLC.
> - Support only one type of I/O system.
> - Assume whatever development tools and target O/S you think are
suitable.
> - The development personnel work on the project full time.
> - No user documentation.

You know what's funny? I HAVE this system. There was a company called Controlware (bought by Allen Bradley and then killed) that did a soft logic engine that could run ladder under DOS and fit in a nice small system. Their documentation was alright, but they were too busy to support me
(working on the Next Big Thing), and as a result, I've got bugs that I can't find or fix. The system is usable, but I'm using some of the more "exotic" features that they threw in there, and those are a little rough.

So this Controlware system that I have now -- a small, DOS based ladder editor and soft logic engine, took about 10 man years to develop with
full-time developers.

That second-hand experience is one why I'm very pessimistic about the LinuxPLC/PuffinPLC/MAT project.

> Also, what would you guess for ongoing development and maintenance
> costs once the first release is out?

One or two full time support guys? One or two full time programmers? When do you release (aka how many bugs do you have left to fix) and how much help does this product need? All depends.

<snip bit about machine companies rolling their own in an attempt to save money>

> I've been curious as to how much money these machine companies may
have
> sunk into their proprietary soft logic systems. It would give me
> an idea as to how much weight to put on their arguements that
> they came up with their own system for technology reasons, and how much
> of it was actually because they thought they could save money on
> software licenses.

That would be, indeed, something very interesting to find out. As usual, it depends on the size of the company, but I've believe that its rarely
"technical" reasons that cause development to be moved in house.

Alex Pavloff
Software Engineer
Eason Technology

 

On September 16, 2002 05:39 pm, Jiri Baum wrote:
<clip>
> Michael Griffin:
> > Would
> > you (or anyone else) have a rough idea of how many man hours is
> > involved in writing a usable soft logic system? Assume the following:
> >
> > - Ladder functionality equivalent to a typical low end PLC.
>

Jiri Baum:
> If it's mnemonics, then it's very little. The actual logic is so trivial
> that it'll be dominated by the problem of getting them from the user
> into a usable form, which is not much - looking up three letter codes in
> a table is not a big problem. I think it took me an evening to get it
> roughly into shape, and another to polish. On the other hand, I knew
> what I was doing.

If the whole thing was "very little", then I suspect you would be done your own project long ago. On the other hand, it can't be too huge a job or Siemens (and others) wouldn't have been able to run their older conventional PLCs on an 8032 - there's only so much software one of these things can handle.

I'll make my own guess on how difficult this would be. Perhaps you could correct me. Let's assume that the target O/S can be whatever is convenient, you can buy all I/O drivers, use good development software and third party
libraries.

Let us assume the following:
1) Basic system research and design - 500 hours (figuring out what you are going to do, and how to do it).
2) Soft logic execution engine - 500 hours (you said this was easy).
3) Ladder programming software - 1000 hours (minimal package).
4) Documentation - 0 (zero) hours (as I said, there normally isn't any).

If someone worked at this full time, it would take them a bit more than a year (allowing for holidays, etc.). Does the above sound somewhere in the right area? Keep in mind that this is not a top caliber system. Also, there is no market research, no advertising, no sales campaign, etc. All the really hard stuff (drivers, OS, etc.) is purchased.
I'm also assuming that the person designing and writing the program has some
experience in this area (machine control software), rather than being someone who normally writes business software for a living. This is a significant factor, as the typical business software programmer seems to have little or no experience which can be applied to this type of project, and so has to be taught nearly everything before they can accomplish anything useful.

> > - No user documentation.
>
> Yeah, that was the problem in the first few months - just announcing it
> on the mailing list doesn't work, people forget. Which is why I now
> insist on adding everything to the manual as soon as it's added

The proprietary systems I am talking about don't have documentation because the people paying the development bills see documentation as unnecessary overhead, rather than an essential part of the system. They still have the "experts" who wrote the system in house, so they don't see the need to spend money to write anything down.
For the customers buying the finished machines, the quality of the control system documentation is only one factor in the overall system, so customer demand has only a marginal effect.

> > I've been curious as to how much money these machine companies may
> > have sunk into their proprietary soft logic systems. It would give me
> > an idea as to how much weight to put on their arguements that they
> > came up with their own system for technology reasons, and how much of
> > it was actually because they thought they could save money on software
> > licenses.
>
> It's probably a combination: if they want any customization at all, they
> basically have to write the the whole thing, because customization fees
> would be prohibitive.
<clip>

The shame of it is that each of these companies duplicates things that have been done many times before, and none gains any competative advantage by having their own proprietary soft logic system. They would get their machines to do what needs to be done one way or another without it. If anything, the fact that each has a unique system is a negative point - for the customer
it's another system to learn and support.


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

 

Virus Warning for everyone using Linux-based SCADA and PLC systems...

New Linux Worm Threatens Denial-Of-Service Attacks
Security vendors are warning users running Linux Apache Web servers that they're vulnerable to attack from the first worm to use peer-to-peer networking technology. The Linux.Slapper.Worm
exploits a buffer overflow vulnerability within OpenSSL, often used in Apache Web servers.
"http://update.informationweek.com/cgi-bin4/flo?y=eIt20EEEaJ0V20BiQz0AE":http://update.informationweek.com/cgi-bin4/flo?y=eIt20EEEaJ0V20BiQz0AE

 

But this "extra juice" is the single most important way, and perhaps, the only way to bring about change. Many people have said many things about my position as being radical, communist, anti business, etc. These are of course buckets of black paint to cover the apathy of working automation professionals in regards to how they
are manipulated and lead around in directions not in their interest and even technically absurd, to the benefit of the various vendors. My only interest is to get folks, instead of bitching, to
take positive action in discouraging the darker aspects of the status quo. Once something achieves widespread, even grudging acceptance, it's with us forever and after even one wave of installs is permanently entrenched.

It's a strange dynamic to change because of this and this forms a lock in factor more subtle yet powerful than the overt measures. It simply can't be undone quickly or directly. I mentally model it as similar to a bezier curve. Our project, and other efforts at truly Open control and automation, can't at this point, directly alter the line. But by providing more and more control points and moving them in the same direction, we can bend it far enough where people can see that things don't always have to go the same way. And most, important, that the line can be moved.

A sizable number of folks who simply say what they
think and have expressed here _when decisions are
being made_ would definitely change the shape of
things for the better. Notice, I'm not asking you to accept my world view of responsible business, but merely to really, really assert your own, in those crucial moments when even the most jaded vendor is listening, before the check is signed. No amount of analysis or regret can alter a bad decision. Use the juice.

Regards

cww

 

Alex:
> Volunteers are great, but like all volunteer organizations, you need
> some place where people are paid to keep the thing on track
> if you want
> to actually get things done.

And where would those projects be without the volunteers devoting their free time upfront to the public? No where. I wonder if any of them would survive without other people sending in patches, testing, etc. I don't think you could remove either group (commercial or volunteer) from any of those projects and expect it to do as well as it does now because they are all interdependant on one another. You can see the effects of those dynamics even in the gaming world. Check the popularity of games (win.
linux. whatever) in the same genre that have a robust user community creating free addons verses those that do not. A OS by itself does very little after all.

The company business angle comes in later (after some initial investement in volunteer time). I think thats what Curt is saying. It might not even be in the best interests of the MAT project to have companies buying influence now because they are making the sort of design decisions that require both deep thought and an independance from monetary concerns that can allow one to be innovative (no i'm not saying that if your paid to do something you can't be innovative, but you do have different concerns that can affect the
process in a situation dependant way). If one person was being payed to develope MAT for an entire year, and biasing the project so that the
volunteers all left, MAT would surely die. At some point in the future things will probably change (and it will probably be for the benefit of the project and users), but theres a bit of road between here and there before we really need to worry about that.

regards,
Richard Higginbotham

 

If you look back a few years they were also doing it when they weren't paid by anybody. The argument that you must be paid to code a major project is absurd. What is your basis? If I want to sit down and write code right now, do i need to
find someone to pay me? If I decide to give 4 hours a day to a project, is there anything preventing me from doing so? I'm not sure what you're driving at. If I can do that,
logically, everyone else can. Would the work done evaporate?

Regards

cww

 

> > Michael Griffin:
> > > Would you (or anyone else) have a rough idea of how many man hours
> > > is involved in writing a usable soft logic system? Assume the
> > > following:

> > > - Ladder functionality equivalent to a typical low end PLC.

> Jiri Baum:
> > If it's mnemonics, then it's very little.
...

Michael Griffin:
> If the whole thing was "very little", then I suspect you would be done
> your own project long ago.

Of course, MatPLC has had mnemonics for years (mid-2000, it's dated). The translator is 223 lines all up, including comments and blank lines,
and implements 22 mnemonics (including basic logic, latches, master control, jumps and subroutines).

See "http://mat.sf.net/manual/logic/il.html":http://mat.sf.net/manual/logic/il.html

The core of it is basically a reverse Polish notation calculator, which is a standard 3-hour lab at first-year university level.

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

 

On September 17, 2002 05:23 pm, Alex Pavloff wrote:
<clip>
> So this Controlware system that I have now -- a small, DOS based ladder
> editor and soft logic engine, took about 10 man years to develop with
> full-time developers.
<clip>

I've never done one of these myself, but does that 10 man years include market research, promotion, overhead, project management, etc? You may have seen another posting I made in which I speculated that slightly over 1 man-year for the programmers and software designers only (no overhead or other costs).
I could be easily persuaded that my estimate was off by a factor of 2 or even 3, but by a factor of 10? Perhaps this was 10 developers working for 1 year, which would probably make inefficient use of manhours. I suspect though
that a lot of indirect man-hours is in that 10 man-years estimate.
When I think of some of the companies which have developed their own, I am pretty sure they didn't have that kind of man power available to them.


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