C
Hi Ken & all
Ken:
Got a chance to look at the article on the ISA site. Great description of the reasons for a free open source controller and open source advocacy.
One little thing though, the currency at the open source bazaar is recognition. I won't bitch about WOT not being mentioned if you and all for that matter, keep clearly in mind that this is a community project. The thing that will get people to code and contribute is to recognize those actions. Yours is a major contribution at this critical stage, for that we all thank you.
All:
We must develop a sense of community and mutual appreciation. That, not the simple fact of Open Source, is the essence of making this thing work. We all need to check our commercialism at the door. The community on the Automation List is very diverse and very partisan. We have not degenerated into flame wars yet although I have heard some discouraging words. That's not aproblem
as I don't expect those folks will be contributing. For those who want the project to succeed, please try to see others reasoning and where we can converge not diverge. I, for my part, struggle with my ego to plot a course
that will be maximally inclusive. This is very difficult as there are already many diverse opinions on how to proceed. I have no mutually agreed upon authority to do this, but, I did start the project and am willing to try. I wish to propose some ground rules with the reasoning behind them. These may be thrown out if you can develop a larger consensus than me. Indeed, I can be thrown out if someone can please a larger group of actual contributors. These will be carefully limited to what it will take to get a start and a reference implementation. If we can't achieve some sort of consensus, the advantage of having many developers is lost. If there's
something here you simply can't live with, post a constructive alternative. If you see more wisdom or a better way to serve the whole community,
post it. But, please do try to consider what's best for all.
License: GPL
Reasons: So it's owned by everyone equally and can't be subverted to exclude anyone. Including everyone excluding no one.
OS: Linux.
Reasons: It's the only truly open platform and the GPL guarantees that.
Anyone can get it and the tools it provides which are fully adequate for the task. It provides the libraries and tools to do the job
with less reinventing of the wheel. It provides for the use of remote HMI's and distributing tasks out of the box. Done in Linux, you will not need to buy add ons or tools or licenses. Revision Control will be possible as will
keeping a bunch of users and developers in sync. It can be scaled to the job and deployed without regard for legalities or restrictions. No one can force a rewrite or upgrade. With care, code can be reasonably portable. It already runs on more platforms from uCsimms to SBC's to Enterprise class servers to Beowulf supercomputers. It runs on almost every processor within reason and a few more than that. It has RTOS, embedded, and full versions with an agreed upon and consistent interface, Elix. Advanced networking is designed in. Tons of programs and functions with source code are available for integration and study. Last, but not least, we have the source code so the applications we write can fully coordinate with and exploit the OS features. The project will be officially agnostic on ports to other platforms _after_ there's a system to port.
Including everyone excluding no one.
My personal opinion? Porting to a proprietary OS defeats the entire purpose and will make the the project a part of the problem rather than a solution. Flame away.
Language: C
It is the native language of the platform. All the languages that I've heard anyone mention can be and are interfaced to C. It is the most
universal and is understood by more people than any other. It is more portable across platforms and compilers exist on even the smallest.
There is absolutely no way that we won't end up doing parts of this in C anyway. If the core system is done in C, any language can be used for clients and modular components. We will need C performance and possibly inline assembler in places. Many things on Linux require C interfaces. Bonehead C is preferred whenever possible, so boneheads like me can still contribute.
Including everyone excluding no one.
Architecture: Modular with flexible interfaces.
To allow cooperative development and utmost flexibility and accommodate as many different ideas and features as possible. To allow everything on one machine or distributed functions. Examples: Sockets allow PLC and HMI on
the same machine or across the world. Shared memory I/O map allows access from user code, RTLinux, modular hardware drivers or compiled kernel drivers. TCP/IP is central as it is ubiquitous and universal. I am working on a shared memory spec which I need for the Modbus I/O driver I'm working on now. This is about as flexible as it can be as new structures can be
added to accommodate drivers as they are added. We need a small working core that's, "As simple as possible but no simpler" to use as a research tool and as proof of concept. Just a working PLC with the tools to make it usable. If we don't do this first, I'm afraid the project will die. Once
this is complete, we can add or replace anything with a framework to test it in.
Including everyone excluding no one.
I/O:
This is a problem, By this time next year, I predict almost everyone will support Ethernet. Unfortunately, they will do everything in their power to support it in a proprietary, non-interoperable fashion. Example Controlnet.
I feel the best course is to emphasize TCP/IP as there will be profibus on TCP/IP, devicenet on TCP/IP, etc. There are boards to interface with
almost all existing fieldbus systems. The boards are for the most part expensive and will remain so because organizations like ODVA and Profibus
etal. want it that way. Of course, we can use dumb boards and do the protocols in software but this has it's limits. I chose Modbus and
Modbus/TCP for starters because they use the peripherals that everyone already has and I can get the information to do it and release the result under the GPL license. Most of the others are the real problems to be solved in this industry if interoperability is to be achieved. I don't hold out much hope for vendor cooperation either. This will require real commitment and resources and in some cases may not be possible without legal problems. Best plan may be to form groups of people who need a particular proto and pool resources to get it done. Local I/O should require only drivers. There will be Linux friendly board vendors who will see this as an opportunity. Years of proprietary greed and self-interest won't be undone quickly, but we have a lot of powerful people reading this.
Please make sure anything you can contribute here can be GPL'd.
Here we'll include as many as we can, Sorry. The vendors need a change in thinking to promote instead of restricting, to open and guide rather
than close and control.
On reflection, It might have been easier to just do what I was going to do and then release it. I don't think that would work with this crowd. It must be your project from the start.
Regards
Curt Wuollet
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
Ken:
Got a chance to look at the article on the ISA site. Great description of the reasons for a free open source controller and open source advocacy.
One little thing though, the currency at the open source bazaar is recognition. I won't bitch about WOT not being mentioned if you and all for that matter, keep clearly in mind that this is a community project. The thing that will get people to code and contribute is to recognize those actions. Yours is a major contribution at this critical stage, for that we all thank you.
All:
We must develop a sense of community and mutual appreciation. That, not the simple fact of Open Source, is the essence of making this thing work. We all need to check our commercialism at the door. The community on the Automation List is very diverse and very partisan. We have not degenerated into flame wars yet although I have heard some discouraging words. That's not aproblem
as I don't expect those folks will be contributing. For those who want the project to succeed, please try to see others reasoning and where we can converge not diverge. I, for my part, struggle with my ego to plot a course
that will be maximally inclusive. This is very difficult as there are already many diverse opinions on how to proceed. I have no mutually agreed upon authority to do this, but, I did start the project and am willing to try. I wish to propose some ground rules with the reasoning behind them. These may be thrown out if you can develop a larger consensus than me. Indeed, I can be thrown out if someone can please a larger group of actual contributors. These will be carefully limited to what it will take to get a start and a reference implementation. If we can't achieve some sort of consensus, the advantage of having many developers is lost. If there's
something here you simply can't live with, post a constructive alternative. If you see more wisdom or a better way to serve the whole community,
post it. But, please do try to consider what's best for all.
License: GPL
Reasons: So it's owned by everyone equally and can't be subverted to exclude anyone. Including everyone excluding no one.
OS: Linux.
Reasons: It's the only truly open platform and the GPL guarantees that.
Anyone can get it and the tools it provides which are fully adequate for the task. It provides the libraries and tools to do the job
with less reinventing of the wheel. It provides for the use of remote HMI's and distributing tasks out of the box. Done in Linux, you will not need to buy add ons or tools or licenses. Revision Control will be possible as will
keeping a bunch of users and developers in sync. It can be scaled to the job and deployed without regard for legalities or restrictions. No one can force a rewrite or upgrade. With care, code can be reasonably portable. It already runs on more platforms from uCsimms to SBC's to Enterprise class servers to Beowulf supercomputers. It runs on almost every processor within reason and a few more than that. It has RTOS, embedded, and full versions with an agreed upon and consistent interface, Elix. Advanced networking is designed in. Tons of programs and functions with source code are available for integration and study. Last, but not least, we have the source code so the applications we write can fully coordinate with and exploit the OS features. The project will be officially agnostic on ports to other platforms _after_ there's a system to port.
Including everyone excluding no one.
My personal opinion? Porting to a proprietary OS defeats the entire purpose and will make the the project a part of the problem rather than a solution. Flame away.
Language: C
It is the native language of the platform. All the languages that I've heard anyone mention can be and are interfaced to C. It is the most
universal and is understood by more people than any other. It is more portable across platforms and compilers exist on even the smallest.
There is absolutely no way that we won't end up doing parts of this in C anyway. If the core system is done in C, any language can be used for clients and modular components. We will need C performance and possibly inline assembler in places. Many things on Linux require C interfaces. Bonehead C is preferred whenever possible, so boneheads like me can still contribute.
Including everyone excluding no one.
Architecture: Modular with flexible interfaces.
To allow cooperative development and utmost flexibility and accommodate as many different ideas and features as possible. To allow everything on one machine or distributed functions. Examples: Sockets allow PLC and HMI on
the same machine or across the world. Shared memory I/O map allows access from user code, RTLinux, modular hardware drivers or compiled kernel drivers. TCP/IP is central as it is ubiquitous and universal. I am working on a shared memory spec which I need for the Modbus I/O driver I'm working on now. This is about as flexible as it can be as new structures can be
added to accommodate drivers as they are added. We need a small working core that's, "As simple as possible but no simpler" to use as a research tool and as proof of concept. Just a working PLC with the tools to make it usable. If we don't do this first, I'm afraid the project will die. Once
this is complete, we can add or replace anything with a framework to test it in.
Including everyone excluding no one.
I/O:
This is a problem, By this time next year, I predict almost everyone will support Ethernet. Unfortunately, they will do everything in their power to support it in a proprietary, non-interoperable fashion. Example Controlnet.
I feel the best course is to emphasize TCP/IP as there will be profibus on TCP/IP, devicenet on TCP/IP, etc. There are boards to interface with
almost all existing fieldbus systems. The boards are for the most part expensive and will remain so because organizations like ODVA and Profibus
etal. want it that way. Of course, we can use dumb boards and do the protocols in software but this has it's limits. I chose Modbus and
Modbus/TCP for starters because they use the peripherals that everyone already has and I can get the information to do it and release the result under the GPL license. Most of the others are the real problems to be solved in this industry if interoperability is to be achieved. I don't hold out much hope for vendor cooperation either. This will require real commitment and resources and in some cases may not be possible without legal problems. Best plan may be to form groups of people who need a particular proto and pool resources to get it done. Local I/O should require only drivers. There will be Linux friendly board vendors who will see this as an opportunity. Years of proprietary greed and self-interest won't be undone quickly, but we have a lot of powerful people reading this.
Please make sure anything you can contribute here can be GPL'd.
Here we'll include as many as we can, Sorry. The vendors need a change in thinking to promote instead of restricting, to open and guide rather
than close and control.
On reflection, It might have been easier to just do what I was going to do and then release it. I don't think that would work with this crowd. It must be your project from the start.
Regards
Curt Wuollet
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc