Re: CAN Message Priority

"jtolmanserra" <[email protected]>
Newsgroups gmane.comp.hardware.bus.can
Message-ID <[email protected]>
Hi John,

Thanks for the explanation.  I'm not quite sure I understood your 150 node explanation because I thought you could only have 127 nodes, I'm sure you've extended the CAN network somehow, which right now is beyond me.

My biggest concern with my system of 40 nodes is network traffic.  Just to give you a better idea of what I need to do:

- Each node will transmit 3 PDOs: PDO1 @ 50ms inhibit time (this can be bumped up if needed), PDO2 @ 500ms and PDO3 @ 5s.
- Each node will also transmit their NMT status (with a heartbeat) every 10s.
- The master must also poll the nodes for other less critical data using SDO Read requests (per node):
-- 1 SDO Read @0.5s
-- 1 SDO Read @1s
-- 3 SDO Reads @ 5s

With the network length we have, 250Kbaud will definitely be possible.  If it has to be 500Kbaud, it would be borderline.  I will have to read up on how to configure using the SYNC frame.  I think at least with the SYNC, every motor will have equal access to the bus.  It's not critical that all of the motor positions be synchronized, but the faster the positions can be captured the better.  I'm guessing that I'll probably have to bump up PDO1's inhibit time a bit too.

I am now kicking myself that I didn't find this forum a few months ago!

Thanks again!

Jeff


--- In [email protected], "John Dammeyer" <johnd@...> wrote:
>
> 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: canlist-owner@...
> > [mailto:canlist-owner@...] On
> > Behalf Of jtolmanserra
> > Sent: Monday, December 03, 2012 10:33 AM
> > To: canlist@...
> > 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 <canlist-owner@...>
> >
> 
> --
> Archives and useful links: http://groups.yahoo.com/group/CANbus
> Subscribe and unsubscribe at www.vector.com/canlist/
> Report any problems to <canlist-owner@...>
>


--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[email protected]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.