First attempt at an open communications standard

G
> 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 -- [email protected] -- (713) 869-6876 _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
A

Andrew Kohlsmith

> 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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
A

Andrew Kohlsmith

> 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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C
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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
A

Andrew Kohlsmith

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 [email protected] 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 ([email protected]) _______________________________________________ LinuxPLC mailing list [email protected] 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 <[email protected]> Q: Why did the chicken cross the Moebius Strip? A: To get to the other... um... er... --r.h.f.r _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
A

Andrew Kohlsmith

> 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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C
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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C
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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Johan Bengtsson

About null modem cable or not (this don't really have much with the discussion to do, but anyway) &lt;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 &lt;/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: [email protected] Internet: http://www.pol.se/ ---------------------------------------- _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Johan Bengtsson

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: [email protected] Internet: http://www.pol.se/ ---------------------------------------- _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
P

Peter Whalley

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 [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Johan Bengtsson

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: [email protected] Internet: http://www.pol.se/ ---------------------------------------- _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Top