Concept Systems Lead Designer, Donavan Moore, takes you through the basics of control design.
Using a distributed I/O system has many benefits but before you start designing, consider the following factors:
- Proximity of the devices to the local rack
- Quantity of items
- Shipping breaks
- Voltage drops
- Speed of communications
Of these factors, the most important to consider is distance between the devices and the local rack, AND whether there are enough points of I/O in the same vicinity to warrant:
- The added cost of a communication module
- The added cost of a new enclosure
- The design time to develop a separate I/O control enclosure or distributed I/O scheme
A specific distance and exact number of QTY alone will not determine the need for distributed I/O. However, in general once equipment is 50-75 feet from the local rack and there are 8-12 individual connection points, consider a distributed I/O solution. At that point, the savings in wire and routing simplification begins to offset the additional hardware and design costs incurred.
If the machine requires a shipping break (meaning the machine is modular for shipping purposes), a distributed I/O structure is fantastic advantage over home runs back to the local rack. The reduced time to break down the machine, setup the machine onsite, and debug on startup typically justifies the additional cost of the distributed I/O system. Reduced documentation and lower hardware costs also add to the appeal of distributed I/O.
Another reason for using a distributed I/O scheme would be to mitigate the risk of voltage drop. Our designers get nervous anytime you have low voltage (24VDC) connections more than 200 feet away from the source. At that distance, we start watching our device loads like a hawk knowing that we’re in the range where voltage drop can start to make things stop working. If we have only one or two sensors out there, we may just make sure we’re within tolerance, but if we have enough out there to fill an I/O module, or a brick of I/O, we’re going to recommend distributed I/O so that our reliability and predictability will increase.
Regarding communication speed, you need to make sure that your I/O update time is less than your fastest signal. There are several factors that we watch when determining which signals to take to the distributed I/O:
- What type of network are we using?
- How many devices are we communicating to?
- What are the run lengths of the communication cables?
- What speeds can our network switches and other network infrastructure support?
Newer ethernet networks with 5 or 6 communication modules attached to a switch and with home run lengths around 100 feet can usually handle 20ms I/O update speeds. If you add more wire length, and devices to the network, then 50ms is considered a best practice. If your system has signals that need to be faster than this, those would need to go to the local rack.
Determining what model of distributed I/O to use comes down to the types of signals we’re dealing with and what makes the most sense for the application. At Concept Systems we use Allen-Bradley Flex I/O remote racks, and Allen-Bradley Point I/O mounted in remote enclosures. We do this because the number and type of signals we’re dealing with are varied, and we like the flexibility of Allen-Bradley platforms. The Allen-Bradley ArmorBlock style of distributed I/O also works great in a conveyor type application where you have fewer points per group, and simple devices like limit switches, proximity switches, and solenoid valves. These kinds of devices typically require one cable to connect and don’t have complicated power and wiring needs. This is mentioned because the block style I/O doesn’t allow a lot of flexibility in separating power for the devices, so if you need something more complicated than just power for outputs, and power for inputs, an ArmorBlock setup may not be what works best for you.
There is a lot to consider when determining whether a distributed I/O system is right for your application. The factors listed above provide what we consider to be “best practices”, but there can be additional details when determining the final design.
The staff at Concept Systems is always ready to help – we are your Automation Solutions Partner.