Today is...
Wednesday, July 26, 2017
Welcome to the Modbus Community, about
the world's leading automation protocol.
First attempt at an open communications standard
Here it is, version 0.0.1 of what I am calling OIC - Open Industrial Communications. It is a written spec, not code. ...

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 (ron@rongage.org). 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 (ron@rongage.org) _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org 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 <jiri@baum.com.au> _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Bob Peterson on 12 March, 2001 - 10:17 am

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 LinuxPLC@linuxplc.org 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 (ron@rongage.org) _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Andrew Kohlsmith on 14 March, 2001 - 4:52 pm

> 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... I like this idea, but for different reasons. Using Category 5 (minimum), 10bT/100bT-style cable will also allow for powering nodes with the cable. This could be a very attractive option. Regards, Andrew _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Hugh Jack on 12 March, 2001 - 3:57 pm

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 LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Andrew Kohlsmith on 13 March, 2001 - 3:58 pm

> 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. > ]]]] I'm working on it. :-) Regards, Andrew _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 13 March, 2001 - 3:59 pm

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 LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Andrew Kohlsmith on 13 March, 2001 - 4:06 pm

> 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 LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 13 March, 2001 - 4:53 pm

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 LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Andrew Kohlsmith on 13 March, 2001 - 5:24 pm

> 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 LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Willy Smith on 13 March, 2001 - 4:07 pm

Put me down as lead for the Ethernet I/O module. I have to get permission to work on it from my employer, but I'm hoping this won't be too difficult. Willy Smith _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 13 March, 2001 - 5:26 pm

I can possibly help depending on what you want to do. I did quite a bit on a rack using MachZ as it comes running Linux already and would take less development than most approaches. You're welcome to whatever I've dug up. Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Andrew Kohlsmith on 13 March, 2001 - 11:10 am

> 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 LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By David Nimmons on 13 March, 2001 - 11:11 am

Before starting from scratch, would the ACPLT system from Aachen univerity in Germany provide a suitable framework to build on? _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By David Nimmons on 13 March, 2001 - 3:57 pm

I guess a link might be helpful. http://acplt.plt.rwth- aachen.de/english/welcome.html _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 13 March, 2001 - 5:27 pm

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: johan.bengtsson@pol.se Internet: http://www.pol.se/ ----------------------------------------

By Johan Bengtsson on 14 March, 2001 - 9:58 am

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: johan.bengtsson@pol.se Internet: http://www.pol.se/ ---------------------------------------- -----Original Message----- From: MIME :ron@rongage.org [SMTP:MIME :ron@rongage.org] Sent: Wednesday, March 14, 2001 4:53 AM To: Johan Bengtsson Subject: RE: LinuxPLC: First attempt at an open communications standard johan.bengtsson@pol.se 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 (ron@rongage.org) _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Greg Goodman on 14 March, 2001 - 2:55 pm

> 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. I take this to mean that your protocol is not for use in any environment where you can't run ethernet cable. We can't use it to communicate with wellhead pump-off controllers via radiomodem, or with SCADA components on satellite offshore drilling rigs. We can't use it in a pipeline's unmanned custody transfer stations, which report their data periodically by modem dial-out. We can't even use it to communicate sensor data from the top of a transmission tower to the SCADA system at the tower's base, since running cable up the tower is prohibitively expensive, and short-haul modems are a common solution. Or have I misunderstood your constraint? -- Greg Goodman -- Chiron Consulting -- chironsw@swbell.net -- (713) 869-6876 _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 14 March, 2001 - 5:23 pm

We would also support Modbus which is entrenched in many markets and used quite often in those situations. Our first choice would be a free and open proto but, since modbus is documented and available to us, why not use it for the special stuff. We can do friendly open, free protos that cover the bulk of applications. The really special hardware will probably never support our proto anyway Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Andrew Kohlsmith on 14 March, 2001 - 4:51 pm

> 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.... Well aside from bending the fiber too much or cracking it. :-) You are (inadvertently) explaining why I want to keep this modular: No one man can figure everything out. By presenting a fairly generic internal interface anyone can make anything talk to the unit. And, if the communications board can be kept small enough, it can fit right in the box and appear to have been made for that communications layer. :-) > 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. That's addressed by the communications module. The (default, unless someone else can sway me otherwise) communications method will be RS485/ModBUS through a pair of screw terminals. If you would like something else you're more than welcome to make or persuade me (or anyone) to make the appropriate connector and interface. That won't distrub the I/O module on its own. I have updated the "standard" I/O board page. I hope to make the drawings clearer within the next few days. Please let me know what you think. http://www.mixdown.org/~andrew/ioboard.html Regards, Andrew PS - I realize that this message was about the protocol instead of the I/O module but you raised some good points for the I/O module as well. _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Greg Goodman on 14 March, 2001 - 9:44 am

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 chironsw@swbell.net _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org 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 (ron@rongage.org) _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 14 March, 2001 - 10:35 am

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 LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Todd Lyons on 19 March, 2001 - 9:48 am

Curt Wuollet wrote: > 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 Since I'm in a slightly different field than most of you (AC/DC drives and controls), the answer to this "two types" is not known to me. I usually only get to see AC and DC drives of all manufacturer types, and the only thing I ever work on that's distributed would be Profibus on Yaskawa drives. Are you talking about DH+? > PS Remember who _really_ invented the internet. Gore's here? -- Blue skies... Todd | Get a bigger hammer! | Two things prevent you from having | | http://www.mrball.net | sex with women: sunlight & sobriety | | http://faq.mrball.net | --Tom Leykis | _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 19 March, 2001 - 9:51 am

Hi Todd I hate to mention names as I get nastygrams but in general, if you can't get the complete spec it's one. And if the spec is an inch or more thick, it's the other. Let's take an example: modbus. Modbus is one of the best known and has been used for more stuff than you can believe. It's probably the most "open". ( you don't need a $30,000 membership to see some specs.) But even this has secret add-ons and parts. Profibus might be a good example of the other. Several types, aims at soup to nuts. By using TCP/IP transport we can achieve what we need for the great majority of uses with elegant simplicity. With elegant simplicity and total openness, it can be tailored for special needs if required. There are only two uses that I would deem significant at the present. Running I/O and data interchange between intelligent processors. And if it came down to it, I would rather see an efficient simple easy to implement proto for each than twisting and perverting one to do everything. socket to socket is already provided for us. all we need to worry about are data frames. Let's call them lightweight protos. No custom silicon, maximum use of what is standard already. Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Andrew Kohlsmith on 14 March, 2001 - 5:26 pm

Okay I'm here to debate/criticize the spec. :-) > 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. One of my main arguements you will notice along this message is "what does this have over ModBUS? It's been opened, is freely usable by anyone (unless I am horribly mistaken) and provides practically everything this protocol specification suggests that OIC should do. > OIC is to support either Ethernet or Serial Communications and preferably > both. So OIC is to be both a networking and a programming protocol? > 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. Is RJ45 good enough? I've seen several "ring-screw" style RJ45 adapters -- will this ever be required? PLCs and most networkable I/O equipment has its cables pretty much protected so I am just raising a concern here as more of an open question than a criticism. Also what kind of electrical protection will be required? Fuses, MOVs or TVSs across the lines to prevent the entire network from being blown to hell if this thing comes across 480V fed from a 10MVA transformer? What about providing a single protection point for each enclosure or MCC? i.e. network cable goes into the protective device and then another cable comes out to go to the MCC's hub? Or even protection within the hub itself? > 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. If the serial port is only for programming PLEASE rethink this. It should be a FEMALE, DCE-wired port. The COMPUTER or PROGRAMMER is the DTE in this case. Requiring a Null modem cable and a gender bender is only going to cause headache after headache. Trust me on this; Benshaw's 232 communications card decided to call the starter DTE as well even though the only thing talking to it would be a computer for configuration. It's called a Royal Pain in the Ass. > 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. Why not autobaud anything between 2400 and 115200? Or any other limit? > Support for RS-422 and RS-485 type of communications shall only be provided > via add-on devices. Makes perfect sense if the port is to be used primarily as a programming port. > 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. I had already raised concerns about this in an earlier email. I'm still a little leary on this but we'll see how it pans out as this spec grows. :-) > All communications is point to point. No broadcasting or multicasting allowed Why? Why not allow broadcasting to find new devices and allow autoconfiguration? > 3. Packet Okay here's where I start wondering what's going on... is this a base protocol or does it fly over TCP/IP? I thought it was the latter. If it is the latter, what's wrong with using standard ModBUS over TCP/IP instead of redefining everything? > Only one command may be transmitted per packet. Understood and I like this requirement. It helps keep a single unit from hogging the link. Even bulk transfers should be limited to the maximum length of one ethernet frame (1500 bytes). Any fragmentation should be handled well before it hits the industrial part of this bus. I left off the last part of the spec (commands and status messages) because I'd like to figure this first bit out first. Regards, Andrew _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

Andrew! On Wednesday 14 March 2001 21:38, you wrote: > Okay I'm here to debate/criticize the spec. :-) Oh joy! :) > > 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. > > One of my main arguements you will notice along this message is "what does > this have over ModBUS? It's been opened, is freely usable by anyone > (unless I am horribly mistaken) and provides practically everything this > protocol specification suggests that OIC should do. See my previous post. The ModBUS falls way short of where we need to be... > > OIC is to support either Ethernet or Serial Communications and preferably > > both. > So OIC is to be both a networking and a programming protocol? Both. With 65000 commands available with the spec (as I laid out), implementing both functions shouldn't be too hard to do. :) > > 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. > > Is RJ45 good enough? I've seen several "ring-screw" style RJ45 adapters -- > will this ever be required? PLCs and most networkable I/O equipment has > its cables pretty much protected so I am just raising a concern here as > more of an open question than a criticism. > > Also what kind of electrical protection will be required? Fuses, MOVs or > TVSs across the lines to prevent the entire network from being blown to > hell if this thing comes across 480V fed from a 10MVA transformer? What > about providing a single protection point for each enclosure or MCC? i.e. > network cable goes into the protective device and then another cable comes > out to go to the MCC's hub? Or even protection within the hub itself? I have no answer here. I'm sure that protection will need to be addressed (eventually). Unfortunately, when you start talking about a 10 Mhz signal (100 Mhz for 100BT), every thing added to the line affect signal quality in non-trivial ways! > > > 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. > > If the serial port is only for programming PLEASE rethink this. It should > be a FEMALE, DCE-wired port. The COMPUTER or PROGRAMMER is the DTE in this > case. Requiring a Null modem cable and a gender bender is only going to > cause headache after headache. Trust me on this; Benshaw's 232 > communications card decided to call the starter DTE as well even though the > only thing talking to it would be a computer for configuration. It's > called a Royal Pain in the Ass. Was thinking of the ports I deal with on a daily basis on AB SLC-500's. The port is a DB-9 Male on the processor and you need to use a Null Modem to communicate. I think we need to find a public concensus on this one as there is no clear direction to go. I do know that I will fight any idea involving the Modicon way of doing serial communications (requiring a cable with special, non-standard jumpering or communications won't work). > > 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. > > Why not autobaud anything between 2400 and 115200? Or any other limit? Two devices autobauding against each other is risky at best. Better to have one of the devices at a fixed baud rate and have the other "go find it". I would argue that the fixed baud rate would belong on the processor. > > Support for RS-422 and RS-485 type of communications shall only be > provided > > via add-on devices. > > Makes perfect sense if the port is to be used primarily as a programming > port. > > > 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. > > I had already raised concerns about this in an earlier email. I'm still a > little leary on this but we'll see how it pans out as this spec grows. :-) > > > All communications is point to point. No broadcasting or multicasting > allowed > Why? Why not allow broadcasting to find new devices and allow > autoconfiguration? Bootp, DHCP suit these purposes just fine. AutoConfig is something best done individually between devices on a specific (manual) trigger. All we need is to have a PPLC device "decide" to auto-reconfig on it's own. A device discovery protocol isn't that hard to do. Could be done off of the internal ARP list on the OS or from a "config" file stored on the HD. > > > 3. Packet > > Okay here's where I start wondering what's going on... is this a base > protocol or does it fly over TCP/IP? I thought it was the latter. If it > is the latter, what's wrong with using standard ModBUS over TCP/IP instead > of redefining everything? > It definately flies over TCP. > > Only one command may be transmitted per packet. > > Understood and I like this requirement. It helps keep a single unit from > hogging the link. Even bulk transfers should be limited to the maximum > length of one ethernet frame (1500 bytes). Any fragmentation should be > handled well before it hits the industrial part of this bus. And it's worlds easier to code to! :) -- Ron Gage - Saginaw, MI (ron@rongage.org) _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Andrew Kohlsmith on 15 March, 2001 - 12:56 pm

> See my previous post. The ModBUS falls way short of where we need to be... Yup I read it and commented on it. To summarize my position: I don't really care if we implement the entire ModBUS spec; I'd just like to be able to address ModBUS devices at the register level without worrying about whether they're ModBUS-compliant or LinuxPLCProtocol compliant.. i.e. the packet structure should be the same and the base-level ModBUS commands (register set / register get, I don't care much for the rest) should be duplicated. > I have no answer here. I'm sure that protection will need to be addressed > (eventually). Unfortunately, when you start talking about a 10 Mhz signal > (100 Mhz for 100BT), every thing added to the line affect signal quality in > non-trivial ways! True but I do believe that this is important... Maybe leave it in the spec that it needs to be discussed or at least explored in greater detail. :-) > Was thinking of the ports I deal with on a daily basis on AB SLC-500's. The > port is a DB-9 Male on the processor and you need to use a Null Modem to > communicate. I think we need to find a public concensus on this one as there > is no clear direction to go. I do know that I will fight any idea involving Agreed. I believe it was Mr. Irving who said that PLCs are usually wired in the DTE manner to facilitate communicating with modems. Personally I rarely see this used (by far the programming port seems to be for laptops) but I do not know the entire industry. I also come from the standpoint that I'm designing the I/O devices and peripherals rather than the PLCs themselves and they have programming ports at times. :-) > > Why not autobaud anything between 2400 and 115200? Or any other limit? > Two devices autobauding against each other is risky at best. Better to have > one of the devices at a fixed baud rate and have the other "go find it". I > would argue that the fixed baud rate would belong on the processor. Why so? The device commanding attention picks the baudrate it wants to speak at, which should be within the legal range. a couple of <CR>s and if there's no response you must obviously be too fast for the other end so lower and try again... > Bootp, DHCP suit these purposes just fine. AutoConfig is something best done > individually between devices on a specific (manual) trigger. All we need is > to have a PPLC device "decide" to auto-reconfig on it's own. Both BOOTP and DHCP are broadcast protocols and you will now require a seperate BOOTP/DHCP server in order to make it work. If you want to do autoconf/etc through BOOTP/DHCP you'll have to have an NFS (or something custom) server... I see it working but also see potential problems. > A device discovery protocol isn't that hard to do. Could be done off of the > internal ARP list on the OS or from a "config" file stored on the HD. True 'nuff. > And it's worlds easier to code to! :) heh. Linux already has a great TCP/IP stack so we might have to bugger with something to prevent packets from being reassembled and used in order to enforce this kind of a limitation. :-) Regards, Andrew _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 15 March, 2001 - 3:07 pm

Hi Andrew I would interject one point. I like Modbus especially the TCP version. But Groupe Schnieder is currently suing OPTO-22 about patent infringement. It's not very germain to this discussion but, I have not seen where GS promises thay will not enforce patents on Modbus. They have published the specs, a big move in the right direction. They out of all the large automation vendors are the only ones with a clue about open, but they retain the right to pull the rug out, unless I am mistaken. This is why we could use our own. Regards cww _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

Andrew Kohlsmith: > If the serial port is only for programming PLEASE rethink this. It > should be a FEMALE, DCE-wired port. The COMPUTER or PROGRAMMER is the > DTE in this case. Requiring a Null modem cable and a gender bender is > only going to cause headache after headache. Trust me on this; Benshaw's > 232 communications card decided to call the starter DTE as well even > though the only thing talking to it would be a computer for > configuration. It's called a Royal Pain in the Ass. To be fair, though, it was most likely the computer that was wired wrong. All IBM PCs and compatibles are wired wrong. To borrow a phrase from the Jargon File, ``some loser didn't understand the RS232C specification and the distinction between DTE and DCE''. Jiri -- Jiri Baum <jiri@baum.com.au> Q: Why did the chicken cross the Moebius Strip? A: To get to the other... um... er... --r.h.f.r _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 19 March, 2001 - 9:52 am

About null modem cable or not (this don't really have much with the discussion to do, but anyway) <rant> Imagine ALL devices wired as a DTE with a male connector and all serial cables where null modem cables - everything would connect to everything with every cable. I personally think it would have been the same for ethernet TP (ok, it's a little bit too late to change that now) if every network port, in a computer as well as a hub/switch/etc was wired in the same way and all ethernet cables where twisted you would never have to worry about that, all cables are twisted - everythin connects to everything without bothering. Think of it </rant> That don't mean I really suggest this in this particular case since the world is what it is, but anyway... /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: johan.bengtsson@pol.se Internet: http://www.pol.se/ ---------------------------------------- _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 19 March, 2001 - 10:22 am

before anyone objects.... of course, when it comes to RS232, anything would of course not understand anything, I wasn't even suggesting that, really... and of course it doesn't work, but that is only because existing equipment isn't wired in that way /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: johan.bengtsson@pol.se Internet: http://www.pol.se/ ---------------------------------------- _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Peter Whalley on 22 March, 2001 - 12:28 pm

Johan The problem with cross over cable schemes comes when you try to use two cables in series in which case you cancel out the cross over and it doesn't work any more. This is a particular problem with fixed cabling systems having multiple patch leads, fly leads, fixed cables etc in series and explains why 10BaseT is not done this way. Regards Peter Whalley _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 22 March, 2001 - 12:31 pm

Well, not if all cables are cross over, with one addition: all cables with the same connector in both ends. if fixed installations (for instance 10BaseT) are cross-over too it would actually work. example: if you have one hub/switch/computer/whatever and want to connect that, thru a fixed cable, to another you will have this: Equpment1 Tx Rx | | \ / X cable between eq. and connector on fixed installation / \ | | Tx Rx Connector on fixed installation | | \ / X fixed installation cable / \ | | Connector on fixed installation Tx Rx | | \ / X cable between connector on fixed installation and eq. / \ | | Tx Rx Equpment2 If you for any really strange reason make a cable with one female and one male connector it should not be crossover for this to work. I think I missed that in my previous post. Summary rule: all cables with one male and one female end = no crossover all other = crossover If it had been done like that no one would have to think any futher about that part. A challenge: find a scheme where this would not work if followed as above. /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: johan.bengtsson@pol.se Internet: http://www.pol.se/ ---------------------------------------- _______________________________________________ LinuxPLC mailing list LinuxPLC@linuxplc.org http://linuxplc.org/mailman/listinfo/linuxplc