linux Modbus master

M

Michael R. Batchelor

On Thu, 7 Mar 2002, Curt Wuollet wrote:
> As you can plainly see, there are plenty of people who would
> like to take work freely given and exploit it for profit. To
> take what is Open and close it, for whatever reason, is a
> step in the wrong direction.

Depends on your motive. This is exactly the effect of the BSD style license. Red Hat, GPL lovers that they are, have taken OpenBSD, which is freely available, but not GPL, and have created
the Stronghold web server, which is not freely distributable, and is not free to use. You've got to buy a license.

Now, most people in the GPL crowd find that repulsive, but Theo and the crew at OpenBSD are free to release their code under any license they want, and that's how they choose to do it.

> If you, as the author, decide to license _your_ code, both
> under the GPL and your private license, you are free to do so
> and then your product, using your code need not be GPL.

This is an important point that most people fail to understand. If you, as a developer, create some neat-o whiz-bang program that the whole world wants, and stuff it out on the net under GPL, then I'm not free to take that code, do something with it myself, and resell it closed source. The GPL protects *YOUR* right to make the code freely available. But it's still your code. I can say, "Hey. Good stuff there. Sell me a license to put it in my xyz not GPL." You can look at my offer, decide it's good money, and give me a piece of paper that says I'm free to distribute exactly the same software, but commercially licensed, and I don't have the GPL restrictions. In other words, if you release
something under the GPL then that's not an exclusive license to the world. You can commercially license it to 40 different people,
who are free to us it in what ever manner you gave them permission. But the can't take the free distribution and use it any way they want. They can only use the free distribution if they also make their stuff free.

See Curt's next paragraph.

> The only thing you are prohibited from is taking someone
> else's GPL code and making it part of a closed product
> against their wishes.

The GPL has a place. It's exactly the reason the whole GNU/Linux movement exists today. The BSD style license has a place. It promotes commercial development in a way the GPL restricts. Closed source has a place. It feeds most of us. There isn't a "best" license. It's more a matter of a "best fit" license depending on your purpose.

MB
 
M

Michael R. Batchelor

On Thu, 7 Mar 2002, Curt Wuollet wrote:
> As you can plainly see, there are plenty of people who would
> like to take work freely given and exploit it for profit. To
> take what is Open and close it, for whatever reason, is a
> step in the wrong direction.

Depends on your motive. This is exactly the effect of the BSD style license. Red Hat, GPL lovers that they are, have taken OpenBSD, which is freely available, but not GPL, and have created the Stronghold web server, which is not freely distributable, and is not free to use. You've got to buy a license.

Now, most people in the GPL crowd find that repulsive, but Theo and the crew at OpenBSD are free to release their code under any license they want, and that's how they choose to do it.

> If you, as the author, decide to license _your_ code, both
> under the GPL and your private license, you are free to do so
> and then your product, using your code need not be GPL.

This is an important point that most people fail to understand. If you, as a developer, create some neat-o whiz-bang program that the whole world wants, and stuff it out on the net under GPL, then I'm not free to take that code, do something with it myself, and resell it closed source. The GPL protects *YOUR* right to make the code freely available. But it's still your code. I can say, "Hey. Good stuff there. Sell me a license to put it in my xyz not GPL." You can look at my offer, decide it's good money, and give me a piece of paper that says I'm free to distribute exactly the same software, but commercially licensed, and I don't have the GPL restrictions. In other words, if you release something under the GPL then that's not an exclusive license to the world. You can commercially license it to 40 different people, who are free to us it in what ever manner you gave them permission. But the can't take the free distribution and use it
any way they want. They can only use the free distribution if they also make their stuff free.

See Curt's next paragraph.

> The only thing you are prohibited from is taking someone
> else's GPL code and making it part of a closed product
> against their wishes.

The GPL has a place. It's exactly the reason the whole GNU/Linux movement exists today. The BSD style license has a place. It promotes commercial development in a way the GPL restricts. Closed source has a place. It feeds most of us. There isn't a "best" license. It's more a matter of a "best fit" license depending on your purpose.

MB
 
A
> Joe replies:
>
> So did Netscape. When IE became free, netscape was forced to change their
> business model to the server market. The one issue that does concern me
> about OSS is that it does push into legitimate markets (in my opinion) and
> pull the ground out of them.

That's interesting that you brought up Netscape. The open source version of Netscape, Mozilla, is licensed under the MPL. An open source project under the MPL that I will be using shortly (and, of course, looking at and fixing bugs and submitting my code to) is Microwindows. (www.microwindows.org). I can write my NDAed code, I can write my proprietary drivers, and I can distribute this.

As a result, I use it, and plenty of other people use it, and things get bug fixed and features get added.

> Joe:
> you said yourself that the problem you had with GPL was that
> you couldn't take the GPL-ed code, tie it into your product, and sell it
> on the market. What sort of contribution to the project would this be,
exactly?

If I took your code, changed things in it, fixed bugs, and added features, does that count as a contribution? I've already done this for an LGPL project (CommonC++), but can't do it for you. You use a less restrictive license, and more companies will look at your code, finding more bugs, and add features to your code.

As it stands, your project is fairly OEM hostile. I can't use it. You've got an all-or-nothing license here.

> Joe:
>
> Ooooh! Good one! Anyone who has a hobby that could use controls is
> apparently incapable of being a professional programmer at
> the same time.

No, I just really doubt the desire of a hobbyist programmer to get into the nuts and bolts and actually put together a system half as usable as one put together by a company that wants to make a profit. Once all the sexy work has been done, whose going to write documentation? Whose going to sit around and tweak the user interface of your ladder editor to make it user friendly?

I know that you guys can get the technical stuff done -- its fun to work on, and makes stuff work. Its the secondary things that don't get done in open source projects unless there's a company spending money directly on the project.

Remember -- this is a PLC that you're working on. In the end, you're going to have to get it to the point where an electrician can debug that ladder logic at two in the morning to make the plant go.

> Each of those 'hundred existing PLCs' seems to have found a
> niche. I am sure the LPLC will do likewise.

I thought that the goal was to conquer the world and make life easier for all the integrators tired of dealing with crappy software, overpriced
hardware, and evil companies.

Alex Pavloff
Software Engineer
Eason Technology
 
C
Hi Alex

> Curt, my major point about the problems with the GPL in regards to your MAT
> project:
>
> a) Most work done in our field is done by companies.

Yes.

> b) Hardware and software companies need to have proprietary software. (As the LonTalk thread shows)

They believe they need it, yes. Whether they actually need it in every case is debatable. A lot of successful high tech companies own no IP whatsoever. IBM used to think that way as well. Now they are finding that contributing needed things to the Linux community has been one of their _very_ best investments. Jealously guarded, they weren't doing anyone much good. One would be very hard pressed to find any plausible downside for either party and these were things that represented substantial investment. The guy who pushed it is now in the top spot.

> c) Your project is allergic to proprietary software

No, we're allergic to mixing the two. There will be no problem running proprietary applications on the system and it's likely we will have some proprietary stuff driven by the system, but the system itself will be Open. It's more that proprietary software is allergic to us. It's quite clear which is more beneficial to the consumer and community.

> Therefore: Hardware and software companies will not support your project.

I don't think anyone will mind selling more IO, that's where the money is. And we don't need much from the software companies. Besides, it's not a question of who supports us, it's who wants the business we generate and who wants to sell to the customers who want IO and services. The current model is to push a wide variety of articles by bundling them inseperably. The companies that will be most important to us will be those that want their stuff to fill the demand. For example, the companies that sell Ethernet IO should be fairly friendly and work with us on protocols. Integrators are a good market to start with.

> In this field, I don't think you can get far without the support of
> established companies. This isn't a new market -- this isn't a new idea.
> You're copying things that have been done before. The only people that will
> use your project with the current licensing terms are integrators. That's
> it.

Like I said, that's an excellent place to start, they get an extremely flexible platform that makes integration easier (possible?) and we get the benefit of their experience and knowlege. If integrators start using MAT/LPLC the right kind of things will happen. Integrators are an important part of the market and will form an excellent community.

> And I don't think that you have enough integrators and "procrastinating grad
> students that want to run their train set" with the programming skills and
> time to create a PLC that can even compete with some of the AutomationDirect
> and other cheap PLCs out there.

We'll keep you on the mailing list anyway:^) It depends a lot on how much the limitations of the current model affect you. For what I do it's already vastly superior. If you have to connect diverse equipment together, PLCs are a non-starter. If you need sophisticated communications, a Linux box, even without a logic engine on it is at least an order of magnitude better at it than any PLC. The logic engine is becoming a small part of a total solution and PLCs simply don't do the other stuff well. If you find you have all sorts of bridges, converters, adapters, and you need to have a PC in the mix anyway, it's a no brainer.

> In regards to the Modbus Master, it doesn't even make any sense to be GPLed.
Why not?

> If it was a kernel driver, as Mr De Sousa says it really should be (to deal
> with all the fun Modbus RTU timing issues), then I COULD use it from
> proprietary software.

And with my blessing and best wishes. All we want is for our stuff to stay free and available for everyone on equal terms. It's a pretty good deal if you use it that way.

Regards

cww
 
C
Well put, Micheal and the GPL is very good for our purpose here. I have code under other license and some under no license and a lot that is unpublished and privately owned. And I find no particular conflict in that. If your purpose is to open things up and keep them open, you use the GPL. If your purpose is to collect a paycheck, you might not have much to say about it. But, more and more, people are realizing the enormous value of tapping in to the bounty of GPL software for the small price of giving back the part you add. The majority of users use it as is or don't publish what they change and so owe nothing.

Regards

cww
 
Jiri Baum:
> > > OK. If the feature is something that's generally useful, chances are
> > > it'll be generally requested, though, and possibly obvious.

Alex Pavloff:
> > Of course -- however, I have a head start.

Joe Jansen:
> Joe replies:

> So did Netscape. When IE became free, netscape was forced to change
> their business model to the server market. The one issue that does
> concern me about OSS is that it does push into legitimate markets (in my
> opinion) and pull the ground out of them.

One could argue that whether volunteer or paid goods are better in some wider sense; if a market is better served by an open-source product, then why would it be a bad thing?

> > Using the LinuxPLC it right now is more painful than working around
> > bugs. Therefore, people won't use it (because they have product to
> > ship), therefore, no work will get done.

> Gee, what have we been doing then? I am sorry to hear that no work has
> been getting done. Apperently those code check in's are just random bit
> flips at sourceforge then.....

Alex is right that the work proceeds much slower for the time being; in addition, while it's not being used for a real project, it lacks the very important grounding influence that such projects would provide.


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

Michael Griffin

On March 7, 2002 08:36 pm, Alex Pavloff wrote:
<clip>
> In regards to the Modbus Master, it doesn't even make any sense to be
> GPLed. If it was a kernel driver, as Mr De Sousa says it really should
> be (to deal with all the fun Modbus RTU timing issues), then I COULD
> use it from proprietary software.
<clip>

Might I suggest cutting this Gordian knot by separating the Modbus master (and other protocols) from the MAT project? There seems to be enough interest in industrial protocols that it deserves to be a stand alone project. The MAT project would benefit from having other people working on various protocols for their own purposes. Mr. Linse made the rather convincing point in another message that we will be dealing with many protocols for the forseeable future, so the more people there are working in this area, the better.

Mr. Pavloff might also wish to consider the implications of his above statement. If the Modbus master is subject to GPL, then there is nothing to prevent someone from taking it and turning it into a kernel driver, providing this kernel driver was also released as GPL. While GPL prevents you from turning the code into a proprietary product, it does not prevent you from making any GPL derivatives you may wish to create.
While Mr. Pavloff's new proprietary product may have some unique features, I doubt that the ability to speak Modbus is something he is counting on to differentiate it from his competition. While some people may have a Pavlovian reaction (sorry, but I couldn't resist) to "proprietary", I don't see what objection they could raise to this suggestion. I don't know if Mr. Pavloff is in a position to undertake this work by himself. Perhaps though, someone would be willing to assist in this, given enough good will and the preception that this would be generally useful.

As a technical note, while I am not an expert in Linux drivers, I have been given to understand that the future trend is away from kernel drivers, and towards loadable drivers. This might be something to keep in mind if we have to deal with multiple drivers.


> This isn't a new market -- this isn't a new idea.
> You're copying things that have been done before. The only people
> that will use your project with the current licensing terms are
> integrators. That's it.
>
> And I don't think that you have enough integrators and
> "procrastinating grad students that want to run their train set" with
> the programming skills and time to create a PLC that can even compete
> with some of the AutomationDirect and other cheap PLCs out there.
<clip>

While I don't have any involvement in this project, I was under the impression that it was more properly a soft logic system than a conventional PLC.
I am aware of several soft logic systems that are perhaps a bit more proprietary than you may be familiar with. Some equipment OEMs who produce "standard" machines have written their own soft logic systems. These systems have their faults, the main ones being that they are all different, and rarely come with any useful documentation (or even any at all). However, they do work and most of the companies which created them are not particularly large. They apparently felt they had good reason to create a system which would be under their own control, rather than rely on a third party.
When these companies can come up with their own working soft logic system, I don't find it too suprising that "integrators and procrastinating grad students" could do the same. I think rather, that too large a number of people working on a software project like this would be more likely to sink it than help. Too many cooks spoil the broth, as it were.

Michael Griffin
London, Ont. Canada
 
Alex Pavloff:
> Curt, my major point about the problems with the GPL in regards to your
> MAT project:
...
> The only people that will use your project with the current licensing
> terms are integrators. That's it.

Then again, every machine project has an integrator towards the end of the chain. In-house or external, formal or de facto, it doesn't matter - it's still an integrator. Someone who has to say ``to make *this* particular pile of rust move and do something useful, we can use X, Y or Z and these are the pros and cons of each''.

So appealing `only' to the integrators is perhaps not as bad a strategy as you might make it out to be...


Jiri, assuming for the sake of the argument that you're right
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
R

Richard Higginbotham

Some secondary things will be done by LPLC members as time allows, others will be done by companies selling support or who just want it done. The difference is that you dont have just one source for this service who can charge whatever they feel like. Competition LOWERS prices, which in general, is good for the users.

What I think a lot of people seem to be missing is that the Modbus code wasn't drawn out of the ether, it was written by someone and DONATED to the LPLC project. As such its thier (whoever it may be) right to decide what licience it is released under. If you want to write parts under a less restrictive liciense and donate those to the project, as far as I know, you are free to do so (Curt, Jirri, help me out on this one). What they can't do is force you to release your code under a licience that you don't like or think is fair. No ones stoping you from doing this they are just preventing you from taking someone elses code and make money off of it against their wishes. In this way, you and these "other companies" can share a code base (used in your proprietary code) and at the same time it can be debuged and patched by those who don't want to work for you for free (like myself).

Problem solved.

Richard Higginbotham
Speaking for me
 
C
As far as I'm concerned everything that goes in the cvs archive must be GPL. There are just too many variables if we start mixing and even
attorneys can't figure out all the implications. That's not to say that it can't be done, just that the core project needs to be consistant. Anything not GPL would be distributed seperately and the author can be responsible for the legalities. We don't have a legal volunteer. We may need to work with drivers, for example, under other licenses but I'd like to keep these seperate so a legal problem can't shut us down.

Regards

cww
 
R

Richard Higginbotham

Sorry, should have been more clear but ran out of time. I don't mean to have several different liciensing requirements for different parts of LPLC (what a nightmare that would be). I meant to say that an "outside" organization could donate code to LPLC under the GPL (ie. make available thier code under more than one licience) which would keep everything in LPLC GPL happy. That same group could also license their source code with LGPL (or any other) for
commericial users. We'd simply be using a library of functions proprogating bug fixes, problems, etc. back up to another group who was responsible for the software same as any other library that was external to LPLC. We could take
advantage of the code base, assuming there are all these companies who are willing to donate and not just take, and they would get a bigger pool of people helping out. It wouldn't be any different than anything we do now. If libX
doesn't work correctly, you send an email to the developers, right? I agree that it shouldn't be part of Linux PLC (back door for too many outside rather nefarious influences), but I think it would be a benefit to help support said outside group so long as there is benefit for us (it might even be worth a branch). If it turns out that the "commercial" entities aren't updating, fixing, etc. at a fast enough rate, we still have GPL code we can use and modify according to our needs. If it helps get IO drivers written, I think its worth trying. I doubt that there will be that much corporate interest, but, hey, Alex says he wants to help us out. Perhaps he is willing to donate his modbus code...

Richard Higginbotham
speaking for me
 
C
Hi Richard

And some of the reason is pragmatic. Lawyers and courts are entirely for organizations with money. The GPL does what we want to keep the code free and Open and it tends to be enforced by the community. If you break the rules, you get slashdotted and the world becomes a much lonelier place. And the fact that the same code can be GPL licensed as well as in the customary manner lets folks contribute bits and pieces we need without affecting what they are doing with it to stay in business. For libraries, in the case where the library _is_ the product, there are provisions made. All in all it's pretty reasonable. Usually, having parts of your product dual licensed shouldn't affect your business negatively, in fact, some companies are capitalizing on this to make parts of their products user supportable and customizable at no cost to them. Getting past the knee jerk reaction to realisticly addessing the real effects of contributing, I think it's very clearly a positive for all involved if they have any use for the project code.

Regards

cww
 
A
> If it helps get IO drivers written, I think its worth trying. I doubt
that there
> will be that much corporate interest, but, hey, Alex says he wants to
> help us out. Perhaps he is willing to donate his modbus code...

I'm not against the idea. I've got drivers that I've written for quite a few platforms that will eventually be ported over to Linux. However, there are a couple things that are problems.

I'm a C++ programmer. Yes, I'm evil, but all my communications code is written in C++. Curt has said a while back on the list that he wants to keep everything C so people can read it.

This aforementioned C++ driver code has dependencies on other parts of my code. Again, while I'm not really against the idea of GPLing some of this code, it would take a bit of work to get it into a distributable state. I don't think it would fit too well into a pre-existing project like the MAT because its from a completely separate lineage.

I work for a small company -- we don't have a lot of programmer bandwidth. I say "it doesn't seem like a bad idea to provide some of my code under the GPL", but then I have to prove to the people writing my paycheck that its actually a worthwhile use of my time.

Accolades in source code comments and nebulous "goodwill" don't really do that. To be brutally honest, will GPLing my code make my company money? Answer me that question.

Alex Pavloff
Software Engineer
Eason Technology
 
R

Richard Higginbotham

>To be brutally honest, will GPLing my code make my company money?
>Answer me that question.

No, probably not, GPL benefits the users and work-in-your-spare-time developers far more than corporate interests. BUT thats not the million dollar question. GPLing your code or not does not mean that the code won't be available (the
code will be there, hence this thread). What will you do when the same (functional wise) code is either available for free or your competition has 10x the develeopers, testers your company does at
no cost? GPL will probably not make you more money than you make now, but it may reduce your costs enough that you can compete later. Its up to you (your company) do develope a business strategy that will work in that (new) environment.

Richard Higginbotham
speaking for me
 
A
So then, when a large body of GPLed code that does what I'm doing exists, THEN I should make another decision? This assumes that there are a large number of linux-using automation companies out there. As far as I can tell, the number of Linux-using automation companies is very small. There doesn't appear to be any companies the likes of Intellution doing the same thing on Linux. There doesn't appear to be companies like Software Toolbox selling drivers for Linux. Most of the big automation companies are going with Windows CE for their embedded HMI needs.

Call my cynical here, but where are these other developers and testers that can provide 10x the resources that my puny company has coming from? I don't think anyone is going to blame me for not being the first one to jump in the pool here on the promise of "lots of people are going to follow you."

And here's the thing -- the things I AM using on Linux right now (CommonC++, Microwindows, the kernel, busybox, etc...) I can use just fine without GPLing all my code. Half the stuff I'm not even touching the code for, and most of the rest is LGPLed or MPLed. I test their stuff, I contribute my changes, and we all win.

Exactly how will the GPL help me? Where is the large body of GPLed code that I need to link statically to that will make my life easier?

You guys talks about this "new" way of doing business, and, I'm sorry, but it ain't here yet! (Of course, I'd point out that I'm hedging my bets in case it does, as I'm already using Linux <g>)

Alex Pavloff
Software Engineer
Eason Technology
 
Alex Pavloff:
> I'm a C++ programmer. Yes, I'm evil, but all my communications code is
> written in C++. Curt has said a while back on the list that he wants to
> keep everything C so people can read it.

That's not such a problem in itself.

> I say "it doesn't seem like a bad idea to provide some of my code under
> the GPL", but then I have to prove to the people writing my paycheck that
> its actually a worthwhile use of my time.

> Accolades in source code comments and nebulous "goodwill" don't really do
> that. To be brutally honest, will GPLing my code make my company money?

Another benefit may be bugfixes, improvements and extensions, but assuming the code is pretty good to begin with, there might not be much scope for that. Especially for something like modbus, which, after all, isn't such a rich universe (unless somebody adapts it to talk to a a not-quite-modbus product).

It may well be that GPL is not a good idea for you at this time, financially speaking. I guess people have pointed out the costs and benefits to you, it's up to you to do a cost/benefit thingy.


Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
Richard Higginbotham:
> > What will you do when the same (functional wise) code is either
> > available for free or your competition has 10x the develeopers, testers
> > your company does at no cost? GPL will probably not make you more
> > money than you make now, but it may reduce your costs enough that you
> > can compete later.

Alex Pavloff:
> So then, when a large body of GPLed code that does what I'm doing exists,
> THEN I should make another decision?

Yes - there may well be a cross-over point (ESR has a whitepaper on this) after which it's rational for you to go GPL. It might be good to run a few hypotheticals in your spreadsheet so you can tell that point when it comes.

> This assumes that there are a large number of linux-using automation
> companies out there. As far as I can tell, the number of Linux-using
> automation companies is very small.

Yes. One would hope (we would hope) that this will increase in the future.

> I don't think anyone is going to blame me for not being the first one to
> jump in the pool here on the promise of "lots of people are going to
> follow you."

The only reason you might want to be first is that there's a certain advantage to it (easier to attract developers if you're first-of-kind). This doesn't really apply to the Modbus driver, seeing as Mario already put one in the MAT CVS (and there's likely others floating around).

As for the MAT LinuxPLC project, one way we expect it'll proliferate is the already-mentioned model train layouts; but mainly we hope to provide an irresistible combination of features and flexibility.

As has been observed, most likely the first ``real'' adopters will be integrators, who own little IP beyond the code they sell to each individual customer. In that situation, it is merely a question of replacing TnD or AutomationX with the MAT LPLC - a feature-based comparison will quickly show which is the better approach.

> Exactly how will the GPL help me? Where is the large body of GPLed code
> that I need to link statically to that will make my life easier?

Yeah - when you see a body of GPLed code that you want.

> You guys talks about this "new" way of doing business, and, I'm sorry,
> but it ain't here yet! (Of course, I'd point out that I'm hedging my
> bets in case it does, as I'm already using Linux <g>)

Hedging bets is good :)


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

Richard Higginbotham

>There doesn't
>appear to be any companies the likes of Intellution doing the same thing on
>Linux. There doesn't appear to be companies like Software Toolbox selling
>drivers for Linux. Most of the big automation companies are going with
>Windows CE for their embedded HMI needs.

And which of those will give their "product" away for free, which will be open? Given two nearly functionally identical products, but one whose price is "free" and whose architecture is "open", it doesn't take a psychic to figure out which will be used more often. We just need some time to work on that that open option before it can be proved to you.

>I don't think anyone is going to blame me for not being the first one to
>jump in the
>pool here on the promise of "lots of people are going to follow you."

I suppose that all comes down to whether you prefer action or reaction. There's risk either way, if you don't get warm and fuzzies for helping a common interest, then I probably wouldn't do it if I were you. You certainly don't need to do anything now, and you will only know afterward whether you made the right decision at the right time or not, in which case it will probably be too late good or bad. If you were a user then I would say that the work would directly benefit and be geared toward you so its probably in your best interest to help as much as possible, but as your a vendor it probably won't make any difference at all until theres a competing 'free' product if there ever is one (don't know what your product is). By then, it will probably be too late, as I've already mentioned. Like I said earlier, only you have to live with your decisions. At least your looking at options so you'll be better prepared if theres anything to prepare for. heh, at least if I were you, I would keep track of the progress to see if there is anything developing that might be in competition to you, that would seem to be a good time to make a decision ;-)

>You guys talks about this "new" way of doing business, and, I'm sorry, but
>it ain't here yet! (Of course, I'd point out that I'm hedging my bets in
>case it does, as I'm already using Linux <g>)

Has anyone said it was? No one I know of is arguing to rip out your AB, Siemens PLCs just yet. My optimistic best guess is that you've still got a couple of years before there's a mature code base to work with. I can't imagine it taking less than 10 man years just for an IDE. I suspect it will be usable well before then, just not something I'd hand over to one of my customers.

Regards,
Richard Higginbotham
speaking for me
 
> Michael Griffin (on the MAT LinuxPLC):
> > While I don't have any involvement in this project, I was under the
> > impression that it was more properly a soft logic system than a
> > conventional PLC.

Yes, it is. Mind you, there's not that much difference (technically) between a soft logic system and the firmware of a PLC, so it may well eventually be both.

> > I think rather, that too large a number of people working on a
> > software project like this would be more likely to sink it than
> > help. Too many cooks spoil the broth, as it were.

For the time being, though, additional people would help rather than hinder, so feel free to join in :)

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
C
And if you put it on the PCPLC Open Hardware project, it will, in effect, be a PLC. Even quack like one :^)

Regards

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