Actions
Forum Thread Details
  • Replies 33 replies
  • Subscribers 316 subscribers
  • Views 2819 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

  • A purely electrical solution is hard to imagine because of the fault tolerance. If you could lift that requirement than you could have an enable signal line for each module and the position in the stack would determine the "address" of the module by connecting it to a different signal. But if the fault tolerance means an other board should immediately take over the faulty ones function - the only solution I could come up with is dynamic address allocation. Think of something like DHCP running on the bus. Every module on connection asks for an address. A broker assigns the next free adress and if a moule fails the broker will (have to) detect this and reassign the address of the failed module to one of the previously unused ones. For the control software this would be transparent, it will always talk to the same address.

  • in reply to crjeder

    Taking this idea a little further - use Ethernet - 1 controller to switch, as many driver boards as you like connected to other ports, one dead driver board can't bring the whole system down.  If you need fault tolerance on each drive board you need very careful design, and two Ethernet ports per board and two separate networks. Similar things are done on aircraft.

     

    You could use CAN, still with 2 buses and dual ports on every board. The problem with mere duality is that you never know which of two systems is correct.

     

    MK

  • in reply to michaelkellett

    Would work but ethernet is orders of magnitude more expensive than e. g. I2C

    CAN is popular choice in those environments.

  • in reply to crjeder

    Ethernet comes into its own when you want the star connection with off the shelf cheap switch - add on cost of 100M Ethernet port to something with an ARM Cortex M3 or 4 on it is about £5, £2 for the Ethernet enabled micro, £1 for the PHY, £1 for the connector and £1 for luck ! If your cables might be longer than a couple of meters it's hard to beat on cost.

     

    If you don't need speed, or the switch, CAN or even RS232 or 4xx might be OK.

     

    MK

  • in reply to michaelkellett

    RS232 is point to point. 4xx might work, though.

    You are right, prices for ethernet have come donwn recenly. Still can't beat I2C on very short distances. The question was about stacking PCBs, that's the domain of I2C.

  • in reply to crjeder

    The problem with I2C is that it's one down/all down but it's certainly cheap.

    If you want to avoid that (ie one failure kills the bus) you need a switch, or you can mitigate the problem by using several redundant buses or there may be I2C isolators.

    'RS232' doesn't have to be point to be point, although you could argue that it isn't strictly RS232 if used this way. Thurlby Thandar instruments used to be fitted with an 'RS232' port which supported having several instruments in parallel - it's very cheap especially for short runs at logic levels (which isn't RS232 either but there isn't a good name for it - logic level asynchronous NRZ serial doesn't mean a lot to most people.)

    To come up with a real solution for the OP we would need to know a lot more about numbers, costs and the level of integrity required.

     

    MK

Reply
  • in reply to crjeder

    The problem with I2C is that it's one down/all down but it's certainly cheap.

    If you want to avoid that (ie one failure kills the bus) you need a switch, or you can mitigate the problem by using several redundant buses or there may be I2C isolators.

    'RS232' doesn't have to be point to be point, although you could argue that it isn't strictly RS232 if used this way. Thurlby Thandar instruments used to be fitted with an 'RS232' port which supported having several instruments in parallel - it's very cheap especially for short runs at logic levels (which isn't RS232 either but there isn't a good name for it - logic level asynchronous NRZ serial doesn't mean a lot to most people.)

    To come up with a real solution for the OP we would need to know a lot more about numbers, costs and the level of integrity required.

     

    MK

Children
  • in reply to michaelkellett

    Hi Michael!

    definitely the solution should be based on a RS485 bus to simplify wiring

    The customer just requires that, in case the board does not power on due to -typically- board's power supply failure, the communication continue to work.There is no safety-critical concerns there. I don't have an idea of the price he expects, but the production volume is about 20k pieces/year

     

    Cheers

    Ambrogio