Searching \ for '[ee] RS485' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/serials.htm?key=rs485
Search entire site for: 'RS485'.

Exact match. Not showing close matches.
PICList Thread
'[ee] RS485'
2005\08\23@090400 by Mauricio Jancic

flavicon
face
part 1 508 bytes content-type:text/plain; (decoded 7bit)

I've always used RS-422, but never RS485. I'm having doubts, because in the
scheme that I saw: (attached)
I see that they connect all the drivers together, so this means that I'll
have to waste a pin to enable/disable the transmitters I'm not using.
Is there a correct way to a multidrop network on rs485 ?

How should it be done?

Thanks,

Mauricio Jancic
Janso Desarrollos - Microchip Consultants Program Member
spam_OUTinfoTakeThisOuTspamjanso.com.ar
http://www.janso.com.ar
(54) 11 - 4542 - 3519



part 2 24602 bytes content-type:image/jpeg; (decode)


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2005\08\23@100757 by olin piclist

face picon face
Mauricio Jancic wrote:
> I've always used RS-422, but never RS485. I'm having doubts, because
> in the scheme that I saw: (attached)
> I see that they connect all the drivers together, so this means that
> I'll have to waste a pin to enable/disable the transmitters I'm not
> using.

Yup, that's the way multi-drop RS-485 works.  A few years back I remember
seeing some clever RS-485 transceivers (or was that RS-232 converters?) that
automatically releaseed the RS-485 bus if you tried to drive it to the idle
state for some minimum time.  I also remember thinking they might cause more
trouble than they were worth in some circumstances.  We used a separarate
PIC pin to enable the local bus driver.

RS-485 is the old way to do this.  CAN is usually better for new designs.
It is differential with good noise immunity like RS-485, but the lowest
level protocol is not only specified but implemented in hardware.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\08\23@102043 by Bob Axtell

face picon face
This is the normal way to connect these networks, Mauricio. I've never
connected them any other way,
except to use TI components instead of Maxim (so my client made a profit
at the end of the day)..

--Bob


Mauricio Jancic wrote:

{Quote hidden}

--
Note: To protect our network,
attachments must be sent to
attachspamKILLspamengineer.cotse.net .
1-866-263-5745 USA/Canada
http://beam.to/azengineer

2005\08\23@113617 by Martin Klingensmith

flavicon
face
part 0 44 bytes
his is a multi-part message in MIME format.
part 1 680 bytes content-type:text/plain; charset=ISO-8859-1; format=flowed (decoded 7bit)

Hello Mauricio,
I stole this [attached PNG image] from an Omega D1000 series manual. The
difference may be that the slave modules cannot initiate communications
perhaps, but it only requires two lines.
--
Martin Klingensmith

Mauricio Jancic wrote:

{Quote hidden}


part 2 17516 bytes content-type:image/png; (decode)


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2005\08\23@115843 by Gerhard Fiedler

picon face
Martin Klingensmith wrote:

>> I see that they connect all the drivers together, so this means that
>> I'll have to waste a pin to enable/disable the transmitters I'm not
>> using. Is there a correct way to a multidrop network on rs485 ?

> I stole this [attached PNG image] from an Omega D1000 series manual. The
> difference may be that the slave modules cannot initiate communications
> perhaps, but it only requires two lines.

This saves wires for the connections between the devices, but not the
processor pin Mauricio was talking about (to enable/disable the individual
transmitters).

Gerhard

2005\08\23@122542 by Mauricio Jancic

flavicon
face
>> This saves wires for the connections between the devices, but not the
>> processor pin Mauricio was talking about (to enable/disable the
>> individual transmitters).

Yes, that's right. I was trying to use the built in USART but needed
distance so I tought of RS485. I have used half duplex rs485 many times and
I know I need the extra pin to toggle between send and receive.

Now, I tough (I guess not much) that full duplex rs485 wouldn't need that
pin.

Other problem I see is that if I disable all the transmitters since are all
in hiz the receiver (and the master) reads a lot of crap which I don't
want...

I'll start considering the CAN as Olin suggested.
Thank you guys,

Mauricio Jancic
Janso Desarrollos - Microchip Consultants Program Member
.....infoKILLspamspam.....janso.com.ar
http://www.janso.com.ar
(54) 11 - 4542 - 3519

2005\08\23@133938 by Gerhard Fiedler

picon face
Mauricio Jancic wrote:

> Now, I tough (I guess not much) that full duplex rs485 wouldn't need that
> pin.

Not on the master (if you have a 1:n configuration), but on the slaves.

> Other problem I see is that if I disable all the transmitters since are all
> in hiz the receiver (and the master) reads a lot of crap which I don't
> want...

You could use pull-up/-down resistors ...

> I'll start considering the CAN as Olin suggested.

... but I second Olin's suggestion. Once you worked your way through the
CAN module once, it's a lot easier.

Gerhard

2005\08\23@155826 by Richard Prosser

picon face
You can use a hardware circuit to drive the TX enable, triggered off
the start bit of the transmission. The only catch is that it has to
hold the TX enable line high at least until the end of the stop bit so
it can slow things down very slightly.
I have used this on a current project. It's working fine at 38400
baud. My attack time is about 1 usec & the holdup time about 1.2ms (so
could be reduced somewhat).

Richard P

On 24/08/05, Gerhard Fiedler <EraseMElistsspam_OUTspamTakeThisOuTconnectionbrazil.com> wrote:
{Quote hidden}

> -

2005\08\23@171624 by Brent Brown

picon face
> Hello Mauricio,
> I stole this [attached PNG image] from an Omega D1000 series manual. The
> difference may be that the slave modules cannot initiate communications
> perhaps, but it only requires two lines.

I am very dubious about this. In RS485 the transmittter and the receiver all
must have the same GND connection. The spec allows for differences in
GND potential (-7V to +12V from memory) which gives a degree of rejection
of common mode noise, such as difference in mains earth ground potential
between buildings. To leave nodes "floating" with no ground reference is a
recipe for disaster. In some cases you may actually achieve data throughput,
but the risk is things floating outside of the comon mode voltage limits and
loosing comms and/or damaging chips.

--
Brent Brown, Electronic Design Solutions
16 English Street, Hamilton 2001, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell/txt: 027 433 4069
eMail:  brent.brownspamspam_OUTclear.net.nz


2005\08\23@220223 by Chen Xiao Fan

face
flavicon
face
I think CAN is as well not a very high level protocol. On top
of it people can use different application layer (?) like
CANOpen or other proprietary protocols.

For example, Pepperl+Fuchs is using CAN as the based protocol
for the RPI (remote process interface) modules with proprietary
application layer. The RPI gateway will translate the CAN signal
inside the "RPI module network" (5-pin DIN rail connected
bus, +24V, GND, CAN+, CAN- and Collected Error) to outside world
like MODBUS/Profibus/Foundation Field Buss/...

The advantage is savings in cabling, which can be a good part
of investment in big industrial projects. With RPI/IS-RPI,
instead of point to point connection of the field sensors
or transmitters to the PLC, we can have bus to point (PLC I/O
modules). From there, P+F have developed bus to bus product
as well (FieldConnex). I do not know the exact details though
since I am not longer working in that division (Process Automation).

Regards,
Xiaofan

----------------------------------------------
Xiaofan Chen
R&D Engineer, Photoelectric Sensor Development
Pepperl+Fuchs Singapore
http://www.pepperl-fuchs.com
Signals for the world of automation
--------------------------------------------

-----Original Message-----
From: @spam@olin_piclistKILLspamspamembedinc.com [KILLspamolin_piclistKILLspamspamembedinc.com]
Sent: Tuesday, August 23, 2005 10:09 PM

RS-485 is the old way to do this.  CAN is usually better for new designs.
It is differential with good noise immunity like RS-485, but the lowest
level protocol is not only specified but implemented in hardware.

2005\08\23@221400 by Russell McMahon

face
flavicon
face
{Quote hidden}

There are risks if this is done unintelligently BUT it's logically and
practically possible. RS485 is true differential and, for signalling,
the voltage of the two wires relative to each other is all that
counts. As long as your circuit can deal with the real world's common
mode voltages that you encounter then all will (probably) be well. It
may be that internally to their products Omega have implemented means
other than standard IC's to monitor and generate the differential
voltages. or they may use standard RS485 ICs that are floated relative
to ground with an isolated supply. ie it's doable but beware of
copying what someone else is doing without knowing the whole story.



           RM


2005\08\24@030154 by Vasile Surducan

face picon face
On 8/23/05, Mauricio Jancic <RemoveMEinfoTakeThisOuTspamjanso.com.ar> wrote:
> >> This saves wires for the connections between the devices, but not the
> >> processor pin Mauricio was talking about (to enable/disable the
> >> individual transmitters).
>
> Yes, that's right. I was trying to use the built in USART but needed
> distance so I tought of RS485. I have used half duplex rs485 many times and
> I know I need the extra pin to toggle between send and receive.
>
> Now, I tough (I guess not much) that full duplex rs485 wouldn't need that
> pin.

 Nor half duplex as I already said.

Vasile

{Quote hidden}

> -

2005\08\24@084428 by Gerhard Fiedler

picon face
Chen Xiao Fan wrote:

> RS-485 is the old way to do this.  CAN is usually better for new designs.
> It is differential with good noise immunity like RS-485, but the lowest
> level protocol is not only specified but implemented in hardware.

When talking about layers (at least OSI protocol layers)... CAN does not
specify the lowest level of the protocol (the hardware level). I guess
that's done on purpose, so that the CAN protocol can be used in different
situations and still be CAN. For example, you can use the standard ISO
11898-2 drivers and go up to 1 Mb/s on a differential pair without
isolation. Or you could use a pull-up resistor and transistors as drivers.
Or you could use optos as drivers and get a pretty slow but isolated
connection. Or you can make a driver that, on two wires, sends not only the
signal but also powers the other devices connected to the wires. And -- you
of course can make an RS-485 driver for your CAN bus. (I don't know why you
would do that, but you can.)

The only thing you have to do is to make sure different drivers can send
dominant and recessive bits at the same time without that in itself
creating a problem (which generally prohibits normal push-pull drivers),
and that a dominant bit is received by all receivers when two drivers at
the same time send a recessive and a dominant bit respectively.


>> I think CAN is as well not a very high level protocol. On top of it
>> people can use different application layer (?) like CANOpen or other
>> proprietary protocols.

In the OSI layer model, CAN is on layer 2 (data link). Layer 2 is generally
described as "Frame format, Transmitting frames over the net [additional
bit/byte stuffing, start/stop flags, checksum, and CRC]." In a traditional
RS-485 network, you see that this includes some of the standard async data
communication protocol (the part usually handled by the UART) and some of
what you have to add in firmware to make the transmission safer (like bus
arbitration and transmission error detection). It's that second part that
is so valuable in using the CAN bus protocol and hardware modules that
implement it.


As for the higher layers -- there are many standards that use the CAN as
layer 2 protocol. Some of them include also a definition of layer 1 (the
physical connection), some don't.

Here are a few of the more common standards for the layer 1 protocol (the
physical link) used with CAN bus:
http://www.can-cia.org/can/physical-layer/index.html#physical

Here are listed a few of the higher layer protocols based on CAN bus:
http://www.kvaser.com/can/hlps/index.htm

There are also one or two open source (free) higher level protocol
implementations somewhere. (In C, IIRC... :)

Needless to say, the higher the level goes, the more assumptions it makes
about the function of the nodes and the application requirements.

Gerhard

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...