R
Hi folks: Here it is, version 0.0.1 of what I am calling OIC - Open Industrial Communications. It is a written spec, not code. It is basically an attempt to get the discussion rolling. It is completely open to discussion by anyone and everyone. I envision this protocol to eventually be able to both communicate with processors AND with I/O devices. Don't worry, I purposely have not specified a command set - yet. I want to concentrate on form of the spec first before I dive into implementation and specifics.
-------------------------------------------------------
Open Industrial Communications Specification Proposal v0.0.1
Copyright - 2001 by Ron Gage, Saginaw Michigan
This document protected by United States Copyright Law.
PURPOSE: This document is to detail the Open Industrial Communications (OIC) protocol. This detail is to be fully explained in "laymans" terms and in an unambiguous manner. The entire protocol is to be fully documented and shall have absolutely no hidden or "proprietary" provisions about it. It is not the purpose of this document to infringe on any company or individual's intellectual property rights, be they patented or otherwise.
MAINTAINER: This document is maintained solely by Ronald Gage ([email protected]). He can be contacted at the above mentioned email address or via standard US Mail at: Ron Gage 527 Ruby Street Saginaw, Michigan 48602
CONTRIBUTORS: This is a living, community-based document. As such, there are members of the community who have contributed to the growth of this document. These people are listed below: CONTRIBUTIONS: If you wish to contribute to the growth of this document, you are absolutely welcome to do so. Any positive, constructive contribution is welcome. Please send your contributions to the maintainer of this document.
REVISION HISTORY: As this is a living document, it will grow as it is utilized. This growth is enumerated below: v0.0.1 - 11-Mar-2001 Initial Release - R. Gage
--------------------------------------- CERTIFICATION or USE OF OIC PROTOCOL: Any vendor or creator of a product or device is welcome to make use of this specification for any purpose, commercial or otherwise. This protocol is a truely open protocol - it is licensed strictly based on compliance with the protocol. There is no fee of any sort for using this protocol in any way, shape, or form. Any claim of compliance to the OIC protocol may only be made after the product in question has been certified as compliant by the maintainer of this document of by any person or organization designated by the maintainer.
-----------------------------------------------------------
SPECIFICATION: 1. Physical Media OIC is to support either Ethernet or Serial Communications and preferably both. Ethernet support shall be via standard ethernet connectors only utilizing an RJ-45 type connector. This connector shall be wired to allow only standard "cat-5" cables to be utilized to allow the device to connect to a standard Ethernet hub. Ethernet support shall include 10 Megabit per second speeds and may also include 100 Megabit per second speeds. Serial Communications shall be via standard RS-232. This shall be via a standard DB-9 serial connector. This DB-9 connector shall be wired to accomidate a standard null-modem type of cable (DTE configuration). The connector on the equipment side shall be "male" in gender. All Serial Communications shall be with an 8 data bits, 1 stop bit, no parity configuration. At a minimum, serial communications shall support 2400 baud, 9600 baud, and 38400 baud. All other "standard" speeds are optional. Serial communications shall default to 38400 baud unless specifically changed by the implementer. Support for RS-422 and RS-485 type of communications shall only be provided via add-on devices. OIC may not be supported via a proprietary fieldbus (e.g: Profibus, ControlNet, Modbus Plus, etc...) unless the access to that fieldbus is completely and freely open and documented and without cost. By completely and freely open and documented, I am referring to fully publishing the communications specification for the communication card needed to utilize the fieldbus in question. For example, if Modicon wishes to implement OIC over Modbus Plus, they must publish full programmers specifications for their SA-85 interface board openly, without restrictions, and without cost. 2. Communications All communications is point to point. No broadcasting or multicasting allowed All multibyte data (except strings) is to be transmitted in network byte order (htons, ntohs type of functions). All strings to be transmitted are to be transmitted in a literal byte for byte order. All strings must be null (0x00) terminated. The following datatypes are defined: Byte (0-255) unsigned 8 bit Short (0-65535) unsigned 16 bit Int (-32768 - 32767) signed 16 bit Long (0-4.2 billion) unsigned 32 bit LInt (-2.1 billion - 2.1 billion) signed 32 bit float IEEE 32 bit float 3. Packet Only one command may be transmitted per packet. The command communications packet shall be laid out as follows: Short COMMAND; Long PACKET_ID; Long COMM_ID; Byte STRING[16]; Short LENGTH; Byte DATA... The response communications packet shall be laid out as follows: Short STATUS; Long PACKET_ID; Long COMM_ID; Byte STRING[16]; Short LENGTH; Short CRC; Byte DATA... Definations: COMMAND - The command being transmitted to the device. See section 4 for more details on this value. STATUS - Did the command execute correctly (STATUS = 0), otherwise is equal to a pre-defined error message. See section 5 for more details on this value. PACKET_ID - a continuously incrementing value that indicates message transmission order. Used for duplicate message detection and for matching replies to commands. COMM_ID - a 32 bit value returned from the device. This is used by the device to identify the communications source. The communications source shall request this value from the device at the beginning of each communications session and shall be re-used throughout the entire communications session unmodified. STRING[16] - a 16 byte value of arbitrary value. It is not used for any purpose within the device. The device simply copies all 16 bytes from the command packet back into the response packet. LENGTH - the length, in bytes, of the data section of the packet. CRC - a CRC-16 calculation of the data section. DATA - the response data. Shall not be included if the command did not execute correctly (STATUS != 0)
-- Ron Gage - Saginaw, MI ([email protected]) _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
-------------------------------------------------------
Open Industrial Communications Specification Proposal v0.0.1
Copyright - 2001 by Ron Gage, Saginaw Michigan
This document protected by United States Copyright Law.
PURPOSE: This document is to detail the Open Industrial Communications (OIC) protocol. This detail is to be fully explained in "laymans" terms and in an unambiguous manner. The entire protocol is to be fully documented and shall have absolutely no hidden or "proprietary" provisions about it. It is not the purpose of this document to infringe on any company or individual's intellectual property rights, be they patented or otherwise.
MAINTAINER: This document is maintained solely by Ronald Gage ([email protected]). He can be contacted at the above mentioned email address or via standard US Mail at: Ron Gage 527 Ruby Street Saginaw, Michigan 48602
CONTRIBUTORS: This is a living, community-based document. As such, there are members of the community who have contributed to the growth of this document. These people are listed below: CONTRIBUTIONS: If you wish to contribute to the growth of this document, you are absolutely welcome to do so. Any positive, constructive contribution is welcome. Please send your contributions to the maintainer of this document.
REVISION HISTORY: As this is a living document, it will grow as it is utilized. This growth is enumerated below: v0.0.1 - 11-Mar-2001 Initial Release - R. Gage
--------------------------------------- CERTIFICATION or USE OF OIC PROTOCOL: Any vendor or creator of a product or device is welcome to make use of this specification for any purpose, commercial or otherwise. This protocol is a truely open protocol - it is licensed strictly based on compliance with the protocol. There is no fee of any sort for using this protocol in any way, shape, or form. Any claim of compliance to the OIC protocol may only be made after the product in question has been certified as compliant by the maintainer of this document of by any person or organization designated by the maintainer.
-----------------------------------------------------------
SPECIFICATION: 1. Physical Media OIC is to support either Ethernet or Serial Communications and preferably both. Ethernet support shall be via standard ethernet connectors only utilizing an RJ-45 type connector. This connector shall be wired to allow only standard "cat-5" cables to be utilized to allow the device to connect to a standard Ethernet hub. Ethernet support shall include 10 Megabit per second speeds and may also include 100 Megabit per second speeds. Serial Communications shall be via standard RS-232. This shall be via a standard DB-9 serial connector. This DB-9 connector shall be wired to accomidate a standard null-modem type of cable (DTE configuration). The connector on the equipment side shall be "male" in gender. All Serial Communications shall be with an 8 data bits, 1 stop bit, no parity configuration. At a minimum, serial communications shall support 2400 baud, 9600 baud, and 38400 baud. All other "standard" speeds are optional. Serial communications shall default to 38400 baud unless specifically changed by the implementer. Support for RS-422 and RS-485 type of communications shall only be provided via add-on devices. OIC may not be supported via a proprietary fieldbus (e.g: Profibus, ControlNet, Modbus Plus, etc...) unless the access to that fieldbus is completely and freely open and documented and without cost. By completely and freely open and documented, I am referring to fully publishing the communications specification for the communication card needed to utilize the fieldbus in question. For example, if Modicon wishes to implement OIC over Modbus Plus, they must publish full programmers specifications for their SA-85 interface board openly, without restrictions, and without cost. 2. Communications All communications is point to point. No broadcasting or multicasting allowed All multibyte data (except strings) is to be transmitted in network byte order (htons, ntohs type of functions). All strings to be transmitted are to be transmitted in a literal byte for byte order. All strings must be null (0x00) terminated. The following datatypes are defined: Byte (0-255) unsigned 8 bit Short (0-65535) unsigned 16 bit Int (-32768 - 32767) signed 16 bit Long (0-4.2 billion) unsigned 32 bit LInt (-2.1 billion - 2.1 billion) signed 32 bit float IEEE 32 bit float 3. Packet Only one command may be transmitted per packet. The command communications packet shall be laid out as follows: Short COMMAND; Long PACKET_ID; Long COMM_ID; Byte STRING[16]; Short LENGTH; Byte DATA... The response communications packet shall be laid out as follows: Short STATUS; Long PACKET_ID; Long COMM_ID; Byte STRING[16]; Short LENGTH; Short CRC; Byte DATA... Definations: COMMAND - The command being transmitted to the device. See section 4 for more details on this value. STATUS - Did the command execute correctly (STATUS = 0), otherwise is equal to a pre-defined error message. See section 5 for more details on this value. PACKET_ID - a continuously incrementing value that indicates message transmission order. Used for duplicate message detection and for matching replies to commands. COMM_ID - a 32 bit value returned from the device. This is used by the device to identify the communications source. The communications source shall request this value from the device at the beginning of each communications session and shall be re-used throughout the entire communications session unmodified. STRING[16] - a 16 byte value of arbitrary value. It is not used for any purpose within the device. The device simply copies all 16 bytes from the command packet back into the response packet. LENGTH - the length, in bytes, of the data section of the packet. CRC - a CRC-16 calculation of the data section. DATA - the response data. Shall not be included if the command did not execute correctly (STATUS != 0)
-- Ron Gage - Saginaw, MI ([email protected]) _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc