RS485, multidrop protocol - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: RS485, multidrop protocol
Quoted text here. Click to load it



Ok, I'll go look at slip, I have only worked with PPP before ( Seiko
firmware chip)

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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


Re: RS485, multidrop protocol
On Sun, 14 Nov 2004 20:46:59 +0000, Ian McCrum MI5AFL

Quoted text here. Click to load it

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


Re: RS485, multidrop protocol

try:

http://www.hth.com/snap /

Re: RS485, multidrop protocol
Ted Wood schrieb:
Quoted text here. Click to load it
---8<----

http://www.p-net.dk

cheers
Gunther

Re: RS485, multidrop protocol
On Sun, 14 Nov 2004 20:46:59 +0000, the renowned Ian McCrum MI5AFL

Quoted text here. Click to load it

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"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: RS485, multidrop protocol
Quoted text here. Click to load it

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



Re: RS485, multidrop protocol
On Tue, 16 Nov 2004 12:48:20 +0100, the renowned "Meindert Sprang"

Quoted text here. Click to load it

That "feature" just requires low-level programming and may eat some
system resources (a timer) if there is no buffering on the serial
port. Other than that, it isn't difficult if you plan for it.


Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: RS485, multidrop protocol
Quoted text here. Click to load it

Try it on a UART with a FIFO.....

Meindert



Re: RS485, multidrop protocol
Quoted text here. Click to load it


The main problem is that hardware receive buffering cannot
be used to prevent loss of frame timing gaps. You cannot
measure the character timing from the FIFO output.

Please forget Modbus/RTU - it seems to be designed for
maximum difficulty to transport. The receive interrupt
handler does not know the length of a frame unless is
parses all of the commands and sub-options of the frame,
and the parsing logic is different for a client (master)
and server (slave).

Modbus/TCP seems to be as broken, but in another way.

Been there - done that (gotten bitten by a tunneling
Modbus bridge).

--

Tauno Voipio
tauno voipio (at) iki fi


Re: RS485, multidrop protocol

Quoted text here. Click to load it

"some" resources?  It eats tons of resources.  It makes it
impossible to use the receive FIFO in a UART and thus requires
an interrupt for every single byte.  That makes it almost
impossible to use at high baud rates.

--
Grant Edwards                   grante             Yow!  BELA LUGOSI is my
                                  at               co-pilot...
We've slightly trimmed the long signature. Click to see the full one.
Re: RS485, multidrop protocol
On Tue, 16 Nov 2004 06:50:59 -0500, Spehro Pefhany

Quoted text here. Click to load it

Modbus master and Modbus point to point slave is trivial to implement,
since you can rely on the message contents. However, implementing a
Modbus multidrop slave is tricky, since you must adhere to the strict
timing.

The simplest environment to implement nearly perfect timing would be
to use the QUICC co-processor found on the MC68360/MPC860/MPC2860
etc., but even in this case, the Tx message preamble would have to be
set to 2 character times (instead of nominal 1.5 character times), the
Tx trailer to 1 character time (nominal 1.5 character times) and the
Rx end of frame interrupt at 3 character times (nominal 3.5 character
times).

Running Modbus multidrop slave at 115k2 or above with a general
purpose hardware, you really need a timing accuracy and interrupt
latency of 50 us or less, which the standard Linux kernel is
definitely not going to offer.  

Paul


Re: RS485, multidrop protocol
Wow, a long thread, Thanks for the inputs, I am following up on the
links.

It looks like there is no clear cut winner in getting, say half a
dozen machines linked using RS485, a simple master-slave polling
scheme, where machines queue up outgoing requests and only speak when
spoken to would be simplest. The other candidates seem onerous.

The real trick will be to provide a physical layer that can link to a
standard TCP protocol stack.

When I get my linux board I'll start dismantling some of the ethernet
drivers, maybe I can "fool" the TCP/IP stack to think it is connected
to a perfect (unbusy) network.

I'll revisit slip and ppp then.

Thanks again
Ian McCrum MI5AFL.
( actually I just realised AX25 might be a good candidate as well...)
University of Ulster




Re: RS485, multidrop protocol
Quoted text here. Click to load it

www.micrium.com offers an inexpensive ModBus package.

Scott



Site Timeline