RE: CAN Message Priority

Hi Jeff,

You've got a good handle on this.

First you make a broad assumption that an average message length (29 bit
ID) is about 135 bits.  Call it 125 bits for 11 bit IDs and to make the
math simple.

If you were running 1Mbps then it's 125uS per message.  Clearly if you are
running 125Bps then it's 8 times that rate or 1mS per message.  So 40 of
those will take up 40mS of your bus time.  So it's doable although it
doesn't leave a lot of time for other nodes or other kinds of messages.

You are right that the node ID part of the COB ID reflects the priority of
the message. Therefore motor Node 1  will win out in arbitration over
motor node 40.

Here's what will happen in real life.  Eventually the nodes will
synchronize to the point where all 40 motors will try and send their
message at the same time.  So all will issue a start bit, and then the PDO
part of the COB ID and finally the actual Motor ID part.  And as expected,
motor 1 will win and send its data.  Then the next 39 try again and motor
2 wins and sends.  Then the next 38 try again... And so on.

Cool eh?

You are better off to go to at least 250kbps and use the SYNC to make
everything more deterministic.  A SYNC from the master should then capture
the motor position in each node on receipt of the SYNC.  Now even though
the last motor message is delayed by 20mS (remember now twice the data
rate) the position reflects the SYNC event point in time.

But here's where you may run into problems.  You have to make sure
filtering is enabled on your motors so that they don't accept any of the
other motor messages.  Your master has to have a big enough receive Q and
the ability to pull out the messages and process them without overruns.
Because you will have a solid block of 40 messages plus anything higher
priority that sneaks in between.  You won't want to lose any.

But it's easily do-able.  I ran 500kbps and 1Mbps with blocks of 75
messages sent to 150 nodes where each one accepted two messages (least bit
was not filtered).  The data part had message for the odd numbered node in
the first 4 bytes and data for the even numbered node in the second 4
bytes of a message.  After each block of 75 messages one of the 150 nodes
would report back with status.  So after a sweep of 300 blocks I'd have
received status from all 50 nodes.  My refresh rate was 24Hz or (41.66 mS)
so I really only used about 30% of the bus bandwidth.

John Dammeyer



"ELS! The Solution"
Automation Artisans Inc.
http://www.autoartisans.com/ELS/
Ph. 1 250 544 4950


> -----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]>
>

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