On Mar 16, 1:39=A0pm, Jim Stewart <jstew...@jkmicro.com> wrote:
> 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. =A0Given 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. =A0A 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.

Yes, in fact, you should always choose wisely and do everything
carefully.  Is that ever bad advice???

Rick

Jim Stewart wrote:
> 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.

Yup.

-- 
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.

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

"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

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 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 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.

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.