RE: Error recovery using MCP2515 can controller

Hi Chuck,

Ideally you should never see the standard errors.  When the bus reaches the
point of Error Warning there is something wrong and you are best to address
the bus issues that cause the errors.  Keep in mind that CAN is not a 2 wire
bus.   It's a two signal plus ground bus and 4000 feet is a good length so
the very nature of the bus segments length can cause issues that have you
operating on the edge.  
The ground is important because if the difference in potential of the ground
at one point between a ground at another point is more than the common mode
rejection ratio of the device you will get errors.
So let's say you get errors.  Internally in the node you have to decide if
they are important enough to cause the node to shut down or just retry and
possibly become a babbling idiot node that takes down the rest of the system
In other words, the errors are important in that they shouldn't occur at all
unless you operate in a high electrical noise environment and even then the
goal should be to prevent the errors in the first place.

CAN bus systems can operate at 100% bus utilization but it's usually the
nodes that can't handle the data rates unless filtering is very strictly
addressed.  For example I ran 150 nodes(PIC18F2680)  from a Freescale 9S12.
To handle the bus loading issues (no more than 120) I used a TKE
Bridge(9S12)  which transported the messages in on one CAN port and ran then
out 3 others.  There was a 4th separate port connected to a Zanthic CAN4USB
for CANOpen control and monitoring.

And bit rate was between 1Mbps on some 30m lengths and 500kbps on the almost
40m lengths.  From  my 9S12 to the bridge I ran 500kbps but it was a short
1m cable.  Update for all 150 nodes was done at 24Hz with one message for a
pair of nodes filtering on the even/odd least significant bit and on the
rest of the message ID.  Therefore each device would only see one message
out of 75 even though there was a burst of 75 messages back to back on the
bus.  Worst case at 1Mbps that was around 10mS so the bus was mostly quiet
for 30mS.

Because we ran power to each node and there was 20m of cable to the first
node and then another 10m with 50 4.5W nodes the 28V supply voltage drop
occurred over the first 20m and then gradually over the next 10m.  We had
almost 7V drop when putting the black  meter lead on the ground at the TKE
bridge and the red meter lead at the ground on the last module.  Because the
current draw varied dynamically between 1W and 4.5W on all the devices we
saw interesting waveforms on the ground lead.  Yet, only error warnings when
we suddenly changed from 1A current draw to 8A or back.  Since we were
updating at 24Hz it caused the occasional sporadic missed message but for
the most part the system was pretty robust.  The second system that used 48V
to 55V suffered less from that issue but there a short between power and CAN
would damage the drivers.  The 28V system was immune to that.

So the bus can easily handle 100% saturation once the nodes are
synchronized.  Odds are the nodes cannot process the CAN messages at that
rate so filtering is your friend.  At worst case with 125kbps you'd see a
message every 1mS.  That's really not any worse than 9600 baud ASCII.  But,
your protocol could prevent other nodes from accessing the bus since each
message has priority built into the node ID.  Have 10 nodes sending once
every 10mS and your bus is saturated without the ability to have lower
priority messages ever winning arbitration.  So bus loading is heavily
dependent on your High Level Protocol.

In either case do handle the interrupts that occur from the various bus
errors and let your application parameters decide whether they node should
shut down or go back bus on with a warning to the central system.  

Best Regards
John Dammeyer

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





> -----Original Message-----
> From: [email protected] [mailto:canlist-
> [email protected]] On Behalf Of Chuck Hackett
> Sent: September-07-14 11:44 AM
> To: [email protected]
> Subject: [CANLIST] Error recovery using MCP2515 can controller
> 
> I have been using the MCP2515 for a couple of years now driven by an Atmel
> ATMega1284p microcontroller.  My bus is running at 125kbps.  I am
> experienced in communications software but this is my first use of CAN
bus.
> All nodes are of my design.
> 
> The basic network is functioning fine but I am really not clear on how I
> should handle error states (Bus-Off, Transmit Error-Passive, Receive
> Error-Passive, Transmit Error Warning, Receive Error Warning, etc.).
> 
> Does anyone have C/C++ driver code I can pattern after or even a flowchart
> for the firmware side of error recovery?
> 
> What "bus occupancy rate" can I expect?  I have heard someone say that I
> should only design to 30% occupancy.
> 
> Since the controller handles bus arbitration I assumed the only effect of
an
> "overloaded" bus was the possible stall of the xmit queue due to constant
> higher priority traffic.  What are the visible effects of an "overloaded"
> bus?
> 
> As background:  My hobby is ride-on live steam locomotives that run on 7
> 1/2" gauge track (http://whitetrout.net/Chuck/844) .  I am developing this
> CAN application as part of an automatic signaling system for 7 1/2" gauge
> track.  Trains are detected by the shunts that cause on the track.  My
> system supports everything using one power pair buried next to the track
as
> well as a CAT-5/6 data cable in the same conduit.  When the bus lengths
get
> too long I break the bus and insert a segment 'bridge' that forwards
> messages between bus segments.  The whole railroad is about 4,000 feet
> long
> (http://cpgrr.org) and located in Florida woods - so lightning protection
of
> the nodes and the CAN bus has been a major challenge!
> 
> Cheers,
> 
> Chuck Hackett
> "Good judgment comes from experience, experience comes from bad
> judgment"
> 7.5" gauge Union Pacific Northern (4-8-4) 844
> http://www.whitetrout.net/Chuck
> 
> 
> 
> 
> 
> --
> Archives and useful links: http://groups.yahoo.com/group/CANbus
> Subscribe and unsubscribe at www.vector.com/canlist/
> Report any problems to <[email protected]>

--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[email protected]>