Forcing Error and Overload Frames

[Mike-419]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi All,

         I am trying to scope the different frame types on my bus. Data and RTR frames are no problem, but generating overload and error frames are. I am trying to generate overload frames from one of my nodes by simply sending request messages at an extremely high rate, however, I can't seem to see the overload frames that should be there. Generating Error frames on the other hand are something that I can't seem to manage at all. Have you guys any idea how to achieve this? Thanks.

 

Mike.

[John Dammeyer]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi Mike,

 

An overload frame was defined in the early CAN 1.0 spec as something to generate when the device's state machine was incapable of internally processing the message before another one would show up on the bus.  Once the CAN 2.0 A and B silicon showed up, that problem went away.  Moore's law made it possible to make smaller dies with more complicated CAN implementations.  The specification states that a node has to be able to process an overload frame if it shows up at the end of a message.  It doesn't state that a node has to be able to generate one.  I don't believe there's a CAN device out there now that would generate one.

 

When CAN is working correctly you should never see an error flag (6 dominant bits).  The easiest way to test your firmware error flag handling is to create the flag with an external bit of hardware.  You could even use a small micro to do this if you keep the bit rate low.  Just look for an recessive to dominant transition and then pull the bus to dominant and hold it there for 6 bit times.  Then let it go recessive.  If you trigger a scope on that event, you'll see the bus stay dominant for an additional 6 bit times and then the message will start again.

 

John Dammeyer

 

 

 

Automation Artisans Inc.
http://www.autoartisans.com
Ph. 1 250 544 4950

-----Original Message-----
From: canlist-owner@... [mailto:canlist-owner@...] On Behalf Of Mike Brooks
Sent: Tuesday, April 22, 2008 3:58 AM
To: canlist@...
Subject: [CANLIST] Forcing Error and Overload Frames

Hi All,

         I am trying to scope the different frame types on my bus. Data and RTR frames are no problem, but generating overload and error frames are. I am trying to generate overload frames from one of my nodes by simply sending request messages at an extremely high rate, however, I can't seem to see the overload frames that should be there. Generating Error frames on the other hand are something that I can't seem to manage at all. Have you guys any idea how to achieve this? Thanks.

 

Mike.

[Bende Georg]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hello Mike,

 

I don't think overload frames are in use anymore. Most modern controllers have some kind of mailbox or buffer management, and if you are too slow reading out in the software, they throw you an exception interrupt instead of thrashing the bus with OVR frames.

You can see nice error frames if you put a node with a different bitrate set in your network. :)

 

Good luck trying,

Georg

-----Ursprüngliche Nachricht-----
Von: canlist-owner@... [mailto:canlist-owner@...] Im Auftrag von Mike Brooks
Gesendet: Dienstag, 22. April 2008 12:58
An: canlist@...
Betreff: [CANLIST] Forcing Error and Overload Frames

Hi All,

         I am trying to scope the different frame types on my bus. Data and RTR frames are no problem, but generating overload and error frames are. I am trying to generate overload frames from one of my nodes by simply sending request messages at an extremely high rate, however, I can't seem to see the overload frames that should be there. Generating Error frames on the other hand are something that I can't seem to manage at all. Have you guys any idea how to achieve this? Thanks.

 

Mike.

[heikki.saha]

Hi all,

I just needed to think about CiA definitions for max. single and
cumulative dropline length definitions. In some CiA documents 300mm
and 1500mm are defined. I read Philips AN96116 and after taking 1Mbps
CANopen bit-timing parameters:
  125ns/TQ
  Tprop=4*TQ = 500ns
  Transceiver loop-delay = 150ns

=> Lu < Tprop/(50*Tp)

   Lu < (500ns - 150ns)/(50 * 5ns/m)

   Lu < 1.4m

Respectively cumulative dropline length of 7m results.

Can anybody tell me what is behind the difference?

Best regards,

-H
----------------------------------------------------------------------
Heikki Saha        Sandvik Mining and Construction Oy
M.Sc.              P.O. Box 100         Tel(dir): [phone]
Research Engineer  FIN-33311 Tampere    Fax: [phone]
Automation Systems Finland              Email: heikki.saha@...


This e-mail is confidential and it is intended only for the addressees. Any review, dissemination, distribution, or copying of this message by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error, kindly notify us immediately by telephone or e-mail and delete the message from your system. The sender does not accept liability for any errors or omissions in the contents of this message which may arise as a result of the e-mail transmission.

[Corrigan, Steve]

Hello Heikki,

 

This mostly depends upon the margin of safety you design into your bus. Since stub-lines are unterminated, signal reflections can develop in a stub that drive signal levels back and forth across a receiver's input thresholds, creating errors.  Bit-sampling occurs near the end of a bit, so it is mandatory that all signal reflections in a CAN stub-line be attenuated before or during the propagation delay segment to provide an adequate margin of safety.

To minimized reflections, stub-line length should not exceed one-third (1/3) of the line's critical length.  Beyond this stub-length, many variables come into play since the stub is no longer considered to be a lumped parameter, and is the maximum length that a stub remains invisible to a transmission line.  The critical length occurs at the point where the down-and-back propagation delay (tprop(total)) of a signal through a line equals the transition time(t_t) of a signal (the greater of the rise or fall times).

                                     Network Critical Length = t_t = tprop(total)

Therefore, a typical CAN driver may have a 50 ns transition time, and when considering a typical twisted-pair transmission line prop delay of 5 ns/m, the down-and-back delay for one meter becomes 10ns/m.  The critical length becomes 5 m (50 ns / 10ns/m = 5 m), and the max un-terminated stub length for the network is 1/3^rd of the critical length, or 5/3 m (1.67 m).

When critical length is taken into consideration, driver slew-rate control becomes a valuable design asset.  The Standard recommends a maximum un-terminated stub length of 0.3 m with a 1 Mbps signaling rate, but with slew rate control, reduced signaling rate, and careful design, longer stub lengths are easily obtained.

For example, if a 10 kΩ resistor is applied for slope-control at the Rs pin (pin 8) of the HVD230 CAN transceiver, a 160 ns driver transition time increases the maximum stub length to 16/3 m or 5 1/3 meters.

Hope it helps,

Steve C.

---

From: canlist-owner@... [mailto:canlist-owner@...] On Behalf Of heikki.saha@...
Sent: Sunday, May 04, 2008 9:22 AM
To: canlist@...
Subject: [CANLIST] CANopen bit timings

Hi all,

I just needed to think about CiA definitions for max. single and
cumulative dropline length definitions. In some CiA documents 300mm
and 1500mm are defined. I read Philips AN96116 and after taking 1Mbps
CANopen bit-timing parameters:
  125ns/TQ
  Tprop=4*TQ = 500ns
  Transceiver loop-delay = 150ns

=> Lu < Tprop/(50*Tp)

   Lu < (500ns - 150ns)/(50 * 5ns/m)

   Lu < 1.4m

Respectively cumulative dropline length of 7m results.

Can anybody tell me what is behind the difference?

Best regards,

-H
----------------------------------------------------------------------
Heikki Saha        Sandvik Mining and Construction Oy
M.Sc.              P.O. Box 100         Tel(dir): [phone]
Research Engineer  FIN-33311 Tampere    Fax: [phone]
Automation Systems Finland              Email: heikki.saha@...


This e-mail is confidential and it is intended only for the addressees. Any review, dissemination, distribution, or copying of this message by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error, kindly notify us immediately by telephone or e-mail and delete the message from your system. The sender does not accept liability for any errors or omissions in the contents of this message which may arise as a result of the e-mail transmission.