CAN bus Problem

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

Translate This Thread From English to

Threaded View
Hi,

I'm using CAN (Controller area network). I don't think the speed is
important (83.333 kHz)

All was ok
Micro + Optocoupler + driver CAN

 but recently, we add a transistor (because the current was too important
for microcontroller)
Micro + transistor + Optocoupler + driver CAN

So the propagation time increase.
All was working very fine until we had a longer bus than other
installations.
Some nodes are going 'bus off', but not those who have the transistor

In the microcontroller, I have the following programmation:
Synchronisation Segment: 1 TimeQuanta (TQ)
Segment Propagation + Segment Phase 1 = 16 TQs
Segment Phase 2 = 7 TQs
Resynchronization Jump Width: 1 TQ

1+16+7 = 24

I have Bit Timing BT = 24 TQ so I can't increase any value without decrease
another

What's the best solution for me ?

1) I must increase the Segment Propagation time but I must decrease smthg
else: Segment phase 2 ? It may stop working
2) or must I increase RSJW ?
3) other solution ?
4) I can't reduce speed because of compatibility with existing products.

I'm a bit lost and I don't know what to do.
May you help me ?

Thanks for you help,

Best Regards

Herve Lhuguenot




Re: CAN bus Problem
On Mon, 27 Oct 2003 18:14:21 +0100, "MU13"


Quoted text here. Click to load it

You don't tell, what type of optocoupler You use.
Cheap optocoupler have propagation delays of
3 - 10 microseconds. I suppose a better coupler
will do wonders.

Regards

Klaus


Re: CAN bus Problem
Quoted text here. Click to load it

Hi

Yes Klaus it's cheap optocoupler, that's one of the problem. We are
searching for better OC with same package

Thanks
Hervé Lhuguenot





Re: CAN bus Problem

Quoted text here. Click to load it


In theory: yes.  But rather much doubt that this could have any
measurable effect on propagation timing unless you chose a
ridiculously slow type of transistor, or aren't driving it correctly.
In other words: if adding that transistor drove your propagation time
beyond the acceptable, you must already have been perilously close to
it before.

Quoted text here. Click to load it

"Longer" meaning what?  How many meters?  Or, more to the point: how
many nanoseconds of cable propagation time?  Do you have any
measurement or idea what your total propagation time (two optos, two
CAN transceivers, one cable) actually is, with and without the
transistor, respectively?

Quoted text here. Click to load it

To me that sounds like somethings wrong with those nodes, not with
your new ones that have the transistor.  By design, a CAN node goes
bus off because it thinks *itself* is behaving incorrectly.  Can you
tap into on of those and find out why they go bus-off, i.e. what types
of errors they're seeing?

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: CAN bus Problem
Quoted text here. Click to load it
important

Well, the latter could be the case. Many people just 'trow in' a transistor
and a base resistor that is way too low. The transistor saturates heavily
and takes 10s of microseconds to get out of saturation.
This can be prevented very easy by adding a schottky diode across collector
and base.

Meindert



Re: CAN bus Problem

Quoted text here. Click to load it
transistor
collector

Thanks I'll say it to the concern person
We are trying to reduce the time, but we don't have thinking about this
solution
Herve Lhuguenot



Re: CAN bus Problem
Hi,

Quoted text here. Click to load it
important

That's what I think !

Quoted text here. Click to load it

Longer is 300 meters (at 83.333 Kb/s i.e. BT = 12us) instead of 100 meters
2 opto + 2 transistor + 2 drivers = 4.5us
+ cable I don't have any information propagation time on the cable (Corel
L120)

Quoted text here. Click to load it
With fastest transistor it seems to work. The older products without
transistors works fine until we plug a new one.

Quoted text here. Click to load it
I know but we have searching for the problem for 5 days. That's why I don't
know what type of error is the problem. It's not logical !

Quoted text here. Click to load it

No, I can't reproduce the problem where I am (not enough cable). The problem
appears on a installation far away. We are going to buy cable to test new
design, 'faster'.The element which goes off sends time each second. It's the
element which transmit the frames on the bus.

Quoted text here. Click to load it

Thanks Hans-Bernhard
We are actually trying to reduce the time.
Hervé Lhuguenot




Re: CAN bus Problem

...

Quoted text here. Click to load it

Can you give a few more details. What kind of transistor do you apply?
What is the prop-delay of this transistor (data-sheet or measured)?
What takes place on Rx and Tx? Maybe you can analyze this with a logic
probe and tell us the prop-delay of a node with transistor.
 
Quoted text here. Click to load it

I surely think it is, but you do not give us any more details nor do you
try to debug the whole thing. The bit error type might be important. Maybe
your new nodes exceed a certain inductance value on the bus, you don't tell.
 
Quoted text here. Click to load it

How many nodes do you have on the bus? Far too less information for granting
serious help, sorry.

Regards,
Taso



Re: CAN bus Problem
Quoted text here. Click to load it
transistor

The transistor is a BC857. I don't have any other references.
But my question at the beginning was more software oriented.
Between the tx signal and rx signal on a node with transistors, I have 4.5us
(2 opto + 2 transistor + 2 drivers )
The bit Length is 12 us.
With the programmation I use, the sample point is at 8.5 us. So my first
idea was to put the sample point at 11 us for example. But, imho, I don't
think (now) that it will resolve the problem. I think that I will have to
reduce prop delay or reduce speed.
We have found fastest optocoupler which not need the use of Optocouler, so i
hope that will resolve the problem.

Quoted text here. Click to load it
don't

I don't have access to the bus so I can't analyse exactly what happens. I
only have the information of how the products reacts on the installation
site by phone. I have products here, but I can't reproduce the problem,
because I don't have enough cable length (actually, we'll command it).

Quoted text here. Click to load it
Yes but I can't know it actually.

Quoted text here. Click to load it
tell.

There's actually 12 nodes on the bus. If I put only 1 'ok node' and 1 'error
node' (with long cable between): the error happens. So the problem isn't the
number of nodes on the bus.
I'm Software Enginneer, so excuse me, but how can the inductance value be
different than the other nodes ? We use the same Driver. I don't understand
exactly what you mean about the inductance value. How can I measure it .

Quoted text here. Click to load it

I'll do it as soon as I can produce the error. But actually I can't.

Quoted text here. Click to load it
problem
new
the
With 12 nodes without transistor, it works
With 1 node without, and 1 with, it doesn't work.
With 11 nodes without transistor, and 1 with it doesn't work.

Quoted text here. Click to load it
Thank you, but I effectively have too less information.

Quoted text here. Click to load it

Regards
Hervé Lhuguenot



Re: CAN bus Problem

Quoted text here. Click to load it

What was it without the transistors?

Quoted text here. Click to load it


That cannot work.  Due to the enormous propagation delay in your optocouplers,
you've exceeded the overall timing tolerance.

Quoted text here. Click to load it

Exactly
--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: CAN bus Problem
Quoted text here. Click to load it
4.5us

I don't have made the test.

Quoted text here. Click to load it
optocouplers,

If I set the sample point at 11 us, am I resolving the problem or  not ?

Quoted text here. Click to load it

We have found a fast optocoupler which doesn't need the use of transistor at
the input. So we think that will resolve our problem.

Quoted text here. Click to load it

Thanks
Regards
Herve Lhuguenot




Re: CAN bus Problem

Quoted text here. Click to load it



I strongly doubt it.  I don't have my reference texts at hand, so I
can't give you a more precise answer right now.

You have 4.5 us transceiver dely, and at 300 meters of bus length, you
have to take into account something like 1.5 us per direction of cable
delay on to of that.  Your problem most likely is that you can't get
ACK bits sent and received in time.

You have three to four variables to play with --- transceiver delay,
cable length, sampling time, and, as a last resort, the bus speed
itself.  It's their combination that really defines the problem.  One
of them will have to change to fix it, and I doubt that moving the
sampling point alone is going to do it.

You _really_ should have someone at your shop with a CAN spec at hadn
and enough experience to use it, so you can do this on your own
without asking on the 'net, though, if you're going around deploying
devices to remote users...


--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: CAN bus Problem
Thanks Hans-Bernhard



Re: CAN bus Problem
On Fri, 31 Oct 2003 12:41:36 +0100, "MU13"
[snip...snip]
Quoted text here. Click to load it

Maybe You have only measured the upgoing edge. As transistors
and optocouplers do not act symmetrically, the falling edge
normally has a much higher propagation delay (look to Meinderts
posting about saturation effects).

Regards

Klaus


Re: CAN bus Problem
Hi

We've tried Meindert suggestion, but had another problem. Our transistors
wasn't correctly polarized.
We have resolved the problem.

Ok Thanks Klaus






Re: CAN bus Problem
 
Quoted text here. Click to load it

Yep, I agree. When using CMOS-parts the propagation delay increases only
for a few ns, e.g. the analogue switch 74HC1G66 from Philips. Additional
prop-delay ~ 11 ns!
 
...
 
Quoted text here. Click to load it

Yep, this approach is highly recommended when debugging CAN-applications.


Regards,
Taso




Re: CAN bus Problem
Quoted text here. Click to load it
important

Yes it's a CMOS transistor !

Quoted text here. Click to load it

I don't have seen it myself, so i doubt of the person who said it to me !
For me it's impossible that the good  goes bus off instead of the bad !

Quoted text here. Click to load it

I'll try as soon as I can.

Quoted text here. Click to load it

Thanks Taso
Herve Lhuguenot



Site Timeline