CAN addressing

[Subramanian, Ramkumar]

Hi John,

Thanks for your reply. I thought addressing on CAN is done in software. I didn't quite understand about the part addressing it in hardware. The id register in and ID mask register in CAN controller won't it take care of which receipient should reply. Are we talking about physically identifying who was responsible for opening or closing a valve. If I use couple of GPIO pins on a micro, read the state of the pin and send that as physical node identification in CAN message so that now I know which node is transmitting the message and to which node it is addressed. Correct me if I was wrong.

 

Thanks

Ram

[John Dammeyer]

Hi,

 

For people coming from other network topologies the CAN addressing model can be a bit confusing.  Every ID that is sent on the bus needs to be unique to avoid duplicate IDs with different Data.  So generally part of the ID has the source NodeID value embedded in it.  Since no other module has the same NodeID all IDs are guaranteed to be unique.

 

That can change where there is a Master of course.  Using a established protocol solves your problems.  CANOpen or DeviceNet or NMEA2000 or J1939 or MilCAN etc. make it easier to create hardware because you don't have to think about all the network issues.

 

However, there are applications that the above network HLPs don't address well.  My Olympic Rings was an example in point.  I had 750 nodes to deal with.  Each node is phsysically and firmware wise identical and interchangeable.  At most I can have about 120 nodes on a single CAN bus.

 

My solution was to first design in the DS1822 temperature sensor and serial # chip from Dallas Semi.  Now I could be guaranteed that in some way each node was unique.  However, the serial number is larger than a 29 bit ID and so duplication on the lower 29 bits was possible.

 

Because the rings were mechanically built in 3 segments per ring I set it up to have 3 segments of 50 nodes each on the last 10m of a 35m long cable.    Each cable was brought back to the control cabinet where they connected to a TKE CAN Bridge.  The 5 CAN bridges connected to a 9S12 board with 5 CAN modules.  So one Bridge per ring.  One CAN network per ring.  Total number of nodes per ring was 150 starting at node ID #2 and going up to node ID #151.  Node ID #0 was reserved for global messages (higher priority too) and NodeID #1 was the default as programmed brand new node.  It would be possible to have a full network of 150 nodes all with ID #1.

 

So I have 5 rings each with identical node IDs on 5 separate CAN buses.  Each node has been programmed with one of those node #'s. 

 

So the real question is what happens when I want to get information from a node.  The application knows which ring so we're down to just one CAN bus.  The NodeID # is embedded into the ID along with a Client/Server bit set to Client.  The node replies to a query with the Client/Server bit set to Server.  And there you have it.  Unique IDs. No duplication.

 

If all the nodes had the same ID# I can send out a message to all nodes (#0) with the serial # of the device in the Data part along with a new node #.  Only the node with a matching serial # will set it's node ID to the new value.  The others ignore the message.

 

The key thing is to know the serial #.  With the serial # and an unused nodeID I can also set a lamp to node 200 for example and then tell the lamp to turn on after sending a global message to turn all lamps off.  Now I have one lamp on.  I can look to see where it is and decide that way where the lamp is physically located and then assign the correct nodeID.

 

The above description is just one way of handling a massively large network.  I welcome descriptions from others as to how they've done things.

 

John Dammeyer

 

 

 

 

 

 

 

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

-----Original Message-----
From: canlist-owner@... [mailto:canlist-owner@...] On Behalf Of Subramanian, Ramkumar
Sent: Friday, August 14, 2009 10:27 AM
To: canlist@...
Subject: [CANLIST] CAN addressing

Hi John,

Thanks for your reply. I thought addressing on CAN is done in software. I didn't quite understand about the part addressing it in hardware. The id register in and ID mask register in CAN controller won't it take care of which receipient should reply. Are we talking about physically identifying who was responsible for opening or closing a valve. If I use couple of GPIO pins on a micro, read the state of the pin and send that as physical node identification in CAN message so that now I know which node is transmitting the message and to which node it is addressed. Correct me if I was wrong.

 

Thanks

Ram