First attempt at an open communications standard

R

Thread Starter

Ron Gage

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
 
Ron Gage wrote: > 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. One thing to consider is that there's considerable momentum behind existing protocols, and it may be more advantageous to make use of one of them rather than creating an entirely new one. > CERTIFICATION or USE OF OIC PROTOCOL: This section will need a lot more thought about what it means to have a community-based protocol. Ideally one would not want one person to be a designated certifier-in-chief or anything - but I've little idea how to fix this. ... > 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. This bit should be checked against the original RS-232 standard - at the very least the DB-9 connector is not part of RS-232, and the gender etc of everything is also specified. We should note where the spec differs from the standard. > 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... I'd suggest rearranging this for the sake of alignment - put the two shorts next to each other. > Definations: > 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. Isn't this rather a lot? Why not make it another Long, like COMM_ID ? > CRC - a CRC-16 calculation of the data section. Why not of the entire packet? Also, it may be easier if the CRC is at the end, so that packets can be generated on-the-fly. > DATA - the response data. Shall not be included if the command did not > execute correctly (STATUS != 0) Why not? It can contain error details... (LENGTH will be 0 if no details are known) Jiri <[email protected]> _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
B

Bob Peterson

Ron Gage wrote: > > 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. > Why not allow for fiber based ethernet? or thin cable? > > 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. > I don't like DB9 connectors in Industrial settings. I'd scrap this requirement. > 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. > don't force people into certain speeds. certain cheaper units may be able to run only at low baud rates, which may be quite adequate for the purpose. > > Support for RS-422 and RS-485 type of communications shall only be provided via add-on devices. > Why? > 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 > What good is it if it is only point to point? it needs to have the capability of talking to more then one thing at a time. > > 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 > I'd add dp fp as well. 32 bit FP does not always have adequate precision for things I am doing and sometimes I end up with a kludge. why limit it? > 3. Packet > > Only one command may be transmitted per packet. > why? if you can pack several commands into a single packet why not allow it? > 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... > Say i want to read some data from data memory? how do i do this? need to have a command byte plus some kind of auxilliary data to give the responding unti a clue what you want. this should be done in a string for ease of debugging. Command STRING (16)??? That way you could request a read of a data address in the command byte and the command string would tell you what addresses to read. > 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) Bob Peterson _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Hi, I have a list below of the things that could/should be added to this standard. [[[[ I would still like to have SOMEBODY design a very simple parallel port interface board. ]]]] Hugh 1. Security?????? At least simple passwords. 2. Defined operation states, with references to network operation. For example, Server: (sensors or remote IO) initializing - setting up internal operations waiting - a socket is ready to 'accept' connections negotiating - a connection was made, the client is logging in. failure disconnects and goes to waiting state connected - the connection is now valid, processing commands and updating IO connection broken - shutting down services for that connection then goes to waiting state Client: (for the controller - for each IO address) initializing - setting up internal operations connecting - trying to 'connect' to remote IO negotiating - passing security information. failure moves to the failed state setup - pass commands that define the IO requirements connected - wait to send and receive IO information connection broken - return to connecting state failed - something serious happened 3. If there are multicast commands it will be easier to search for unknown nodes on the network, and do emergency shutdowns. 4. It would also be beneficial to have large message packets for passing between controllers, or to data oriented IO points. 5. A clear list of commands and responses would help. For example 0x01 - change IO value 0x02 - get IO value etc... 6. Each network node should contain ALL of its own relevant device information, and be able to pass this over the network by command. This would eliminate the need for additional device information/driver files. 7. How are the connections to be managed? Are they to be RPC or an open TCP/IP socket? 8. Can there be multiple connections to devices? If so how will this be resolved unless RPC is used? _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
On Monday 12 March 2001 03:27, you wrote: > > 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 > > Why not allow for fiber based ethernet? or thin cable? From my way of thinking, I wanted something common. In the many plants I have been in (that even utilized Ethernet on the floor), fiber was reserved for a "backbone" and 10BT was used to reach the floor equipment. As for thin cable (10Base2??), does anyone even use this anymore? I know I haven't seen it used in quite some time... > > 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. > > I don't like DB9 connectors in Industrial settings. I'd scrap this > requirement. The idea I am chasing here is to have a simple, easy to deal with standard. My perspective is mostly from an equipment servicing person's perspective. I can tell you with absolute certainty that everytime a "new" connector is utilized (micro-din, rj-45, screw terminals, etc...) for simple rs-232 communications, your service people really hate it. Plus, there is no standard way to wire these "new" connectors so that makes your service people have to carry 6 or more cables (with the same connector no less). Besides, with using a DB-9 connector, I can walk into just about any Radio Shack in the world and get the parts I need to make a new cable - now. I cannot do that with any other "industrial" connector. > > > 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. > > don't force people into certain speeds. certain cheaper units may be able > to run only at low baud rates, which may be quite adequate for the purpose. > Again, from the field service perspective. Keep things simple. 2-3 baud rates at a fixed field config is easier to figure out when you are walking up to an unknown machine. You have 3 choices and that's it. > > Support for RS-422 and RS-485 type of communications shall only be > > provided via add-on devices. > > Why? Because there is no standard way to wire these interfaces up. > > > > 2. Communications > > > > All communications is point to point. No broadcasting or multicasting > > allowed > > What good is it if it is only point to point? it needs to have the > capability of talking to more then one thing at a time. Multiple communication sessions take care of this. I just don't want to get into using UDP and all the headaches that brings in. > > 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 > > I'd add dp fp as well. 32 bit FP does not always have adequate precision > for things I am doing and sometimes I end up with a kludge. why limit it? > I wasn't sure if this would be needed. I'll probably add this. > > 3. Packet > > > > Only one command may be transmitted per packet. > > why? if you can pack several commands into a single packet why not allow > it? Simplicity (again). Makes it a world easier (at least at first anyhow) to decode the 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... > > Say i want to read some data from data memory? how do i do this? need to > have a command byte plus some kind of auxilliary data to give the > responding unti a clue what you want. this should be done in a string for > ease of debugging. Exactly. You would issue a read memory type of command, and in the data field, you would specify the address you want to read and how many "units of data" you wanted to read. > > Command STRING (16)??? > > That way you could request a read of a data address in the command byte and > the command string would tell you what addresses to read. > The STRING field is just provided to mimic a simular field found in the ControlLogix packet (they call it "Context"). I believe Modbus also has something like this but much shorter (like 2 bytes). -- Ron Gage - Saginaw, MI ([email protected]) _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
A

Andrew Kohlsmith

> Here it is, version 0.0.1 of what I am calling OIC - Open Industrial > Communications. It is a written spec, not code. There are a lot of people giving their opinion on the technical merits already and it's too early in the morning for me to tackle you on technical merits so I'll cut to what caught my eye first: > 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. This will *never* happen and this paragraph would kill the entire OIC movement's introduction into legacy systems. If I want to embed OIC through MyIndustrialNet(tm)(c)(pat. pend.) I need to open up my spec? Just because it's a tunnel for OIC? Forget it. There should be no reason for this and it strongly mimics the virulent nature of the GPL... but for no good reason. > It is basically an attempt to get the discussion rolling. It is completely > open to discussion by anyone and everyone. I agree and it certainly has gotten discussion rolling. I'll be back later to wrestle with you on my opinion of the technical issues. :) Regards, Andrew _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Hugh Jack wrote: > Hi, > > I have a list below of the things that could/should be added to this standard. [[[[ I > would still like to have SOMEBODY design a very simple parallel port interface board. > ]]]] > > Hugh Hi Hugh I agree that we had three threads crossed in that discussion. Would people wanting to do hardware projects please ID the one they (or more) they are going to proceed on? Thanx cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
A

Andrew Kohlsmith

> I agree that we had three threads crossed in that discussion. Would people wanting to > do hardware projects please ID the one they (or more) they are going to proceed on? Alright -- I'm Andrew Kohlsmith. I do research and development at Benshaw Canada (www.benshaw.com) and I am the designer of the RediStart Digital soft starter. I'd done up an old 8255 driver card YEARS ago (ISA interface) because I got sick and tired of not having enough I/O on my computer. Now the 8255 driver that was desired by the list (as I understand it): - optically isolated inputs (24V AC/DC) and optionally 240VAC - high voltage drivers for outputs (ULN2003A-type, Open Collector), optionally optically/relay isolated? What I haven't worried about until now is the PC interface: how would you like it? ISA, PCMCIA, PC-104? I haven't done any PCI design but there are hordes of PCI glue chips I could do. If we're doing ISA or PC-104 what kind of port configuration do you want? I've done some PnP but really it's not that difficult, I just need to know what you guys want as a whole. How many I/O? Each 8255 can get you 24 I/O in your choice of three (basic) flavours: straight I/O, interrupts and control lines. The 8255 has three 8-bit ports but IIRC (gotta get the datasheet out) there are some restrictions as to which can be input and which can be output in some configurations. The board I designed long ago was used for straight I/O and supported 3 8255s (just because I got sick and tired of soldering all the wires. :) Regards, Andrew _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Hi All I think I got it figured out. I think there's some confusion on the term "parallel port card" Andy, (may I call you Andy? ) is thinking about parallel port as in 8255 a general parallel port for, I believe an 8080 processor. What others are talking about is parallel port as in PC printer port. Did we have someone volunteering to do a lpt->industrial (24 V) card? Or am I simply more confused than usual? Regards cww And we're in the wrong thread!!!???!!! _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
A

Andrew Kohlsmith

> I think I got it figured out. I think there's some confusion > on the term "parallel port card" Andy, (may I call you Andy? ) > is thinking about parallel port as in 8255 a general parallel > port for, I believe an 8080 processor. What others are talking > about is parallel port as in PC printer port. DId we have > someone volunteering to do a lpt->industrial (24 V) card? Well between myself and Ken Irving I think we've figured that there is a need for some kind of digital I/O module. He (and others) would like to see it plug into the parallel (LPT) port of a standard PC; Personally I'd rather use RS232 and ModBUS. Also there should (should there?) be provision to plug in and be able to do Ethernet or USB? If so I think that a bare bones I/O card would work something like this: - Parallel interface (8-bit wide data port, 8-bit wide control port and a few control lines - R/W, CS and address) - one or more 8255 (or equivalent) general purpose I/O chips - 24V (AC/DC) optically-isolated inputs, optional 240VAC - high voltage (open collector) outputs based on something like the ULN2003A, optional relay/opto output If it's done that way I believe that all expectations can be met. The Ethernet controller would just be able to address this as an 8-bit device on its bus. Serial (RS232/RS485) could either use an 8-bit uC port or a shift register. USB is also possible. The base device would be totally protocol independent then as well. What do you all think? Doing the base system this way it actually makes the board cheaper and more versatile. I'll draw up a quick block diagram and put it on my website (http://www.mixdown.org/~andrew/ioboard) later tonight or tomorrow. Regards, Andrew _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Johan Bengtsson

Others have provided some rather good opinions about this already, and instead of repeating them I try to focus on what other have not said: RS232, is this good enough for industrial control in a noisy environment? Does it have to be? Would it not be better to use RS422 (or RS485) and do a spec on the parts that lacks a good enough spec? Someone suggested fiber, I really like that as an option, no way to disturb that one.... How do you plan to communicate with more than one device? one serial connector to each? I would probably not like that idea much, some kind of bus system and thereby adressing is probably needed, unless I have completely missed what the purpose of the protocol is of course. Why would you like PACKET_ID to be that big? make it a byte at most, in that way you can be quite sure everyone handles a wrap around in a good manner, a long is big enough for some people to not find a fault here (does someone remeber Y2k?) and a byte gives you 256 unique values, enough to always know where you are even when a wrap occurs. STRING isn't 16 bytes a little waste just to copy around, 16 bits could have been acceptable I think? /Johan Bengtsson ---------------------------------------- P&L, Innovation in training Box 252, S-281 23 H{ssleholm SWEDEN Tel: +46 451 49 460, Fax: +46 451 89 833 E-mail: [email protected] Internet: http://www.pol.se/ ----------------------------------------
 
G
Ron, I'm all for public RFC's (requests for comment) and public design discussions, but I'd like to see a section of the document that describes the problem or problems for which the proposed protocol is intended to be a solution. Is "open-ness" its only reason for being, or does it address technical shortcomings of other protocols? Is it meant to be a simple binary protocol optimized for data collection from PLC memory? Or is it meant to be a configurable and customizable protocol that can be fitted to particular industry segments? Do you plan for it to be something we could use to manage the configuration of IEDs in the power industry? A simple alternative to Modbus? Something I could use to communicate with an SP88.1 batch control processor? Something particularly suited to communication over slow noisy serial lines in the oilpatch? A clear statement of purpose and a set of design goals and constraints would let me know if we're on the same page, or even part of the same conversation. At the moment, your primary design goals seem to be: 1. develop a protocol that is trivially simple to code. 2. develop a protocol whose physical layer is trivially simple to maintain. I see no point in aiming for trivial code. Since this is an open project, it only has to get done right one time, after which the working code is published and everybody has it, whether they could have written the code themselves or not. And in my world, a specification for data communication is separate from the specification of the physical and transport layers. I have no objection to making hardware maintenance simple, but if your primary goal is never to use any cabling other than twisted pair with DB-9 connectors, why are you specifying the message format? Regards, Greg Goodman Chiron Consulting [email protected] _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Hi Greg: On Tuesday 13 March 2001 23:29, you wrote: > Ron, > > I'm all for public RFC's (requests for comment) and public design > discussions, but I'd like to see a section of the document that describes > the problem or problems for which the proposed protocol is intended to be a > solution. > > Is "open-ness" its only reason for being, or does it address technical > shortcomings of other protocols? Open-ness AND a complete lack of intellectual property concerns. I think it's important to avoid any lawsuit avenue where possible. > At the moment, your primary design goals seem to be: > > 1. develop a protocol that is trivially simple to code. > > 2. develop a protocol whose physical layer is trivially simple to > maintain. > > I see no point in aiming for trivial code. Since this is an open project, > it only has to get done right one time, after which the working code is > published and everybody has it, whether they could have written the code > themselves or not. I guess that I see absolutely no purpose to embrace a "complexity for complexity's sake" approach. I tend more to believe along the lines "all other things being equal - the simplest answer to a question tends to be the best answer to a question". I see absolutely nothing wrong with "trivially simple" code that is "trivially simple" to maintain. It DOES tend to reduce the debugging effort quite a bit. > And in my world, a specification for data communication is separate from > the specification of the physical and transport layers. I have no > objection to making hardware maintenance simple, but if your primary goal > is never to use any cabling other than twisted pair with DB-9 connectors, > why are you specifying the message format? Reference the ControlNet Specification, Version 2 Errata 2. The first couple of chapters relate to the physical media used for transporting the protocol. There is also discussion in that spec that concerns "electrical" specs including such things as current limiting, impedance, and rise-time control. It is only from chapter 4 (to chapter 10) that the actual protocol is discussed. This has been (to date) my only exposure to a real live "full specification" so I thought it appropriate to include both physical and communications specs in the same overall spec. -- Ron Gage - Saginaw, MI ([email protected]) _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Johan Bengtsson

Ok, I somehow missed the purpose of the protocol, sorry /Johan Bengtsson ---------------------------------------- P&L, Innovation in training Box 252, S-281 23 H{ssleholm SWEDEN Tel: +46 451 49 460, Fax: +46 451 89 833 E-mail: [email protected] Internet: http://www.pol.se/ ---------------------------------------- -----Original Message----- From: MIME :[email protected] [SMTP:MIME :[email protected]] Sent: Wednesday, March 14, 2001 4:53 AM To: Johan Bengtsson Subject: RE: LinuxPLC: First attempt at an open communications standard [email protected] wrote: > >Others have provided some rather good opinions about this >already, and instead of repeating them I try to focus on >what other have not said: >RS232, is this good enough for industrial control in a >noisy environment? Does it have to be? Would it not be >better to use RS422 (or RS485) and do a spec on the parts >that lacks a good enough spec? RS-232 is envisioned (by myself anyhow) as a "programming terminal interface". I wouldn't even think of using it for anything robust like inter-PLC communicaitons or MMI's or data collectors. RS422/485 are just not common enough to go on (quick, how many different ways have you seen for wiring a 422 or 485 connector? How many different connectors have you seen for 422/485?) RS-232 is plenty good enough for programming terminal applications, plus it's cheap, common, and standardized. >Someone suggested fiber, I really like that as an option, Is there such a thing as a standard fiber connector? For a laptop? >no way to disturb that one.... >How do you plan to communicate with more than one device? >one serial connector to each? I would probably not like >that idea much, some kind of bus system and thereby >adressing is probably needed, unless I have completely missed >what the purpose of the protocol is of course. I guess I wasn't clear on this point at all.... RS-232 is envisioned as STRICTLY a programming port. Ethernet is envisioned as both a programming port and a networking port. I suppose if you were a glutton for punishment, you could use the RS-232 port as a networking port somehow (rs-232/rs485 adaptor) but why bother. Ethernet hardware is cheap, common, and worlds faster than anything you could hope to achieve under RS232/485. >Why would you like PACKET_ID to be that big? make it a byte >at most, in that way you can be quite sure everyone handles >a wrap around in a good manner, a long is big enough for some >people to not find a fault here (does someone remeber Y2k?) >and a byte gives you 256 unique values, enough to always know >where you are even when a wrap occurs. Going off of what others in the industry use. AB uses 32 bits for a packet-id (DF1, ControlNet and Ethernet/IP), Modicon uses 16 bits(Modbus RTU). 32 bits seems to be the direction of the "forward thinkers" in the industry from what I can see. >STRING >isn't 16 bytes a little waste just to copy around, 16 bits could >have been acceptable I think? A mimic of what AB is doing with the Ethernet/Industrial Protocol (ControlNet over Ethernet) as implemented with the ControlLogix PLC (ref. Controlnet protocol reference Rev 2 Errata 2, Section 4, table 4-41, field name Sender Context). They use 8 bytes, I used 16 bytes - hense we would be "twice as capable" as AB. :) ----- Ron Gage - Saginaw, MI ([email protected]) _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Hi all For what it's worth, I agree with Ron that basic, simple, and open are virtues not to be dismissed lightly. Well understood is the gateway to reliable. If we make it extensible and it's reasonably easy to understand and hack, it will grow to meet the challanges. Since it's to be GPL'd (I assume) we will get those changes back. There are already two types of network protos used in automation. Too secret, so nobody really knows what they do. And huge behemoths that try to be all things to everybody and are so complex that nobody really wants to know what they do. The reason that ancient old modbus is still popular is that it does enough and is relatively well understood. If we make supporting I/O well the initial goal, we don't need a complex proto. If we add a generic memory block transfer mechanism, we can support the great majority of needs without bloat. You have to keep in perspective that TCP/IP does a lot for you. We don't even really need to checksum or order packets (unless you don't trust the host programming) because TCP/IP is classed as reliable transport. That's why, if we USE what we get with the Linux platform we can do a lot with a little and retain elegant simplicity. Even Modbus, as simple as it is, has a lot that is redundent when tunneled through TCP/IP . By using TCP/IP we have 95% of what is needed already coded, tested and proven reliable by millions of users. The commercial guys need to reinvent all the features that Linux programmers accept and take for granted and have used succesfully for years without a second thought. Of course, there are some limitations, but every commercial protocol has limitations also. The difference is that the limitations of TCP/IP are well known and workarounds are also well known. NONE of the commercial offerings will _ever_ have this level of testing and scrutiny. All we really need to support I/O is a length and data, The addressing is handled by IP, the checksummiong and ordering are handled by TCP. Both ends have to know what the data means but that's true of any protocol.. So we add a clue like a type byte that tells us we are talking to I/O or doing a memory transfer. A good driver should interact with the stack and use the mechanisms there for error detection and reporting. Why _everybody_ wants to reinvent all that is beyond me. The only reason is that they feel they must have total ownership and control. More reliable data is transferred with TCP/IP every day than has been transmitted by all automation protocols ever. Just the perspective of an old UNIX hacker who watches people reinvent what we have been using for years.........and reinvent it badly. Regards cww PS Remember who _really_ invented the internet. _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Top