RE: CAN Message Priority

At 125 KBPS, the bit-time is 8 microseconds.
One packet will take 584 - 1264 microsec.
How many data bytes do you have?
Standard or extended IDs?

40 packets with extended IDs and no retries will take 23.4 - 50.6
milliseconds. 

At 125 KBPS, your bus is already  47% to 101% loaded, before retries or
new requirements add other messages to it.

Unless you have NO timeliness or determinism requirements at all, a
higher bus speed sounds like a very good idea.  Or use a Master with 2
or more CAN ports, and split the nodes among them.  

I always expect a system to grow, so I consider designing for a 50% bus
load risky,  even if I'm not YET aware of any need for determinism or
timeliness.  "Give it lots of room to grow."

My rule of thumb is that if I am even THINKING about bus priority, my
bus load is too high for my determinism requirements.  

If most of your bus traffic has no timeliness constraints, but a very
few msgs do need to get on the bus quickly, "priority" can help/.  But
say you have 3 time-sensitive msgs and the packet-time is 1 ms.  The
best determinism you can have is + / - 3 ms, because there might already
be one pkt on the bus, and the other 2 timely msgs might already be
waiting before you.


>>  Should I use the SYNC method? 

I'm not familiar with 'SYNCH' but if you are near 100% bus load, I
expect that adding constraints like time windows would make it worse.  

You would gain some bus-behavior-determinism if the Master tells
everyone to send "NOW", and the data trickles in over the next 24-51 ms.
At least the staleness of data from each node would be fairly constant:
low-ID nodes would be pretty fresh,  and high-ID nodes would be
consistently 20-50 ms stale.

And normal bus behavior will be a lot like worst-case bus behavior,
since you'll have 40 nodes all in arbitration at once!  You won't be
SURPRISED by some intermittent weakness of your bus design,  that only
causes problems when every node happens to want to talk at the same
time.

What is it that you need to be consistent?  

 - Generally average freshness of data, between when each node measures
something and the master receives it? (That is, minimum average lag
between measurement and reporting).

 - some limit on the worst-case freshness, i.e. a maximum delay time?

 - Minimal jitter in reporting delays (some control loops need that)?

 - 50.000 usec between data sample-TAKING, and who-cares when it gets
reported?

 - never lose a data sample?

If you have any kind of determinism requirement, the first thing is to
have a lightly loaded bus.  (That is more like "design by brute force"
than being clever.  But I think it's wise to avoid NEEDING cleverness,
whenever possible.) 

THEN play games to optimize the kind of determinism that you need.  
But a heavily loaded bus is like trying to swim with bricks in your
pockets.

One thing I've done is to pick one node as the "conductor of the
orchestra".  That node sends out some "tick" msg regularly.  All other
nodes listen for the tick even  if they don't need any data from it.
Then they send their messages either right after they hear the "tick",
or some fixed interval after it, with the interval a function of node ID
number. 

That focuses all the "immediate reply" msgs into one time window, where
there is a lot of contention and poor determinism. But it leaves the bus
relatively free the rest of the time, when messages can expect little or
no contention for bus access, and good determinism.



Rick Corey  | 

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
jtolmanserra
Sent: Monday, December 03, 2012 10:33 AM
To: [email protected]
Subject: [CANLIST] CAN Message Priority

Hi,

I am new to CAN and am working on a project that has 40 identical nodes
and a master. Each node is a motor that has two encoders. The two
encoder values, each 32-bits, will be transmitted in PDO #1. PDO #1 is
configured in each node to transmit acyclically with an inhibit time of
50ms. Network speed is 125K.

I know that the network speed will have to be bumped up, probably to
250K or even 500K. My understanding is that it is the COB Id that
determines the message's priority for getting onto the network. I am
currently using default COB Ids (PDO #1 is 180h + Node #). It then makes
me think that the lower the node number, the higher the priority,
correct?

So one of my concerns is that with 40 nodes all sending their PDO #1s
every 50ms, is it possible for the higher nodes to NEVER get to send
their PDO? If so, then how can I get around this? Should I use the SYNC
method? And isn't that going to slow things down a bit? I'm just trying
to understand the limitations of CAN and what the best method is for a
system of 40 slave nodes.

Thanks. I appreciate all answers or suggestions!

Jeff


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

--------------------------------------------------------------------------------
Check out the new Crane Aerospace & Electronics Newsroom!
http://newsroom.craneae.com
Like us on Facebook!
http://www.facebook.com/home.php?#!/pages/Crane-Aerospace-Electronics/163305413682908

We value your opinion!  How may we serve you better? 
Please click the survey link to tell us how we are doing:
http://www.craneae.com/ContactUs/VoiceofCustomer.aspx
Your feedback is of the utmost importance to us. Thank you for your time.
--------------------------------------------------------------------------------
Crane Aerospace & Electronics Confidentiality Statement:
The information contained in this email message may be privileged and is 
confidential information intended only for the use of the recipient, or any 
employee or agent responsible to deliver it to the intended recipient. Any 
unauthorized use, distribution or copying of this information is strictly prohibited 
and may be unlawful. If you have received this communication in error, please notify 
the sender immediately and destroy the original message and all attachments from 
your electronic files.
--------------------------------------------------------------------------------

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