RS485 with SN75176 - TX collision

Hi, coming back after the RS485 bus has been setup.
Going on investigating about possible problems, we've found that we're
defenseless against transmitters collisions: if a slave get stuck in
transmitter mode (DE=1 in SN75176) when the master take the bus
control, we have a fault on the line.

So I made up a test board with two transceivers: the first one fixed
on transmission mode (DE[1]=1 and D=0) and the second one with DE[2]
pin switchable between 0 and 1.
When DE[2] == 0 there's no problem and the supply current is about
5mA.
When we switch DE[2]=1 supply current step up to 200mA.

We're trying a dominant/recessive scheme, based on DS36277 used in
J1708 bus.

djordj schrieb:

> Going on investigating about possible problems, we've found that we're
> defenseless against transmitters collisions: if a slave get stuck in
> transmitter mode (DE=1 in SN75176) when the master take the bus
> control, we have a fault on the line.
> 
> So I made up a test board with two transceivers: the first one fixed
> on transmission mode (DE[1]=1 and D=0) and the second one with DE[2]
> pin switchable between 0 and 1.
> When DE[2] == 0 there's no problem and the supply current is about
> 5mA.
> When we switch DE[2]=1 supply current step up to 200mA.
> 
> We're trying a dominant/recessive scheme, based on DS36277 used in
> J1708 bus.

RS-485 is pure single master and not capable of a dom/rec scheme. The
drivers are push-pull, you can't even predict what the other devices on
the bus will receive during the collision.

I think you should look at CAN transceivers instead.

Tilmann

djordj wrote:
> Hi, coming back after the RS485 bus has been setup.
> Going on investigating about possible problems, we've found that we're
> defenseless against transmitters collisions: if a slave get stuck in
> transmitter mode (DE=1 in SN75176) when the master take the bus
> control, we have a fault on the line.
> 
> So I made up a test board with two transceivers: the first one fixed
> on transmission mode (DE[1]=1 and D=0) and the second one with DE[2]
> pin switchable between 0 and 1.
> When DE[2] == 0 there's no problem and the supply current is about
> 5mA.
> When we switch DE[2]=1 supply current step up to 200mA.
> 
> We're trying a dominant/recessive scheme, based on DS36277 used in
> J1708 bus.

So why not use the J1708 scheme?  From Wiki (master of the infoverse, 
dispenser of all knowledge, first in every Google search) pedia on their 
J1708 page*:

"The hardware utilized are RS-485 transceivers wired for open collector 
operation through the use of a pullup and pulldown of the separate data 
lines. Transmission is accomplished by controlling the driver enable pin 
of the transceiver. This method allows multiple devices to share the bus 
without the need for a single master node. Collisions are avoided by 
monitoring the bus while transmitting the MID to ensure that another 
node has not simultaneously transmitted a MID with a higher priority."

Assuming that you have your polarities right, and that your driver chips 
all have the data pin tied in the same direction, you should be fine.

* http://en.wikipedia.org/wiki/J1708

-- 
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

On Mar 15, 6:13=A0pm, Tilmann Reh <usenet2007nos...@autometer.de> wrote:

>
> RS-485 is pure single master and not capable of a dom/rec scheme. The
> drivers are push-pull, you can't even predict what the other devices on
> the bus will receive during the collision.
The network is a single-master bus, but I have to face problems
deriving from faulty devices.
What about if a slave get stuck in transmitting mode after its reply
has been sent?
The next time the master get bus control we have two transceivers in
TX mode, and that's a problem.

On Mar 15, 6:30=A0pm, Tim Wescott <t...@seemywebsite.now> wrote:
> djordj wrote:
> So why not use the J1708 scheme? =A0From Wiki (master of the infoverse,
> dispenser of all knowledge, first in every Google search) pedia on their
> J1708 page*:
>
This is exactly the solution we're about to try.

djordj schrieb:

> On Mar 15, 6:30 pm, Tim Wescott <t...@seemywebsite.now> wrote:
>> djordj wrote:
>> So why not use the J1708 scheme?  From Wiki (master of the infoverse,
>> dispenser of all knowledge, first in every Google search) pedia on their
>> J1708 page*:
>>
> This is exactly the solution we're about to try.

But take care that even if you implement it that way (or with any other
dom/rec scheme), the system will still hang if one of the devices stucks
 with TX active at dominant state.

To maintain bus control by the master, you'd need a four wire bus
(RS-422), so that a collision on the master TX lines is impossible
(since there are only device receivers connected to it). If a device
stucks at TX active, the master still can send commands to all devices,
trying to gain control again.

Another approach would be a hardware watchdog at each device, forcing
the transmitter off if it's active for a too long time.

Tilmann

On Mar 16, 9:10=A0am, Tilmann Reh <usenet2007nos...@autometer.de> wrote:
> But take care that even if you implement it that way (or with any other
> dom/rec scheme), the system will still hang if one of the devices stucks
> =A0with TX active at dominant state.
That's right, but at least transceivers are saved...

> To maintain bus control by the master, you'd need a four wire bus
> (RS-422), so that a collision on the master TX lines is impossible
> (since there are only device receivers connected to it). If a device
> stucks at TX active, the master still can send commands to all devices,
> trying to gain control again.
Right again, but for mechanical reasons we can't use a 4-wire bus...
don't ask me why......

> Another approach would be a hardware watchdog at each device, forcing
> the transmitter off if it's active for a too long time.
Or a sort of current sensing on transceiver supply.

Thanks!

"djordj" <grgmeda@gmail.com> wrote in message
news:95a1ded9-39d0-45a6-b6e1-6566631c761c@e7g2000yqf.googlegroups.com...
On Mar 15, 6:13 pm, Tilmann Reh <usenet2007nos...@autometer.de> wrote:

> The network is a single-master bus, but I have to face problems
> deriving from faulty devices.
> What about if a slave get stuck in transmitting mode after its reply
> has been sent?

Design your slave such that after a reset, the DE is inactive and use a
watchdog timer. End of problem.

Meindert

djordj wrote:
> On Mar 15, 6:13 pm, Tilmann Reh <usenet2007nos...@autometer.de> wrote:
> 
>> RS-485 is pure single master and not capable of a dom/rec scheme. The
>> drivers are push-pull, you can't even predict what the other devices on
>> the bus will receive during the collision.
> The network is a single-master bus, but I have to face problems
> deriving from faulty devices.
> What about if a slave get stuck in transmitting mode after its reply
> has been sent?
> The next time the master get bus control we have two transceivers in
> TX mode, and that's a problem.
> 
That's a problem that you face with just about any practical networking 
choice.  Given careful design of the slave, it becomes equivalent to 
"what if a customer takes a hatchet to the main circuit board?" -- i.e., 
a truly fatal problem, but one that isn't likely.

Design your slave so that it doesn't get stuck.  A suggestion has 
already been mooted for unsticking a hard-stuck slave; consider taking 
that, then design the _rest_ of your slave's hardware and software with 
a goal of never having it land in that particular safety net.

-- 
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

Tim Wescott wrote:
> djordj wrote:
>> On Mar 15, 6:13 pm, Tilmann Reh <usenet2007nos...@autometer.de> wrote:
>>
>>> RS-485 is pure single master and not capable of a dom/rec scheme. The
>>> drivers are push-pull, you can't even predict what the other devices on
>>> the bus will receive during the collision.
>> The network is a single-master bus, but I have to face problems
>> deriving from faulty devices.
>> What about if a slave get stuck in transmitting mode after its reply
>> has been sent?
>> The next time the master get bus control we have two transceivers in
>> TX mode, and that's a problem.
>>
> That's a problem that you face with just about any practical networking 
> choice.  Given careful design of the slave, it becomes equivalent to 
> "what if a customer takes a hatchet to the main circuit board?" -- i.e., 
> a truly fatal problem, but one that isn't likely.
> 
> Design your slave so that it doesn't get stuck.  A suggestion has 
> already been mooted for unsticking a hard-stuck slave; consider taking 
> that, then design the _rest_ of your slave's hardware and software with 
> a goal of never having it land in that particular safety net.

The only think I'd add is use a watchdog
and write your TX driver very carefully.