How to enumerate many nodes on a bus?

[SherpaDoug]

I am working on a new product that will have one master and 24 slaves on a 485 bus. I will number the slaves with something like the Dallas DS28CM00 serial number chip. Hopefully thousands of slaves will be built and they should all have unique numbers.
How can the master find what 24 slave addresses it has without polling millions of possible addresses or having to manually type in the addresses of the slaves?
I am sure this situation has been dealt with before. I just can't think of how.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[arunb]

Are the slaves different from each other (ie: do they all do different jobs ??).

In one of my projects I am currently working on, I have a controller (the master) and a few slaves, so a single system will consist of these modules...

1. motion control system (type 1)
2. Motion control system (type 2)
3. Display device
4. Power control device.
5. Controller (the master)

Each of the slaves have a unique single byte code. The controller sends a 'broadcast' code on the network, followed by one of the unique codes (say D), the slaves receive the broadcast but only the display acknowledges the broadcast by sending back its serial number, the controller gets the serial number and records it. This way the controller will enumerates every device that may should be found in the network.

You could create a list of codes that the controller can enumerate.

You could also modify the single byte ascii codes to say 6 byte codes ( as in MAC addresses)

Hope this was helpful...

thanks
arunb

[SherpaDoug]

Unfortunately in this case all the slaves are identical battery packs. It is an underwater robotic vehicle and most of it is filled with batteries so it can sink and run for years. I can't have the master interrogating millions of potential addresses looking for the couple of dozen installed.

I am currently thinking of using "don't care" digits in the address. So if I ask for acknowledgment from address 12XXXX I will get a reply from units 120000 through 129999. If no one replies I now know that address space is empty. If there is a reply I next interrogate 121XXX, 122XXX, 123XXX ... 129XXX and see who responds. It will be tedious but fortunately PICs are good at tedious. I think I can get it done at power-up long before the !@#$#$% PC gets around to booting.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[rnielsen]

I just had a thought (maybe it's just a brain fart) but I'm not sure if it will work or if it's what you're looking for.

If you will always have 24 packs that you need to interrogate then you could have each slave pass an array that contains the addresses of each slave that's in the loop. Have the master send a pulse on a dedicated output that is connected to a dedicated input of the first slave. This slave inserts it's address into the first location of the array and pulses an output that is connected to the next slave that's in line. The array is passed to the second slave via the RS485 line. The second slave reads this array and places it's address into the array and then signals the next slave in the same manner.

When the last slave inserts it's address into the array it pulses the master and passes the filled array to the master. The master can read this and know all of the addresses that it needs to talk to and which address is in which position.

Hopefully you get the idea that I'm trying to convey here. Maybe something like this will work for you.

Ronald

[kevcon]

What kind of data are you collecting?

Do the batteries have to be on a 485 bus?

Have you though about just using a Dallas smart battery one wire chip?

They already have a protocol for identifying chips on the chain.

[newguy]

I'm not familiar with the 485 standard or how it handles bus collisions, so this may or may not make sense.

If you have a maximum of 24 battery packs, I'd start with 16 polls of the bus to find out who is out there. Protocol is as follows:

- Master powers up and sends a 'prepare to report ID' message, followed by a short pause. Maybe send this message twice, just in case.
- Master then sends 'report 0' message. All nodes whose internal serial number ends in 0 then report. This is where the collision avoidance becomes important.
- If nothing reports within the alotted time or if there is a pause of whatever predetermined length, master moves on to next address: 'report 1'. The last address in the report command is 15 (0xF).

I'd tackle the collision avoidance with a random time delay internal to each slave. The seed value for this delay could be based on each unit's unique serial number. When the master's report command matches the unit's last nibble of its serial number, it waits this predetermined length of time before replying, and only if the bus is free.

This algorithm should be relatively easy to implement and quite fast to execute.

[ckielstra]

I'm not familiar with bus collisions on RS485 either, but maybe the enumeration method as used by the MMC flashcards can be used as a suggestion for a (partial) solution.

The old MMC card specifications before v4.0 did include a provision for multiple cards sharing the same bus lines. For this each card has a 128 bit unique Card Identification number (CID) which during Card Identification process is replaced by a shorter and easier to handle number.

The big trick is that the MMC cards start up with open collector driver outputs. After receiving a broadcast request for sending their addresses all cards will do so but meanwhile monitor the transmitted output. On detection of collision a card will immediately stop transmitting. Finally only a single card won't have detected a collission and will have transmitted it's complete address. This card is handled and goes offline. Now the detection process starts again until all cards are handled.

The MMC specification can be bought from the MMC organization but a usefull alternative is the Samsung MMC Datasheet, chapter 6.1.3 Card Identification Process:

[SherpaDoug]

The mechanics and the connectors were specified before I even heard of the project. All packs hang on a 7 wire parallel bus. 2 wires for charging, 2 heavy wires for discharging, 2 wires for 485 and one for a safety ground. I tried it talk them into I2C bus but powers that be don't trust I2C for "long" distances like the 5 foot length of this vehicle. I2C handles collisions nicely.

The data is mostly state of charge, temperature, whether the battery has taken itself off line and why.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[kevcon]

I hate when that happens

If you are using Dallas serial number chips, you may still be able to use the one wire protocol for identifying nodes on a buss.

The individual would pics interpret the commands from the master like the one wire part would.


http://pdfserv.maxim-ic.com/en/an/AN187.pdf

EDIT:
wait, let me think about this more.....stay tuned

[arunb]

Since you have fixed the total nodes to be 24, you could assign 24 unique codes to each of the slaves, the master could have a list of the codes that need to be addressed....

thanks
arunb

[SherpaDoug]

Hopefully tens of thousands of nodes (battery packs) will be built, warehoused, and sent out to customers as replacement parts. Each must have a serial number for stocking purposes, but that will be 6 digits, too many to search singly at boot time. But using don't care digits I can search 100,000's, then search 10,000's, then 1000's and so forth to speed things up. I'll have to work up a search algorithm unless I can find one.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[Neutone]

[newguy]

[arunb]

What happens if some of the units are defective (or not able to receive the command), how will you ensure synchronisation between the nodes ???

thanks
arunb