RE: CAN Message Priority

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

I used a bridge. 1 x CAN into 3 x CAN to 50 nodes each.  Photo on home
page here:
http://www.autoartisans.com

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

This adds overhead that will work itself out but will screw up timing a
bit.  Again, the worst case and the best assumption is to always assume
all nodes will be synchronized and will try to send at the same time.

So now at the 50mS interval you _will_ have (worst case) 40 nodes trying
to send RxPDO1, the same 40 nodes trying to send RxPDO#2 and of course
since we are on that once every 5 second interval all 40 nodes trying to
send RxPDO3.  Also, just because the moon is full it's also the 10s NMT
status heartbeat point so you get all 41 nodes (master does this too)
sending the NMT Status message.  Oh and in front of the 50mS point was the
SYNC message.

Let's add it up.

1+40+40+40+41 = 162 messages back to back.  Again at 250kbps and about
0.5mS per message we take up 81mS in this burst.  That's bigger than your
50mS window so now you have a problem.  Add in the extra 20mS overlap into
the next 50mS window and we're still at least 1mS over.  At least and as
Richard Corey mentioned, no room for retries on errors.

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

The SDO reads will add a bit of overhead but it's not your primary worry
unless you are doing one to each node in which case it's really 40  SDOs.

Anyway,  if you needed the high speed and the length becomes an issue the
Bridge from TKE in Finland that I used was able to easily handle the 1
Mbps rate I was using.   What may work for you is to design with a bridge
in the middle of the network so you can run 500kbps and the distance on
each subnet is short enough to not cause issues.  I found there was only
about a 1 message latency inside the bridge.

Or change your PDO interval.  But do design for everything being
accidentally synchronized so the messages go back to back.  In CANOpen you
can do things to help SYNC things but OTS hardware may not always support
that.

For example, milCAN has a SYNC master that issues a message on a periodic
interval.  Each SYNC message has a counter that is incremented and wraps
at message 1023 so the next one is 0.  Each node out there knows which
SYNC message it's allowed transmit after.  So you can plan which SYNC
message is followed by which motor PDO.

If you are designing your own motors or have some control possibilities
within the drives have your NMT Master also send a TxPDO with an
incrementing parameter.  On each TxPDO transmission every 50mS the number
increments and have only the motors that identify with that particular
value send their RxPDO1.  On a different TxPDO have each motor send their
RxPDO2.  And so on.

Now you are still getting periodic motor information,  some of it on 50mS
granularity and perhaps others on 100mS or even 150 or 200mS.  The most
important motors could transmit every TxPDO the least important every 8.

With some planning you can segment and partition the RxPDOs sent by the
motors so even with the 500mS and 5 Second and 10 second messaging you can
squeeze everything in without overlapping the 50mS TxPDO SYNC style
message.

Hopefully that all makes sense.  All depends on what you can make your
motors do.

John Dammeyer

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

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