D
Dan Pierson
There's a danger in trying to overspecify a volunteer project like this. Essentially:
- A lot of people are quite willing to contribute ideas to the spec to ensure that someone else implements their favorite hot item.
- Fewer people are willing to go to the trouble to write or seriously review detailed specs.
- Still fewer are willing and able to do the actual coding :-(
We've already seen a lot of the above on this list...
It's my experience that successful open source projects start with working code. This NOT to say that design is unimportant, just that community design by a committee of the whole tends not to work.
As for a couple of your more specific points:
- While I think that it is important to understand what an initial essential set of components is, I think that it is actively bad to try to define all possible/allowed components at this stage. We don't know all the answers and we don't want to discourage good ideas from people with unexpected answers (this is a set up for my next point). What is important is to develop a genuinely open architecture that will allow these as yet unknown people develop their components and make them work with everything else.
Unfortunately, the best way to develop that architecture is experiment and evolution. Prior specification sounds good but I don't believe it will work in this type of environment. Objectors are invited to produce concrete counter-examples
- IEC 1131 has an important role to play in the projects' future. However, it is not central. Implementing the whole thing would be a VERY large
undertaking. I think it will happen over time, but not all at once. Secondly, IEC 1131-3 is a backward looking standard that makes some attempt
to standardize old ways of doing automation control (the PLCopen Portability Level Certification looks like it may finally make this standard useful to end users -- IMO, a "standard" with no defined portability is not a standard
at all). Those ways are very important to many members of this list. Effort should and will be put into implementing them. However, there are
other approaches that some of us feel offer substantially higher productivity than any of the IEC 1131 languages. State based languages are
an example that Curt mentioned recently and that I have some experience with. I hope to see some of these approaches implemented as well as
variants on RLL + function blocks.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
- A lot of people are quite willing to contribute ideas to the spec to ensure that someone else implements their favorite hot item.
- Fewer people are willing to go to the trouble to write or seriously review detailed specs.
- Still fewer are willing and able to do the actual coding :-(
We've already seen a lot of the above on this list...
It's my experience that successful open source projects start with working code. This NOT to say that design is unimportant, just that community design by a committee of the whole tends not to work.
As for a couple of your more specific points:
- While I think that it is important to understand what an initial essential set of components is, I think that it is actively bad to try to define all possible/allowed components at this stage. We don't know all the answers and we don't want to discourage good ideas from people with unexpected answers (this is a set up for my next point). What is important is to develop a genuinely open architecture that will allow these as yet unknown people develop their components and make them work with everything else.
Unfortunately, the best way to develop that architecture is experiment and evolution. Prior specification sounds good but I don't believe it will work in this type of environment. Objectors are invited to produce concrete counter-examples
- IEC 1131 has an important role to play in the projects' future. However, it is not central. Implementing the whole thing would be a VERY large
undertaking. I think it will happen over time, but not all at once. Secondly, IEC 1131-3 is a backward looking standard that makes some attempt
to standardize old ways of doing automation control (the PLCopen Portability Level Certification looks like it may finally make this standard useful to end users -- IMO, a "standard" with no defined portability is not a standard
at all). Those ways are very important to many members of this list. Effort should and will be put into implementing them. However, there are
other approaches that some of us feel offer substantially higher productivity than any of the IEC 1131 languages. State based languages are
an example that Curt mentioned recently and that I have some experience with. I hope to see some of these approaches implemented as well as
variants on RLL + function blocks.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc