CAN Bus: dynamic CAN ID?

For a new device generation communicating with CANopen I d'like to implement
dynamic assignment of CAN ID's. It should work like DHCP in TCP/IP!

Idea: a special CAN ID (with serial number as data)  is reserved for request
the master for the individual CAN ID. Each CAN slave asks after boot-up the
master with his unique serial number for the CAN ID. The slave with the most
dominant serial number has priority.

Motivation: the actual dip switch for CAN ID is a big problem for our
support (multiple identical CAN ID's)!!

Any tips?

Thanks very much!

Regards
Markus

Markus Forrer wrote:
> For a new device generation communicating with CANopen I d'like to implement
> dynamic assignment of CAN ID's. It should work like DHCP in TCP/IP!
> 
> Idea: a special CAN ID (with serial number as data)  is reserved for request
> the master for the individual CAN ID. Each CAN slave asks after boot-up the
> master with his unique serial number for the CAN ID. The slave with the most
> dominant serial number has priority.
> 
> Motivation: the actual dip switch for CAN ID is a big problem for our
> support (multiple identical CAN ID's)!!
> 
> Any tips?
> 
> Thanks very much!
> 
> Regards
> Markus
> 
> 

This is a good idea: we use it. ;-)

We have the slave nodes repeatedly (with a time delay, of course!)
broadcast the wakeup message with serial number. Eventually, when the
master comes alive it will respond with a broadcast that contains the
slave's serial number and actual CAN ID.

The master keeps a table containing the slave's serial number and
assigned CAN ID. It can keep track of slaves rebooting, etc. using the
table.

-Rich
-- 
Richard Pennington
Email: rich@pennware.com
http://www.pennware.com ftp://ftp.pennware.com

Hy Rich


> This is a good idea: we use it. ;-)

Wow, super!


> We have the slave nodes repeatedly (with a time delay, of course!)
> broadcast the wakeup message with serial number. Eventually, when the
> master comes alive it will respond with a broadcast that contains the
> slave's serial number and actual CAN ID.

Do you use a special CAN ID for broadcast messages? Is BROADCAST a special
message?

I think, it looks like that:

slave: CAN ID=1000h, rtr=1, Byte 0..5=serial number
master: CAN ID=1000h, rtr=0, Byte 0..5=serial number, Byte 6..7=CAN ID

Thank you very much for your hints!

Markus

On Wed, 11 Aug 2004 08:45:08 +0200, "Markus Forrer" <markus_5@gmx.ch>
wrote:

>For a new device generation communicating with CANopen I d'like to implement
>dynamic assignment of CAN ID's. It should work like DHCP in TCP/IP!
>
>Idea: a special CAN ID (with serial number as data)  is reserved for request
>the master for the individual CAN ID. Each CAN slave asks after boot-up the
>master with his unique serial number for the CAN ID. The slave with the most
>dominant serial number has priority.
>
>Motivation: the actual dip switch for CAN ID is a big problem for our
>support (multiple identical CAN ID's)!!
>
>Any tips?

Have a look at CANopen specification 'DSP 305 Layer Setting Services'.
I think it contains the things you want to do, but as standard
solution.

There the (slave-) modules have a unique address at startup which
contains some device information including the serial number to
identify it.
Tthere are defined messages for node-id and baud settings.

Maybe it helps
Peter 

--
Bitte nur in der Gruppe antworten.
Please reply only in the group.

On Wed, 11 Aug 2004 08:45:08 +0200, "Markus Forrer" <markus_5@gmx.ch>
wrote:

>..The slave with the most
>dominant serial number has priority.

Are you sure the priority resolution extends into the data?  I thought
that CAN priority resolution ended one bit after the ID field, in
which case two transmitters with the same ID would just continue
transmitting and possibly corrupt each other's data.  You could rely
on the CRC to detect this, but this would be a non-standard use of
collision detection in CAN.


-Robert Scott
 Ypsilanti, Michigan
(Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)

Markus Forrer wrote:

> Hy Rich
> 
> 
>> This is a good idea: we use it. ;-)
> 
> Wow, super!
> 
> 
>> We have the slave nodes repeatedly (with a time delay, of course!)
>> broadcast the wakeup message with serial number. Eventually, when the
>> master comes alive it will respond with a broadcast that contains the
>> slave's serial number and actual CAN ID.
> 
> Do you use a special CAN ID for broadcast messages? Is BROADCAST a special
> message?
> 
> I think, it looks like that:
> 
> slave: CAN ID=1000h, rtr=1, Byte 0..5=serial number
-----------------------^^^^^--^^^^^^^^^^^^
> master: CAN ID=1000h, rtr=0, Byte 0..5=serial number, Byte 6..7=CAN ID

According the CAN spec 11898, an RTR message contains _no_ data bytes.

> 
> Thank you very much for your hints!
> 
> Markus
Besides this small problem above, I would support what Peter Wucherer said
use LSS - the CANopen Layer Setting Services - if you are really talking
about CANopen. Otherwise do what you like, but don't call it CANopen.
This standard DS305, is used already by a lot of manufacturers, especially
for sensors, where size and environmental protection counts. 

Regards
  Heinz  


-- 

with best regards / mit freundlichen Grüßen

   Heinz-Jürgen Oertel
+===================================================================
| Heinz-Jürgen Oertel  port GmbH  http://www.port.de
| mailto:oe@port.de
| phone +49 345 77755-0     fax   +49 345 77755-20
| Regensburger Str. 7b,     D-06132 Halle/Saale,  Germany 
| CAN Wiki    http://www.CAN-Wiki.info
| Newsletter: http://www.port.de/engl/company/content/abo_form.html
+===================================================================

On Wed, 11 Aug 2004 13:26:49 +0200, "Markus Forrer" <markus_5@gmx.ch>
wrote:

>slave: CAN ID=1000h, rtr=1, Byte 0..5=serial number
>master: CAN ID=1000h, rtr=0, Byte 0..5=serial number, Byte 6..7=CAN ID

CAN ID 1000h would suggest a 29 bit identifier.

Are there really CanOpen implementations using 29 bit identifiers
(instead of 11 bit identifiers) ? 

If both 11 and 29 bit identifiers are used at the same bus, the 29 bit
1000h identifier would have a bus priority between the 11 bit 000h and
001h identifiers.

Paul
   

Thanks for all your hints!

Regards
Markus

I'll let you know where to send the check.

> Thanks for all your hints!
>
> Regards
> Markus
>
>