Connect with us

Advise on industrial system

Discussion in 'Microcontrollers, Programming and IoT' started by wmitc2375, Nov 10, 2012.

  1. wmitc2375

    wmitc2375

    10
    0
    Nov 10, 2012
    I am a veteran programmer and somewhat familiar with electronics. I have an Arduino microprocessor which supports I2C. I am wanting to build an industrial application which will consist of 5 foot “bars” each having 4 LEDs. I need the ability to daisy-chain these bars out from the microprocessor and control any combination of turning on/off the LEDs on each bar. I am considering using I2C with extender boards http://sjtbits.com/i2c-to-differential-breakout-board/ but need some serious help in understanding if this is a practical design. The LED “bars” will be about 8 feet apart and on my application there will be a total of 24 bars each having 4 LEDS. I am considering using CAT5 wiring and connectors to daisy-chain and hopefully carry enough voltage to drive the system. Thanks for any advise on how to build such a system.
     
  2. Harald Kapp

    Harald Kapp Moderator Moderator

    9,367
    1,903
    Nov 17, 2011
    Suggestion:

    Use a 4 bit shift register (serial in, parallel out) for each bar.
    Connect one LED to each parallel output (use a simple transistor LED driver if you need more power that the shift register IC can deliver).
    Make an input connector to the bar having the following connections:
    - Supply Vcc and GND
    - Clock in
    - Data in

    Add a couple of bypass capacitors between VCC and GNG: 10µF electrolytic or tantalum plus for each CI on the bar 100nF ceramic very close to each IC.

    Add a Schmitt trigger buffer (or 2 Schmitt trigger inverters in series) between Clock in from the input connector and clock in of the shift register IC.
    Add a Schmitt trigger buffer (or 2 Schmitt trigger inverters in series) between Data in from the input connector and data in of the shift register IC.
    The Schmitt triggers will make the system more robust against noise, especially at cable lenght up to 5 m. You may have to insert an additional low pass (RC) between the input connector and the Schmitt trigger buffers.

    Make an output connector from the bar the following connections:
    - Supply Vcc and GND
    - Clock out from the input of the shift register via an additional buffer (see above)
    - Data out from the 4th bit of the shift register via an additional buffer (see above)

    This setup allows you to daisy-chain the bars. Note that you cannot set or reset single LEDs this way. You will have to shift the full string into the resultinhg n*4 bit shift register. If done fast, the flicker from shifting will not be noticeable.
    If the flicker annoys you, you can resort to shift registers with built-in latches. You will thenn have to supply an additional "latch" line (buffered per bar by Schmitt triggers as above). You can then shift a control string into the shift register while the old state is still held by the latch. No flicker on the LEDs. When the shift register contains the full string, latch it into the output register by toggling the "latch" line.

    Harald
     
  3. wmitc2375

    wmitc2375

    10
    0
    Nov 10, 2012
    Harald,

    Thanks so much for taking the time to provide a detailed explanation of how to build the circuitry needed for my project.

    I did spend a good bit more time yesterday searching for possible solutions and believe I might have found something that could work well for my project. Here is what I found -

    http://docs.macetech.com/doku.php/shiftbrite_2.0

    Interesting enough, because these LEDs are tri-color, I have now reconsidered how my system might work such that instead of showing different configurations on the bars one at a time and having the operator need to switch between configurations, I could light all the LEDs at once with a series of different colors to designate which yarn goes on which hangar.

    So it looks very promising. Also, if I were to stick with just a single color LED, this other product the same company makes looked ideal -

    http://docs.macetech.com/doku.php/shiftbar

    I realize it is a bit more plug-and-play and probably a bit more costly using these tri-color LED modules than a custom built circuit from individual components but the main cost of my system will be in the software control side and so a nominal increase in hardware cost should be ok. The LEDs with the shift-register logic built onto the IC board are around $5. The company also sells varying lengths of 6-pin ribbon cable with connectors on each end for the headers of the ShiftBright LEDs modules. Interesting enough, the data sheet for this product has a sample application using the same Arduino micro controller I plan to use. So it appears to be a good fit.

    I think that for my configuration, I will need to supply a 5v drop every so many bars and am still a bit unsure on how to wire that up. Since the modules use six lines, I am considering still using CAT-5 between the bars and using the two remaining wires for some type of ground and 5V+. Again, not having a strong electronics background, I don't know exactly how to keep a constant 5V+ across the circuit so if you have any thoughts, I would sure appreciate them.

    Best Regards,
    Bill
     
  4. Harald Kapp

    Harald Kapp Moderator Moderator

    9,367
    1,903
    Nov 17, 2011
    Use a line voltage higher than 5 V and a 5V voltage regulator per module (or one regulator every 4-5 modules). An 7805 can do the job at >5 V input voltage. Don't forget to add some filter capacitors.
    You could use a buck regulator (step-down) instead of the venerable 7805. This allows you to use an even higher line voltage while reducing the current on the line. This is due to the higher efficiency of a switch mode regulator vs. a linear regulator. There are even 7805 compatible switch mode modules out there.

    Harald
     
    Last edited: Nov 11, 2012
  5. wmitc2375

    wmitc2375

    10
    0
    Nov 10, 2012
    Thanks again Harald! I will look into this more.
     
  6. KrisBlueNZ

    KrisBlueNZ Sadly passed away in 2015

    8,393
    1,266
    Nov 28, 2011
    This sounds like an interesting project!

    As Harald suggested, I would definitely use a high-ish DC voltage (e.g. 36 VDC) on the power wires, and convert down to 5V (or whatever) locally in each bar using a switching converter. This reduces the current being carried by the connectors and the wires, which is important if you're daisy-chaining, since the connector and wires at the supply end will be carrying all the current for all the bars, like the turtle at the bottom of the tower in the Yertle the Turtle story!

    I'm concerned about signal integrity over such a long distance (200 feet). Even just eight feet is significant. Differences in ground voltage between the bars will occur due to current flow in the wires between them, and inductive and capacitive coupling, and this can cause data corruption and component damage if DC-coupled signals such as I2C and SPI are used.

    I suggest using optocouplers on the signals. Serial data (asynchronous at, say, 9600~57600 bps) is probably the way to go, since there's only one signal in each direction. You should have some way for your controller to check that a command has been received correctly by the bar that it's addressed to.

    Alternatively, RS-485 or Profibus (which uses RS-485) is appropriate for industrial multipoint communication over significant distances, but may be unnecessarily complicated and unnecessarily fast.

    In any case, I'm imagining a microcontroller in each bar, and communication using short messages with CRC (cyclic redundancy check - a powerful type of checksum). Is that within your budget for both time and materials?

    You might be able to find modules that already have an RS-485 interface, that you can use as-is or reprogram. They would end up more expensive than a roll-your-own solution but the time saved might make it worthwhile.

    A bit more background information would help us to focus better on your needs.
     
  7. Harald Kapp

    Harald Kapp Moderator Moderator

    9,367
    1,903
    Nov 17, 2011
    I agree concerning profibus.

    I disagree concerning RS485. You don't have to use a UART protocol. Just use the differential drivers and receivers that are used for RS485 and send any protocol (including I²C over the line. that way it is not going to be difficult at all.

    Also using photocouplers is a good idea to improve noise immunity.

    If you use a line voltage markedly higher than 7V you should use step-down regulators locally for each bar. Otherwise you will not profit from low line currents and accordingly low losses on the line.

    And by the way: Since many shift-register chips are organised by 8, consider making each bar 8 LEDs long instead of the planned 4 LEDs.

    Harald
     
  8. KrisBlueNZ

    KrisBlueNZ Sadly passed away in 2015

    8,393
    1,266
    Nov 28, 2011
    This project is to be used in an industrial setting. I wouldn't use a protocol with no error detection, even on a single signal; adding multiple signals that all have to be correct is even worse. And I2C is an open-collector multi-drop bus which is not suited to being transferred over RS-485 (I think there are tricks that can be used though). That's why I think he should use a message-based protocol with a micro in each bar.

    Edit: An alternative would be to use an unchecked protocol with a continuous update stream, and just put up with all the bars blinking to the wrong colour each time a machine starts up :)
     
    Last edited: Nov 12, 2012
  9. wmitc2375

    wmitc2375

    10
    0
    Nov 10, 2012
    Hi Harald and Kris,

    I got word back from MaceTech the makers of the "shift register" LED modules.

    Here is the main piece of that email -

    Additionally, the data communication interface is prone to electrical noise, and doesn't do well over long wire runs. We typically see problems with ShiftBrites if the cable is more than two feet long.

    These problems are commonly solved in industry (specifically the one I was in) by using a differential signaling interface. In most cases, RS485, which can use a twisted pair of wires to pass data thousands of feet with good noise immunity.

    What I'd suggest is a more custom solution. If you control the part list and the PCB design, you can get as many of these made as you need in the future.

    I don't know what type of lights you plan to operate. I'm assuming some type of industrial indicator, maybe running on 24V? Or maybe just a standard single LED? In any case, I'd need to know the maximum supply voltage and current for the LEDs.

    If I were to design a solution, I'd base it on one of these:
    http://www.digikey.com/product-detail/en/TPIC6C595N/296-2020-5-ND/276260

    That has 8 channels, but of course you don't need to use them all. It's a shift register (serial data in one end, and out the other) but can sink 100mA or so per channel. Just on and off, which is all you need.

    Now, the data interface is still 5V, and susceptible to industrial noise. It requires three control lines to operate, and to chain to the next bar. I'd use six of these per bar:
    http://www.digikey.com/product-detail/en/SN75176BP/296-1739-5-ND/277385

    One for each differential pair leading in and out of the bars. I may be able to reduce the part count and cost by finding a single chip with multiple transceivers, or complementary driver and receiver chips. Additionally, there would need to be a voltage regulator.

    So, the final design would include four to seven small chips, all through hole. Two or four RJ45 connectors (depending on how you want to configure the inputs and outputs). Maybe a PCB at one end of the bar with all the logic and two RJ45 connectors, and a PCB at the other end with two more jacks and a cable connecting it to the first PCB. Then, connectors and internal wiring for all the LEDs on the bars. This could be screw terminals for individual wires, or some kind of pluggable connector.
     
  10. wmitc2375

    wmitc2375

    10
    0
    Nov 10, 2012
    @Harald -

    The four LEDs per bar is based on the physical layout of the equipment these indicators would be used on. I think I would just shift extra zeros into the unused bits of the registers so the daisy-chained downstream registers would get the correct data pushed along the chain.
     
  11. wmitc2375

    wmitc2375

    10
    0
    Nov 10, 2012
    I realize I did not state earlier but after some consideration of system design, I realized I did not have to use I2C and individually address each LED but rather could just use a shift register type approach where I send the entire data stream for all lights in the chain each time something needs to change. The project is for showing "full sets" of lights being on or off so this is ideal in that I already know which lights are to be on and off for the full series. Hope that helps.
     
  12. wmitc2375

    wmitc2375

    10
    0
    Nov 10, 2012
    From what I understand about these shift registers, I could set a certain line to bring all outputs low, latch that to the outputs to turn all the LEDs off then shift in all the data for all the registers which spills over to the next, and once all are loaded, "latch" the data onto the outputs which would turn on the correct LEDs. Supposedly ,this prevents the flickering effect.
     
  13. KrisBlueNZ

    KrisBlueNZ Sadly passed away in 2015

    8,393
    1,266
    Nov 28, 2011
    So you're suggesting an interface with:

    +V and 0V (thick wires and connector pins, or multiple)
    Data (RS-485 differential, 2 wires) (downstream)
    Data clock (ditto) (downstream)
    Latch clock (ditto) (downstream)

    Each bar would receive those three signals, and re-transmit them to the next bar; data clock and latch clock would just be buffered, and data would have an 8-bit delay.

    If your controller updates all outputs continuously, then the worst that can happen is brief incorrect indications on all bars on each burst of interference.

    As well as a shift register such as the TPIC device suggested in that email from MaceTech, this arrangement needs three RS-485/422 receivers and three transmitters. Those aren't cheap; optocouplers a small micro would be cheaper, and would also allow your controller to detect how many, and which, bars were connected, and to detect a disconnection or failure anywhere. That's why I suggest a message-based serial protocol. I guess it depends on your priorities.
     
  14. wmitc2375

    wmitc2375

    10
    0
    Nov 10, 2012
    Hi Kris,

    Thanks for the continued feedback to my quest for a good design. Being new to these devices, can you give me an idea on how these optocouplers could tell the Arduino how many of them are connected? That sounds interesting. And of course the detect of a disconnection certainly sounds like a good thing.
     
  15. KrisBlueNZ

    KrisBlueNZ Sadly passed away in 2015

    8,393
    1,266
    Nov 28, 2011
    It's not the optocouplers that make the difference; it's the idea of using a serial, message-based protocol, with a microcontroller in each stick. You could just as well use RS-485 for the physical connection.

    Those features require that the bars communicate back to the controller. With the physical topology being a daisy-chain, there are two data topologies that I can think of: a single RS-485 data bus with all devices communicating on the same wires, like Profibus, or individual point-to-point connections between bar n and bar n+1. The former would require less components (only one RS-485 transceiver for each bar) but the latter would be more reliable over a total distance of 200 feet, and you could use optocoupled data, which would be cheaper than RS-485.

    Unfortunately, the latter would also require two serial ports on each micro - one for upstream communication with the controller or with bar n-1, and one for downstream communication with bar n+1. But if the data rate is low enough, the UARTs can be implemented in firmware. Each micro would have to forward requests downstream, and responses upstream, as well as dealing with requests and responses for its own bar.

    Bars could be addressed according to their position in the daisy-chain, and/or by a number that's associated with each bar (set on a DIP switch or similar).

    The major advantage of having intelligence in each bar is that the controller can be sure it's talking to something, and can make sure the message has been correctly received, or retry it if it hasn't, and report an error if all retries fail.
     
    Last edited: Nov 13, 2012
  16. KrisBlueNZ

    KrisBlueNZ Sadly passed away in 2015

    8,393
    1,266
    Nov 28, 2011
  17. wmitc2375

    wmitc2375

    10
    0
    Nov 10, 2012
    Kris,

    Very cool! I will do some more reading on these. So this would pretty much eliminate the whole electronic noise over wire issue?
     
  18. KrisBlueNZ

    KrisBlueNZ Sadly passed away in 2015

    8,393
    1,266
    Nov 28, 2011
    Yes, and it provides electrical isolation too. You could even power the bars independently (assuming power is available at each bar's location), so the only connections between the bars would be the optic fibre.

    But you would need to use some kind of serial protocol. If you used a simple SPI protocol over optic fibre, you would need three fibres - for data, data clock, and latch clock. You would need each bar to act as a repeater, since optic fibre can't be multi-dropped. So this would require three transmitters and three receivers per bar, and you still wouldn't have any way to detect errors or breaks.

    Assuming you use serial comms, if you want bidirectional communication, each bar will need to have a micro with two serial ports (or serial ports implemented in firmware), and two POF transmitters and two receivers.

    The other option would be a ring topology. Data would flow from the controller to bar 1, then from bar 1 to bar 2, then from bar 2 to bar 3, and so on, and the output from the last bar would feed back to the controller to complete the loop. This would use only one optic fibre between bars, and only one transmitter and one receiver per bar, but it would be harder to deal with physically. Also, if there is a break anywhere in the loop, the controller would detect it, but couldn't tell you where it was. Again you would use serial data rather than SPI.

    Edit: Can you tell us more about your speed and frequency requirements? How often do updates need to be sent? And what is the maximum allowable delay for getting data to the last bar? Any other general information about this project?
     
    Last edited: Nov 13, 2012
  19. wmitc2375

    wmitc2375

    10
    0
    Nov 10, 2012
    Hi Kris,

    I have also been chatting with an independent developer of solutions and he is drafting me a proposed PCB design which will use the RS-485 to move data. At some point in several chats, he offered to make a design which I took him up on. I will keep you posted on what I receive back. Thanks again for allyour help.
     
  20. KrisBlueNZ

    KrisBlueNZ Sadly passed away in 2015

    8,393
    1,266
    Nov 28, 2011
    Good! I hope it works out. I would be interested to see what he is proposing.
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-