R
Hi all,
Robert Oglesby here, president of Host Engineering, partner of Automationdirect.com.
We've been trying our hand at the open control concept for a few years and recently released a Windows CE based PLC. We didn't do so because
we think it's the end of the journey (it isn't), but because we think it is one of many possible paths there. As a commodity provider of
automation equipment, we are completely dedicated to the concept of platform standardization. As such, we would be thrilled to see this effort successful and would like to be involved. I haven't read the entire archive so if I make points that have been (repeatedly
) made already, I apologize in advance.
Some thoughts:
There are really multiple goals here. The first should be to define a standard platform. I would define a platform as two things: a) the way
the box looks from the inside; OS, comm interface, data interface, and I/O interface, but -NOT- a specific control methodology, and b) the
way the box looks from the outside; standard comm interface to the controller's data or the control engine(s) itself.
The strength of the PC is not that we all run the same spreadsheet or word processor, but that we CAN if we want. Similarly, the strength of
PC software is that it will run on any PC regardless of the manufacturer. Standard platforms will yield the great software our
customers want, both open source AND proprietary. A large base of hardware independent software will, in turn, guarantee a large base of hardware that will run it.
PLC vendors have, for far too many years, attempted to define the "proper" way to run control. In doing so we have confined, bullied,
impeded, and otherwise upset our customers. The first and highest priority of this effort should be to define the platform that will free them to make their own decision about what is proper for them. An open source ladder engine or a proprietary object model - their choice, not ours. Running on a headless PLC style box or a high end workstation with leading edge graphics - again, their choice, not ours.
The second goal should be, I think, to create some open source engines that implement specific control methodologies. This MUST NOT be to the
exclusion of proprietary engines. The vast majority of high quality software does not come from guys writing VB in their basement, but
from companies that need to get paid for what they do. We need both. Period. For the customer that requires control program interoperability (IEC 1131 types, for instance) an open source engine is an ideal way to accomplish that. But for the customer that wants bleeding edge more than least common denominator, we must encourage
and support the vendors that innovate.
The third goal should be to establish standard protocols and interfaces that provide the interoperability of open and proprietary systems, while maintaining extensibility mechanisms to allow for vendor specific extensions. The goal of achieving a truly standard control system or communication protocol is as elusive as the Holy
Grail, mostly because the range of control problems is so vast that what is perfectly right for one is totally wrong for another. But,
interoperability at the most simple levels is often all that is required for the peaceful coexistence of incompatible systems - case in point - Modbus is the tie that binds. If we defined (or used existing) standards that provided access to the fundamental similarities that we all possess, while providing a standard conduit for vendor extensions, we may not find the Holy Grail, but we might end up with a complete set of McDonald's Christmas glasses ;-)
In closing, if all that is accomplished is the creation of a widely used, truly open, truly standard platform for control, I believe that
automation would forever be altered for the better. The PC should have taught us that much. But be cautious that in creating such a system,
we don't so thoroughly impose a particular view of what is proper that we become what we seek to replace.
Most important - standard platform. Then open source AND proprietary control engines, and standard protocols WITH vendor extensibility.
<flame shields on>
Robert Oglesby
President, Host Engineering, Inc.
Proud member of the Automationdirect.com federation of companies.
www.hosteng.com
PS. We have an SH3 based PLC with enough memory to run a Linux kernel, that coincidentally, has a separate boot loader and OS that can be updated over its Ethernet port by a freely available utility. Prior to discovering this illustrious group and its purpose, I had already identified it as a possible Linux target. I have not done so, nor do I know if it is possible, but I don't know what would prevent it. Anybody wish to know more?
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
Robert Oglesby here, president of Host Engineering, partner of Automationdirect.com.
We've been trying our hand at the open control concept for a few years and recently released a Windows CE based PLC. We didn't do so because
we think it's the end of the journey (it isn't), but because we think it is one of many possible paths there. As a commodity provider of
automation equipment, we are completely dedicated to the concept of platform standardization. As such, we would be thrilled to see this effort successful and would like to be involved. I haven't read the entire archive so if I make points that have been (repeatedly
) made already, I apologize in advance.Some thoughts:
There are really multiple goals here. The first should be to define a standard platform. I would define a platform as two things: a) the way
the box looks from the inside; OS, comm interface, data interface, and I/O interface, but -NOT- a specific control methodology, and b) the
way the box looks from the outside; standard comm interface to the controller's data or the control engine(s) itself.
The strength of the PC is not that we all run the same spreadsheet or word processor, but that we CAN if we want. Similarly, the strength of
PC software is that it will run on any PC regardless of the manufacturer. Standard platforms will yield the great software our
customers want, both open source AND proprietary. A large base of hardware independent software will, in turn, guarantee a large base of hardware that will run it.
PLC vendors have, for far too many years, attempted to define the "proper" way to run control. In doing so we have confined, bullied,
impeded, and otherwise upset our customers. The first and highest priority of this effort should be to define the platform that will free them to make their own decision about what is proper for them. An open source ladder engine or a proprietary object model - their choice, not ours. Running on a headless PLC style box or a high end workstation with leading edge graphics - again, their choice, not ours.
The second goal should be, I think, to create some open source engines that implement specific control methodologies. This MUST NOT be to the
exclusion of proprietary engines. The vast majority of high quality software does not come from guys writing VB in their basement, but
from companies that need to get paid for what they do. We need both. Period. For the customer that requires control program interoperability (IEC 1131 types, for instance) an open source engine is an ideal way to accomplish that. But for the customer that wants bleeding edge more than least common denominator, we must encourage
and support the vendors that innovate.
The third goal should be to establish standard protocols and interfaces that provide the interoperability of open and proprietary systems, while maintaining extensibility mechanisms to allow for vendor specific extensions. The goal of achieving a truly standard control system or communication protocol is as elusive as the Holy
Grail, mostly because the range of control problems is so vast that what is perfectly right for one is totally wrong for another. But,
interoperability at the most simple levels is often all that is required for the peaceful coexistence of incompatible systems - case in point - Modbus is the tie that binds. If we defined (or used existing) standards that provided access to the fundamental similarities that we all possess, while providing a standard conduit for vendor extensions, we may not find the Holy Grail, but we might end up with a complete set of McDonald's Christmas glasses ;-)
In closing, if all that is accomplished is the creation of a widely used, truly open, truly standard platform for control, I believe that
automation would forever be altered for the better. The PC should have taught us that much. But be cautious that in creating such a system,
we don't so thoroughly impose a particular view of what is proper that we become what we seek to replace.
Most important - standard platform. Then open source AND proprietary control engines, and standard protocols WITH vendor extensibility.
<flame shields on>
Robert Oglesby
President, Host Engineering, Inc.
Proud member of the Automationdirect.com federation of companies.
www.hosteng.com
PS. We have an SH3 based PLC with enough memory to run a Linux kernel, that coincidentally, has a separate boot loader and OS that can be updated over its Ethernet port by a freely available utility. Prior to discovering this illustrious group and its purpose, I had already identified it as a possible Linux target. I have not done so, nor do I know if it is possible, but I don't know what would prevent it. Anybody wish to know more?
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
