element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet & Tria Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
    About the element14 Community
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Japan
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      •  Vietnam
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Experts, Learning and Guidance
  • Technologies
  • More
Experts, Learning and Guidance
Ask an Expert Forum Design suggestion for a bus
  • Blog
  • Forum
  • Documents
  • Leaderboard
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Experts, Learning and Guidance to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • Replies 33 replies
  • Subscribers 320 subscribers
  • Views 3044 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
amgalbu over 10 years ago

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

  • Sign in to reply
  • Cancel

Top Replies

  • crjeder
    crjeder over 10 years ago in reply to Robert Peter Oakes +1
    I2C adressability is an issue. E. g. a suitable device could be TPS22993 Quad Channel Load Switch with GPIO and I2C Control but it features only 3 adress pins for a max of 8 devices. But each can operate…
  • Robert Peter Oakes
    Robert Peter Oakes over 10 years ago +1
    Then by that measure, using a device like a 23017 http://ww1.microchip.com/downloads/en/DeviceDoc/21952b.pdf would give 16 valves on a board and re duce the count of boards considerably and only needs…
  • michaelkellett
    michaelkellett over 10 years ago in reply to amgalbu

    Well because Devicenet exists, uses low cost wiring, is simple enough that you might make the nodes small enough so that you could have one per valve.

     

    If you MUST have each node knowing its address without programming it must be plugged in to  a particular slot in the network (star connected) or be able to determine its position in  a daisy chained network.

     

    Both methods are quite high risk - being very susceptible to mis-plugging in the field.

     

    I'm sure that a position discovering daisy chain scheme could be devised but it's hard to imagine one that would be very reliable (all the obvious ways of doing it require nodes to actively process all messages that pass through them).

     

    My hands on experience of building machines and control electronics says use star wiring, design a reliable hardware driver and replace the whole board if it fails.

     

    If you can't get good enough reliability like that (and it wouldn't be good enough for some applications) then you are into a different realm alltogether and without very detailed information about the system I couldn't make any suggestions.

     

     

    MK

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • D_Hersey
    D_Hersey over 10 years ago

    What if you used something like a hall-effect sensor to see if your pneumatic actuator actually actuates?  Closing the loop a little farther out would cover more possible error conditions.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Robert Peter Oakes
    Robert Peter Oakes over 10 years ago

    It sounds like were at an impass here

     

    without a proper description of what solution wants to be realized, we are unable to probide any more than speculation as to what might work

     

    It is obvious that if a specefic valve has a specefic function unique to the valve then there MUST be configuration, either by the position of the controller in a pre-defined bus (Star , Linked or otherwise) or by software or by jumpers. you can NOT have a parallel system where all boards are identical and with zero configuration or knowledge of position of each control and expect it to work... sorry not going to happen

     

    the best thing right now is to provide a better description of the system operation, function and layout

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • clem57
    clem57 over 10 years ago in reply to Robert Peter Oakes

    Robert Peter Oakes

    Take a look at token ring. That may  be a wonder.image

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Robert Peter Oakes
    Robert Peter Oakes over 10 years ago in reply to clem57

    I worked with Broken Ring many many tears ago

     

    It woul dnot work in this scenario as while it is a sobust networking solution, it soes not discreminate between loation and function, only ensuring everyone gets to talk.

     

    Network address and the like higher in ther ISO Layers get to decide function and identity from a user/ unique perspective

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • amgalbu
    amgalbu over 10 years ago in reply to Robert Peter Oakes

    There is no impasse here

    Each actuator must be automically aware of its position in the chain without user intervention. Configuration should happen automatically. That's why a standard bus does noto match my needs

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • amgalbu
    amgalbu over 10 years ago in reply to michaelkellett

    Hi michael

    Which information do you need?

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • dougw
    dougw over 10 years ago

    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

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • michaelkellett
    michaelkellett over 10 years ago 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

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • dougw
    dougw over 10 years ago 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

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
<>
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2026 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube