Discovering devices on a bus


Closed Thread
Results 1 to 7 of 7

Hybrid View

  1. #1
    Join Date
    Jul 2003
    Location
    USA - Arizona
    Posts
    156


    Did you find this post helpful? Yes | No

    Default Re: Discovering devices on a bus

    I would take a look at how some of the ethernet works (sort of). You want to have a minimum and maximum timeout period. After master sends out query, each slave must wait a predetermine "random" timeout which is no less than the minimum and no more than the maximum. Whoever answers first gets first dibs at the channel. The other slaves must now re-start their timers and wait again. This is kind of expanding a bit on what Jerson mentioned.

    As an example:
    >Slaves are happily going along
    >Master sends special command to re-assign IDs
    >Slaves go into special "listening" mode
    >>Slaves start random timer to request first ID
    >>Slave response goes like this: wait for random timer
    >>>If random timer expires look at TX line to make sure it's idle
    >>>To simplify, you may add a "busy" line on a wired or configuration
    >>>If line is idle, send simple acknowledge back
    >>>Whoever "grabs" the line first, gets the first ID
    >>First slave to respond creates a "busy" condition on the TX line (or the special "busy" line)
    >>Any other slaves see this busy condition and must re-start their respective random timers
    >>Any other slaves must also increment their IDs by 1
    >Master re-starts its own timer to wait for next response
    >Slaves keep self-assigning IDs until nobody else is left
    >Master times-out and send special "back to normal" command
    >Slaves go back to their happy lives

    You could of course start adding more "intelligence" to this.

  2. #2
    Join Date
    Sep 2007
    Location
    Waco, Texas
    Posts
    151


    Did you find this post helpful? Yes | No

    Default Re: Discovering devices on a bus

    Great ideas and I appreciate the discussion. I understand the 'random' addressing of the IO boards on the chain but for my project I HAVE to have them in a linear order. For example: the 1st board is 1024, 2nd board is 1040, the 3rd board is 1056, etc. This is because I have to know what the address is of the outputs and the inputs on the board (there are 16 each).

    The addressing rotary switch idea will work but then if I forget to address a board or if I quickly address it, there will be conflicts on the bus.
    An idea I have been working is if I have a 485 network in half-duplex mode (less bus collisions), but have 2 serial channels on each IO board. The Master talks to the 1st board via the 485-IN, then the 'chain' continues to the next board by going out a 485-OUT which is connected to the next board and so on.
    For the hardware I plan on using an 18F part

    The MASTER will initiate a command and the 1st board in the chain will answer, get its address unless it already has one, and then merely acts as a forwarding node on the chain.
    This looks like it will work but my question now is at what latency cost? I have successfully driven the 485 at 57.6K but it will take some CPU time to read in the packet and transmit it back out on the chain.
    This method while adding network latency, does overcome the total number of slaves on the network as each IO board starts over <grin>.

    Criticisms or comments? Any further thoughts?
    "If we knew what we were doing, it wouldn't be called research"
    - Albert Einstein

  3. #3
    Join Date
    Dec 2005
    Posts
    1,073


    Did you find this post helpful? Yes | No

    Default Re: Discovering devices on a bus

    This is from memory so it may be slightly off but here's how ADI does it for their RS485 devices. Activated devices have addresses from 0-252 (I think) with no gaps. All start with an address of 253 (FE) and as they are added to the network, the master sends a command to FE assigning it the next available address. A variation might work for your purposes.

    Looks like they have revised it since I worked with it about 12 years ago. See Section 5.2 (p77) in their manual.
    Last edited by dhouston; - 14th March 2012 at 14:38.

  4. #4
    Join Date
    Nov 2008
    Posts
    26


    Did you find this post helpful? Yes | No

    Default Re: Discovering devices on a bus

    I've not had a chance to do much more on this but my though's were

    All slaves have fixed unique addresses, they also have a broadcast address to listen in to

    The master broadcasts a start new discovery command - slaves wait a random time and respond to master with their address

    After a period of time the master then attempts to talk to each discovered slave

    If the master can talk to the slave the slave address is marked as valid and the slave is given a mute command

    The master goes through the remaining discovered slaves as previous step

    The master then issues a retry discovery command - only slaves not muted would respond, again at random time delays

    The Process then repeats until the master can issue a retry discovery command and get no responce from any slaves - assume all slaves discovered.

    Any comments welcolme

Members who have read this thread : 0

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts