RE: Error recovery using MCP2515 can controller

> From: John Dammeyer
> 
> Hi Chuck
> ....
> Since you have a long bus, the capacitor at the end with split termination
may
> not have a large impact on noise at the center of the bus.

True - I think I'll change to the split terminator and add the cap just
because I don't think it can hurt and see how it goes.

> ....
> I've not experienced that with the MCP2510/2515 devices.  By CAN rules the
> one time a node does _not_ go bus off and stop sending is when there is no
> ACK.
>  ....
> The devices still transmit when error passive.  They just no longer
contribute
> ERROR flags to damage a message they think is bad.
> ....
> A bus off situation is pretty easy.  Clear out the transmit flags.  Then
go
> bus on.    Stale data gone.  What to do with error passive for transmit is
> up to your application.  
> ....

I have changed the driver to:

Bus-Off: Discard xmit buffers and waiting messages on transition to Bus-Off.
Discard xmit messages while in Bus-Off.

'Error-Active' & 'Error-Passive':  Let controller perform its error recovery
without intervention from firmware.  Firmware monitors age of messages in
xmit queue and discards 'out-of-date' messages and possibly others depending
on memory pressure.

In my application (signal control for 7.5" gauge ride-on railroads) there
are several classes of messages:

Object Status: These messages are sent once per second (or upon 'state'
change .. on/off, etc.).  Other nodes act upon these to drive output
functions (railroad signal heads in this case) and for central display of
system status (occupied tracks, etc.).  The system is designed to handle the
loss of object status in a fail-safe manner so discarding them is not a big
issue but would be annoying if severe (delayed trains at red lights, etc.).

Statistics: These are info only (error rates, memory pressure, etc.) and are
sent about once per minute.  They are for monitoring purposes only, no
problem if discarded.

Commands: These are messages sent to drive some action.  These are responded
to at the application level and loss of response handled appropriately.
Again, not a problem if messages lost unless severe.

> There are lots of ways to queue up the data messages in such a way that
they
> have a lifetime and are pulled when stale.  That same approach can also
> insert higher priority messages ahead of lower one. 
> ....

Now that gave me a great idea - I already have a 'work queue' class builtin
to the firmware that drives the main 'Work' loop.  It supports both timed
work items and priorities.  I could just replace the current FIFO xmit queue
with this class object and get the best of both worlds: timeout of messages
and priorities :-)

> ....
> But ZigBee is better which is why I don't make a CANRF anymore.

I use ZigBee for RF links between nodes where cable is impractical.  I
prefer the cable links because they are easier for untrained people to
diagnose.  If the RF link isn't working because of someone nearby with a
misbehaving baby monitor, etc. you might need a spectrum analyzer to figure
out where the problem is.

> John Dammeyer

Are you the same John Dammeyer that is on the MACH CNC users email list?  I
run MACH on a Series I Bridgeport, Emco Maier Super 11 lathe home
conversion, Sherline lathe and mill.  Alas, I have been too busy building a
house and this signal system project to spend much time in the shop lately.
I have been using the Sherline mill to make prototype PCBs using the
'isolation milling' technique. 
 
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]>