D
> From: Robert Oglesby [mailto:[email protected]]
> Subject: LinuxPLC: Platform first, then controller
> At its foundation, every control product is simply IOBC - Ins, Outs,
Brains,
> and Comm. So any plaform that establishes a standard way of implementing
> those basic requirements is a control platform. Whether it runs ladder and
> and we call it a PLC, or flow charts on a PC, or SCADA on a workstation,
> it's all just IOBC. The only real difference between control system A and B
> is topology, latency, and performance. The requirements of process are
> different than motion are different than machine control - but - at some
> fundamental level, they are all just IOBC. If you define a platform that
> provides standards based access to the IO and C, while allowing standards
> based access to a user selectable B, you have the foundation of a truly
> standard platform. Anything short of a user selectable control engine
> running on fully standard fully scalable hardware, is a nice hobby or at
> best a niche product...
Thank you for a very elegant statement of one the key points I, and I think
some others, have been trying to make. Personally, I've mostly been
ignoring the ladder vs. non-ladder argument because they both have to exist.
I've been a little more worried about the continuing attempts to come up
with one, universal engine implementation of B based on a ladder/PLC view of
the world because it simple can't work for some other types of controller
language environments. A module that implements a ladder/PLC B would be a
good thing. A LinuxPLC that enforced the use of that B would be a disaster,
both for us and for the long term future of the project.
Jiri's message on modular vs. monolithic programs was right on the point.
This brings be to the other key point. This effort is really a collection
of subprojects. Curt's initial effort is one of these. It, or something
like it, has to come first because it provides a platform that others can
build and test on. Once that platform is in place, people who need ladder
will implement it. People who need something else will implement that.
Most of these will become separate subprojects. I'll be surprised if Curt
finds the time to be involved in all of them
.
As in all open source work, the projects that actually get done will be the
ones that people find important enough to find the time to work on. If we
succeed, I eventually expect some companies will pay people to work on
contributions they find important for their business.
We are planning for the web site, CVS repository, etc. to support multiple
subprojects as needed. We plan to place control of those sections of the
wesite directly in the hands of the subproject people. The details are
still being worked out (but see http://www.zope.org for a good hint).
Dan Pierson, Control.com
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
> Subject: LinuxPLC: Platform first, then controller
> At its foundation, every control product is simply IOBC - Ins, Outs,
Brains,
> and Comm. So any plaform that establishes a standard way of implementing
> those basic requirements is a control platform. Whether it runs ladder and
> and we call it a PLC, or flow charts on a PC, or SCADA on a workstation,
> it's all just IOBC. The only real difference between control system A and B
> is topology, latency, and performance. The requirements of process are
> different than motion are different than machine control - but - at some
> fundamental level, they are all just IOBC. If you define a platform that
> provides standards based access to the IO and C, while allowing standards
> based access to a user selectable B, you have the foundation of a truly
> standard platform. Anything short of a user selectable control engine
> running on fully standard fully scalable hardware, is a nice hobby or at
> best a niche product...
Thank you for a very elegant statement of one the key points I, and I think
some others, have been trying to make. Personally, I've mostly been
ignoring the ladder vs. non-ladder argument because they both have to exist.
I've been a little more worried about the continuing attempts to come up
with one, universal engine implementation of B based on a ladder/PLC view of
the world because it simple can't work for some other types of controller
language environments. A module that implements a ladder/PLC B would be a
good thing. A LinuxPLC that enforced the use of that B would be a disaster,
both for us and for the long term future of the project.
Jiri's message on modular vs. monolithic programs was right on the point.
This brings be to the other key point. This effort is really a collection
of subprojects. Curt's initial effort is one of these. It, or something
like it, has to come first because it provides a platform that others can
build and test on. Once that platform is in place, people who need ladder
will implement it. People who need something else will implement that.
Most of these will become separate subprojects. I'll be surprised if Curt
finds the time to be involved in all of them
. As in all open source work, the projects that actually get done will be the
ones that people find important enough to find the time to work on. If we
succeed, I eventually expect some companies will pay people to work on
contributions they find important for their business.
We are planning for the web site, CVS repository, etc. to support multiple
subprojects as needed. We plan to place control of those sections of the
wesite directly in the hands of the subproject people. The details are
still being worked out (but see http://www.zope.org for a good hint).
Dan Pierson, Control.com
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
