C
Hi all
I've had other demands on my time, but I've been reading the mail, (quite a bit of mail :^) ) and I have been amazed at the interest and enthusiasm. Perhaps it's premature, but I've sensed some fall off in the last couple of days. So I was trying to assess "Where Are We?". as a focusing tool.
I haven't seen anything that really upsets the apple cart although there is quite a diversity of opinion. Here are some attempts to draw concensus on various points.
What's a PLC: When I say PLC it's possibly more general than some people. I take it literally to mean a processor that acquires data, performs definable operations on it and uses outputs to control a task or process. I don't see it in the sense that it has to be restricted to relay replacement or any dogmatic role.
USER Languages: In my original attempt at herding cats, I deliberately stayed away from this as a religious issue. I have seen everything from ladder only to control by extra sensory perception. The question that I ask is, who is going to code all this? To answer fears that your particular favorite might be left out, I doubt that anyone who delivers a working language that doesn't require a complete rewrite of the project will be turned away. What we're missing, and I don't want to discourage those who have done so, are the people who are willing to say, "I will write a ladder language for this project" or "I have the experience and skills to write to order" These will be the players who ultimately determine what happens when.
System Language: For the core, C. I have listened to the buzz and this I get as a consensus. It is also a pragmatic matter. All the languages I have heard of will interface
to C, and most likely, not to each other, so C will be required to provide the diversity that
seems to be desired.
I/O: Everything we can get legally. As a practical matter, I lean towards good fieldbus support but, everything except the most popular will probably be "you want it, you write it" Unless we get a team of really committed programmers who are willing to write to order,
this will probably be expanded piecemeal as the need and means arise. I am going to do Modbus/TCP
because that's what I need. I am hoping that someone who has a lot of (put FB name Here)
will see fit to write it or get it written and share it.. No matter what we might want, there is no means to get it except to write it and you need to have some I/O around to do that. So if you want it, figure out how you are going to do it. Joining together in interest groups can
help here.
Logic: Here, I am of the opinion that conflicting requirements will mean more than one logic engine. The best one for the first pass will be one that provides the information and experience to make the second pass better. Since we know very little at this point about the nagging little real world problems that will profuondly affect what we can and can't do,
to theorize at length at this point and debate about methodology is entertaining but not
remarkably fruitful. Since it seems that everyone agrees that ladder is a must, even in the 21st
century, I suggest that we cruelly limit the first pass to a conventional PLC model and set
definitaly achievable goals in the short term as a test bed for I/O drivers.
General: While I know the project will just die a horrible death if we don't design in everything
everybody wants from the very start, from what I am "hearing" I doubt that IBM and Microsoft
put together could do that. And I'm fairly sure the result would work exactly like some of their products do. And that is totally unacceptable in an automation controller. I believe that, since
the constraints are unknown, the resources are unpredictable, and we have few people with
carnal knowlege of Linux internals that an incremental approach would be best. Do what it
takes to get something basic working and build on that.
Process: I have read a lot of discource that doesn't reflect the Open Source collaborative
model of development. Incremental development is the rule, not the exception. It isn't like commercial development where you decide on the features you want and a team of people build it that way. Instead, many projects come about in stages. One person will code a basic program that does something he wants. Someone else will take that and add what they want. Features are strongly tied to the coder. There are some big
projects where a team of people is assembled and code to order, but even there it's usually
split up by interest and ability. As for the remarks that it's entirely useless if it doesn't
have X from the start, Linux started out as a program that printed "A". While commercial
development is often coded to a final result in one fell swoop, the sucess rate for large
projects is abysmally low. I think the final product will be much better if it is an "interesting hobby" or "niche product" until we have a lot more questions answered and
establish what works. It is almost certain that little of the original code will be final code
and much is thrown away along the way, but, that is why the model produces high quality software.
To use the model, Let's forget about the commercial viability for the time being. When
it begins to get to the point where people might think about actually using it for real work,
we will still have plenty of time for commercialism before it's release quality.
If we don't want to use the model, we should pool all the money we want to risk, hire the best team
available and file for a Billion dollar IPO before anybody knows if it's gonna work.;^)
I personally don't care if it ever runs on a MS platform and I really doubt that a good low
level design for one will ever be a good low level design for the other because they are
totally different as far as scheduling and priority are concerned. The higher level stuff
should be much better in this regard. The folks who want MS may want to build an interface compatible core.
Regards
Curt W
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
I've had other demands on my time, but I've been reading the mail, (quite a bit of mail :^) ) and I have been amazed at the interest and enthusiasm. Perhaps it's premature, but I've sensed some fall off in the last couple of days. So I was trying to assess "Where Are We?". as a focusing tool.
I haven't seen anything that really upsets the apple cart although there is quite a diversity of opinion. Here are some attempts to draw concensus on various points.
What's a PLC: When I say PLC it's possibly more general than some people. I take it literally to mean a processor that acquires data, performs definable operations on it and uses outputs to control a task or process. I don't see it in the sense that it has to be restricted to relay replacement or any dogmatic role.
USER Languages: In my original attempt at herding cats, I deliberately stayed away from this as a religious issue. I have seen everything from ladder only to control by extra sensory perception. The question that I ask is, who is going to code all this? To answer fears that your particular favorite might be left out, I doubt that anyone who delivers a working language that doesn't require a complete rewrite of the project will be turned away. What we're missing, and I don't want to discourage those who have done so, are the people who are willing to say, "I will write a ladder language for this project" or "I have the experience and skills to write to order" These will be the players who ultimately determine what happens when.
System Language: For the core, C. I have listened to the buzz and this I get as a consensus. It is also a pragmatic matter. All the languages I have heard of will interface
to C, and most likely, not to each other, so C will be required to provide the diversity that
seems to be desired.
I/O: Everything we can get legally. As a practical matter, I lean towards good fieldbus support but, everything except the most popular will probably be "you want it, you write it" Unless we get a team of really committed programmers who are willing to write to order,
this will probably be expanded piecemeal as the need and means arise. I am going to do Modbus/TCP
because that's what I need. I am hoping that someone who has a lot of (put FB name Here)
will see fit to write it or get it written and share it.. No matter what we might want, there is no means to get it except to write it and you need to have some I/O around to do that. So if you want it, figure out how you are going to do it. Joining together in interest groups can
help here.
Logic: Here, I am of the opinion that conflicting requirements will mean more than one logic engine. The best one for the first pass will be one that provides the information and experience to make the second pass better. Since we know very little at this point about the nagging little real world problems that will profuondly affect what we can and can't do,
to theorize at length at this point and debate about methodology is entertaining but not
remarkably fruitful. Since it seems that everyone agrees that ladder is a must, even in the 21st
century, I suggest that we cruelly limit the first pass to a conventional PLC model and set
definitaly achievable goals in the short term as a test bed for I/O drivers.
General: While I know the project will just die a horrible death if we don't design in everything
everybody wants from the very start, from what I am "hearing" I doubt that IBM and Microsoft
put together could do that. And I'm fairly sure the result would work exactly like some of their products do. And that is totally unacceptable in an automation controller. I believe that, since
the constraints are unknown, the resources are unpredictable, and we have few people with
carnal knowlege of Linux internals that an incremental approach would be best. Do what it
takes to get something basic working and build on that.
Process: I have read a lot of discource that doesn't reflect the Open Source collaborative
model of development. Incremental development is the rule, not the exception. It isn't like commercial development where you decide on the features you want and a team of people build it that way. Instead, many projects come about in stages. One person will code a basic program that does something he wants. Someone else will take that and add what they want. Features are strongly tied to the coder. There are some big
projects where a team of people is assembled and code to order, but even there it's usually
split up by interest and ability. As for the remarks that it's entirely useless if it doesn't
have X from the start, Linux started out as a program that printed "A". While commercial
development is often coded to a final result in one fell swoop, the sucess rate for large
projects is abysmally low. I think the final product will be much better if it is an "interesting hobby" or "niche product" until we have a lot more questions answered and
establish what works. It is almost certain that little of the original code will be final code
and much is thrown away along the way, but, that is why the model produces high quality software.
To use the model, Let's forget about the commercial viability for the time being. When
it begins to get to the point where people might think about actually using it for real work,
we will still have plenty of time for commercialism before it's release quality.
If we don't want to use the model, we should pool all the money we want to risk, hire the best team
available and file for a Billion dollar IPO before anybody knows if it's gonna work.;^)
I personally don't care if it ever runs on a MS platform and I really doubt that a good low
level design for one will ever be a good low level design for the other because they are
totally different as far as scheduling and priority are concerned. The higher level stuff
should be much better in this regard. The folks who want MS may want to build an interface compatible core.
Regards
Curt W
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc