1. Home
  2. Embedded Programming
  3. CAN Bus: dynamic CAN ID?

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

Reply to
Markus Forrer
Loading thread data ...

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
Reply to
Richard Pennington

Hy Rich

Wow, super!

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

Reply to
Markus Forrer

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.

Reply to
Peter Wucherer

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

Reply to
Robert Scott

-----------------------^^^^^--^^^^^^^^^^^^

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

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+===================================================================
Reply to
H.-J.Oertel

Thanks for all your hints!

Regards Markus

Reply to
Markus Forrer

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

Reply to
Captain Bly

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.