Ian McCrum MI5AFL wrote:> I wonder if there is documentation on standard RS485 protocols > anywhere for download? > > I have homebrewed a couple of these in the past but is there a > standard way of doing this?<SNIP>> Tia > Ian McCrumIan, as you can see from the responses there doesn't seem to be a standard. We also have homebrewed a couple. I have placed a zip file in a download area of our web site of a simple protocol we have used a few times. http://www.exotech.com/downloads.htm. I realize this is asking all the NG's old hens to fuss about how it could be better, faster, simpler, etc. But the cost is the same, and I can't remember seeing there offerings. Although I am willing to host any others on the site. Scott
RS485, multidrop protocol
Started by ●November 14, 2004
Reply by ●November 15, 20042004-11-15
Reply by ●November 15, 20042004-11-15
>Ian McCrum MI5AFL wrote: >> I wonder if there is documentation on standard RS485 protocols >> anywhere for download? >> >> I have homebrewed a couple of these in the past but is there a >> standard way of doing this? ><SNIP> >> Tia >> Ian McCrum>On Mon, 15 Nov 2004 11:38:05 -0700, "Not Really Me" <scott@exoXYZtech.com> wrote: >Ian, as you can see from the responses there doesn't seem to be a standard. >We also have homebrewed a couple. I have placed a zip file in a download >area of our web site of a simple protocol we have used a few times. >http://www.exotech.com/downloads.htm. > >I realize this is asking all the NG's old hens to fuss about how it could be >better, faster, simpler, etc. But the cost is the same, and I can't >remember seeing there offerings. Although I am willing to host any others >on the site. > >Scott============================== Thanks Scott, I have downloaded the .zip I'll give it a good looking over. It has been 3 or 4 years since I did my last RS485 network, and it has always been one computer talking to a number of much smaller microprocessors. I always used a four wire system. I'll see if I can dig up the code. I am running a simple RS485 lab past my students at the University and it rekindled my interest, Http://www.eej.ulst.ac.uk/~ian/modules/COM347J1/COM347J1_LAB5.pdf A mate called Pat Sweeney wrote it, the students are only computer science students and have no/little hardware expertise so they just poke a few registers and see a few characters go flying by (at 1 baud!) plus I am getting an ARM board to play with soon 8-) In reply to other posters, is IrDA multi-drop? Actually hacking PLIP or SLIP is fine for point to point, the real physical media is not of too much importance, but getting multiple machines to work is harder. PPP does not use addresses! As a starting point, Jeremy Benthams book on putting TCP/IP on PICs uses a ethernet card driver (for a 3com 3c509) of only 250 lines of C. Might be worth a play. If the interface at a driver level is so simple, e.g in linux then it would be easy to add a simple driver module that pretended to be an ethernet card. The driver code could play pass the parcel to get its message around the network. Even if it meant defeating ARP and using hardwired ARP tables, or frigging with various timeout timers it might be on... 8-))) Ian
Reply by ●November 15, 20042004-11-15
In article <67gfp0dr2na07h75ic7i939d15r2pelcf5@4ax.com>, Ian McCrum MI5AFL <IJ.McCrum@ulster.ac.uk> wrote: -I wonder if there is documentation on standard RS485 protocols -anywhere for download? RS485 is an electrical standard. But that's not what you're talking about. There is no multidrop data link standard. - -I have homebrewed a couple of these in the past but is there a -standard way of doing this? Nope. -I am interested in using the serial port of a linux machine, with -RS485 line drivers/receivers and probably RTS control to effectively -network a number of machines together. OK. - -Two possible applications spring to mind, my own custom (udp) system -or trying to get TCP/IP sort of working, NFS or TFTP booting for -example, I'd accept atrocious performance just for the convenience of -it all. typically only a pair would be busy at once... - -The SLIP and PPP protocols are not multidrop of course. PPP isn't. But SLIP is nothing other than a trivially modified IP packet, which of course is routable. There's no technical reason why you couldn't route addressible packets onto a SLIP link. Run UDP on top of it and voila! a simple and standard multidrop link. However you'd still have to implement a speak when spoken to only duplex protocol on top of this to eliminate collisions. - -It may be possible to modify a TCP driver to provide a ALOHA type -connection ( there being no "collision dectect" on a simple system) Why not do it in the application layer and leave TCP out of it. Just send datagrams over the SLIP link and have everyone involved strictly follow a speak before spoken to protocol? - -It may be possible to encode data so that 8 bits gets transmitted as -16 (20 actually if you include stop/start). E.g send each bit as a -dibit, 01 or 10. Then arrange to pad the line and use a token passing -mechanism so that each machine only transmits when the line is quiet. -I could even add hardware to provide a "sort of " collision detect but -it all seems a bit complicated. Very complicated. If you're going there when implement a virtual token system where you can only speak when you have the token. Collisions are of course the problem. You can't afford to have any. BAJ
Reply by ●November 15, 20042004-11-15
Ian McCrum MI5AFL wrote:>> Ian McCrum MI5AFL wrote: >>> I wonder if there is documentation on standard RS485 protocols >>> anywhere for download? >>> >>> I have homebrewed a couple of these in the past but is there a >>> standard way of doing this? >> <SNIP> >>> Tia >>> Ian McCrum > >> On Mon, 15 Nov 2004 11:38:05 -0700, "Not Really Me" >> <scott@exoXYZtech.com> wrote: Ian, as you can see from the responses >> there doesn't seem to be a standard. >> We also have homebrewed a couple. I have placed a zip file in a >> download >> area of our web site of a simple protocol we have used a few times. >> http://www.exotech.com/downloads.htm. >> >> I realize this is asking all the NG's old hens to fuss about how it >> could be better, faster, simpler, etc. But the cost is the same, >> and I can't >> remember seeing there offerings. Although I am willing to host any >> others >> on the site. >> >> Scott > > ============================== > Thanks Scott, I have downloaded the .zip I'll give it a good looking > over. > > It has been 3 or 4 years since I did my last RS485 network, and it has > always been one computer talking to a number of much smaller > microprocessors. I always used a four wire system. I'll see if I can > dig up the code. ><SNIP> Should work fine for 4-wire also. We use it primarily on 2-wire in an industrial control app with 2 to 20 or more devices per network. Scott
Reply by ●November 15, 20042004-11-15
>On 15 Nov 2004 14:53:49 -0500, byron@cc.gatech.edu (Byron A Jeff) wrote:>>In article <67gfp0dr2na07h75ic7i939d15r2pelcf5@4ax.com>, >>Ian McCrum MI5AFL <IJ.McCrum@ulster.ac.uk> wrote: >>-I wonder if there is documentation on standard RS485 protocols >>-anywhere for download? >>... >>-The SLIP and PPP protocols are not multidrop of course.> >PPP isn't. But SLIP is nothing other than a trivially modified IP >packet, which of course is routable. There's no technical reason why >you couldn't route addressible packets onto a SLIP link. Run UDP on >top of it and voila! a simple and standard multidrop link. >Ok, I'll go look at slip, I have only worked with PPP before ( Seiko firmware chip)>However you'd still have to implement a speak when spoken to only >duplex protocol on top of this to eliminate collisions.In practice collisions would be unlikely, a datalogging application will look after the polling, that just leaves other miscellaneous things I'd like to run, tftp and NFS. There would probably be a "master" computer anyway>Why not do it in the application layer and leave TCP out of it. Just >send datagrams over the SLIP link and have everyone involved strictly >follow a speak before spoken to protocol?I'd probably want to run TCP applications over the link, e.g SSH, TELNET or VNC so using a standard TCP/IP stack makes the applications easier to get. And the off timeout wouldn't matter, or could be got around. Once you have a network, you'd use it for lots of things... Regards and Thanks again Ian
Reply by ●November 15, 20042004-11-15
On Sun, 14 Nov 2004 20:46:59 +0000, Ian McCrum MI5AFL <IJ.McCrum@ulster.ac.uk> wrote:>It may be possible to modify a TCP driver to provide a ALOHA type >connection ( there being no "collision dectect" on a simple system)Running ALOHA on a bus which can be actively driven both high and low at different units, is not a good idea. When one transmitter is driving "1" and the other "0", a quite large short circuit current will flow between Vcc and ground. While the short circuit current limit will protect the devices against permanent physical damage, the transceivers can run quite hot or produce other nasty side effects. A better solution would be to use some kind of dominant/rescessive system as used in CAN (Controller Area Network). Prior to the availability of dedicated CAN transceivers, ordinary RS-485 chips were used in CAN. Connect the transmitter data input to a permanent "0" level and connect the serial Tx signal to the Tx-driver enable signal in such a way that the "0" serial data will activate the driver and send out the fixed "0" level (dominant state). When the "1" is to be sent, the RS-485 driver is disabled and the fail safe termination will pull the line to the "1" (recessive) state. If there is a collision, the dominant "0" driver will override the recessive "1" termination. If you keep the receiver enabled all the time, you can monitor, if some other station caused a collision which overrided your recessive state. Paul
Reply by ●November 16, 20042004-11-16
Ian McCrum MI5AFL wrote:>>Ian McCrum MI5AFL wrote: >> >>>I wonder if there is documentation on standard RS485 protocols >>>anywhere for download? >>>I've come across this thread rather late so I don't know what's been said, but has anyone mentioned Bitbus? <http://www.alfirin.net/flamer/bitbus/> for some stuff. Paul Burke
Reply by ●November 16, 20042004-11-16
Ian McCrum MI5AFL <IJ.McCrum@ulster.ac.uk> wrote in message news:<67gfp0dr2na07h75ic7i939d15r2pelcf5@4ax.com>... try: http://www.hth.com/snap/
Reply by ●November 16, 20042004-11-16
"Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> wrote in message news:cbqjp05rjfpvfe2hj369kskgp7laqjudvf@4ax.com...> On Sun, 14 Nov 2004 20:46:59 +0000, the renowned Ian McCrum MI5AFL > <IJ.McCrum@ulster.ac.uk> wrote: > > >There may be implementations already done... was localtalk rs485? ( > >old apple) or maybe versions of modbus, profibus or somesuch. I don't > >know anything about modbus, profibus or localtalk, maybe someone here > >can comment... > > Modbus is simple and may be appropriate. It comes in two flavors- RTU > and ASCII. Google for more.Modbus-RTU is horrible, because it relies on inter-character timing for frame delimiting. It is far more easy to use a modified SLIP, where you use 0xFE as start, 0xFD as end and 0xFC as escape characters. Actually, the choice of these control characters is arbitrary. Meindert
Reply by ●November 16, 20042004-11-16
On Sun, 14 Nov 2004 20:46:59 +0000, the renowned Ian McCrum MI5AFL <IJ.McCrum@ulster.ac.uk> wrote:>There may be implementations already done... was localtalk rs485? ( >old apple) or maybe versions of modbus, profibus or somesuch. I don't >know anything about modbus, profibus or localtalk, maybe someone here >can comment...Modbus is simple and may be appropriate. It comes in two flavors- RTU and ASCII. Google for more. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
