Actions
Forum Thread Details
  • Replies 33 replies
  • Subscribers 320 subscribers
  • Views 3052 views
  • Users 0 members are here
Related
See a helpful answer?

Be sure to click 'more' and select 'suggest as answer'!

If you're the thread creator, be sure to click 'more' then 'Verify as Answer'!

Design suggestion for a bus

amgalbu

Hello

I need to develop a custom board (hardware + software) to drive a set pneumatic valves. The requirements are

  • the boards can be stacked (up to 18 boards can be stacked, but I expect this number to be increased in the future)
  • the boards must be configuration-free (no dip-switches to set the board address)
  • the bus must be fault-tolerant: if a board in the stack breaks, the other boards should continue to work properly
  • pneumatic valves are "digital", so the bus must convey only on/off commands

An external board communicates with the stacked boards through the bus and drives each pneumatic valve indivudually

 

The only solution I can think of is to have two serial buses: the first one is an in-out bus used only to configure the address of each board in the stack and is used only when the system is switched on. The second bus connects all the boards in parallel, thus providing the required fault-tolerance

 

However, this solution is far from being elegant... Does somebody have a better idea?

 

Cheers

Ambrogio

Parents

  • How about this:

    Any serial (or parallel) bus can be used.

    • Each node has an input bus and an output bus.
    • Each node has a watchdog chip that will connect input bus to output bus if the node processor fails to pulse the watchdog.
    • The master sends an address byte and a command byte. If the receiving node address matches, then it acts on the command without passing the data to its output bus.
    • If the node address does not match the received address, the data (address and command) are passed on to its output bus - the next node in the daisy chain.
    • The master has a second input bus connected to the last output bus in the daisy chain of nodes - if the address makes it all the way back to the secondary master input, then that node address has failed.
    • If the node does not have an assigned address (it just got installed) it permanently assigns itself the first address that arrives and acts on that command and all future commands to that address.

    Doug

  • in reply to dougw

    Hello Doug,

     

    Your scheme has two issues that I think the Ambrogio wishes to avoid:

     

    1) the signal is processed by each node so one dead node means that the chain fails - the master will know but can't address the remaining good nodes.

    2) the master will know that a newly plugged node is node x of y nodes but this won't help if two are replaced at the same time (ie it isn't robust) .

     

    You can mitigate issue 1) by duplicating the bus in a suitable fail safe way or by using relays to isolate a dead node and some kind of adequately reliable watchdog circuits to operate them. Without knowing the required SIL (check on WIKI for definition and brief discussion) it isn't possible to make detailed suggestions.

     

    My personal take on it is that the problem, as described so far, is insoluble.

    Using a human to correctly plug the parts in  a chain or a star is very unreliable (in an automotive production FMEA analysis we would have given it a probability of failure of 1% or worse) .

    Any method of mitigating this issue involves identifying the actual valves.

    You can't make  a reliable system  where the master operates the correct valve via a collection of interchangeable and identical nodes unless the master can identify individual valves .

    One way you could do this is to embedded in each valve (or glue to the side of it) a reverse diode and a coding resistor, then the master could discover via the collection of drives and buses, which valve was where and operate it accordingly. (Can work with single driver board for all valves.)

    Equally you could glue the driver board to the valve and program it with a unique ID (dil switch ?), and then use any star or daisy chain arrangement you like. The master can easily spot duplicate or missing nodes.

     

    MK

  • in reply to michaelkellett

    It is tough to express a detailed solution in a few sentences, but what I was thinking is a failed node would be automatically bypassed (with a pass-through circuit such as analog switches) based on watchdog timeout.

    If the system is re-powered when a node is replaced, each node would always end up with the same address as its place in the daisy chain, regardless of how many nodes get replaced.

    Doug

Reply
  • in reply to michaelkellett

    It is tough to express a detailed solution in a few sentences, but what I was thinking is a failed node would be automatically bypassed (with a pass-through circuit such as analog switches) based on watchdog timeout.

    If the system is re-powered when a node is replaced, each node would always end up with the same address as its place in the daisy chain, regardless of how many nodes get replaced.

    Doug

Children
  • in reply to dougw

    Never trust a human !! (to replace only one node at  a time).

     

    Actually with the pass though fail safe this system wouldn't be too bad - if two nodes were replaced it would break but would know that it had been broken so could demand re-configuring.

     

    Here's an interesting challenge:

     

    If you had a set of Doug-nets, where in each one the nodes are in a different order - is it possible to design it so that two (or more) nodes can be replaced and the system still recovers correctly ? And if so how many nets  are needed and how must they be scrambled to correctly recover from any pair of nodes replaced ?

     

    MK

  • in reply to dougw

    Hi Douglas

    the external watchdog looks like a good idea... I need to check whether it meets cost and board size constraints but it's something that can be easily implemented and can give a good reliability to the whole system

     

    Thanks!

     

     

    Ambrogio