6707ef156510957e6ed0bebc Shutterstock 402089755

9 questions to determine centralized vs. decentralized motion

Oct. 10, 2024
Should motion control remain in the cabinet or move onto the machine?

Admittedly, in our workflows, we tend to do what we always do unless there is a compelling reason to change. For me, motion control has always been a big main control panel (MCP) with a large section near the bottom dedicated to the bank of servo drives that make up my application. The drives share a common backplane that also acts as a means of heat dissipation, and the physical size of the drives and the heat they produce is a serious consideration. It also determines how big to make the panel and whether I need to include air conditioning to keep the cabinet cool.

Some discussion about the basics of this design approach is in order.

Get your subscription to Control Design’s daily newsletter.

Centralized motion control means the entire group of servo drives are located in the main control panel with power and encoder cables are routed out to each physical motor mounted on your machine. Additional connections might be necessary to provide a home or registration sensor, and all of this requires cable management, not only in the control cabinet, but out to the field, as well. Think of this as a star topology.

With decentralized motion architecture, the drives are located on the machine or process, close to the devices they operate. The obvious advantage here is the reduction in cable length and routing. Now this technique has been further enhanced over the years by the advance of technology. Formerly, servo groups would be moved out of the MCP into smaller control panels mounted directly to the machine. The main power feed would come from the MCP, as well as the appropriate industrial network connecting this satellite group back to the main processor in the MCP.

Now, this can be accomplished, doing away with the remote group altogether. Distributed drive technology combines servo drive and motor into a single package by way of special cabling; each drive/motor is connected to the next one in a daisy-chain configuration with power and network combined in a single media.

From a practical standpoint, if your machine has a lot of coordinated motion, then a centralized motion group would make the most sense. If your design is a lot of spread-out single axes, then decentralized would be better. With the improvement in network technologies, the grouping of axes in a decentralized topology is also a feasible option. Decentralized topology also lends itself to modularity. Machine builders can develop modules independently and then join them together as part of a bigger solution.

Consider wiring costs for a moment. If you have a process that is 60 ft long and each station/motor is 5 ft farther from the main control cabinet than the first one, individual encoder and power cable would add up to 5+10+15+20+25+30+35+40+45+50+55+60 = 390 ft of cable using a centralized topology. Using the decentralized topology, total cable length would be 60 ft using a central power supply and decentralized drive/motors.

If your design requires localized I/O, then even better because modules can be added at the site of the drive/motor without having to run separate power and network cables out to it.

Generally, a distributed motion system will comprise a power supply module—aka power interface module—that resides in the main control cabinet. From this module, a single unified cable connects to the first field-mounted/distributed servo drive and motor or servo drive only. The choice of the combined servo and motor or just the drive depends on the area in which the motor will be located.

Sometimes there is not enough physical space to mount a combination drive/motor so the drive can be mounted near the motor and then a single unified cable completes the connection from drive to motor. Depending on the hardware manufacture, a number of servo/motor or servo-only modules can then be connected to the first field module in a daisy-chain arrangement.

One vendor allows up to 24 nodes per power interface module. To include more than 24 motors, more power interface modules are added to the main control panel. It is important to note that the heat producers, the drive and motor, are no longer present in the control cabinet so the need to dissipate heat in the main panel is greatly reduced.

Another vendor has a power-supply module to which five distributed drives can be connected. They have a separate distributed power module that can be mounted in the field, and five distributed drives can be connected to that field-mounted device in a cascade topology. This particular product offering shares the dc bus, meaning that regenerated power can be shared across the other drives connected to the power module.

Networks vary, but EtherNet/IP with CIP Motion, Profinet, Profibus, CAN and TwinCAT are some popular methods, depending on the hardware vendor.

All of these developments happen because there is a need to make motion easier to design and deploy. Distributed motion allows the designer to consider motion where a pneumatic or small conventional motor might have previously been used. Motor frame sizes as small as 40 mm—a little over 1.5 inches—are possible. For precise movement, the choice of servo over a pneumatic device is obvious.

Most of the vendors mate their decentralized/distributed motion products with the centralized counterpart. This adds familiarity where programming/commissioning are concerned, and this can make a huge difference when deciding whether to expand to this newer technology.

So, armed with this information, do we use centralized or decentralized motion control in our designs? It would seem that the answer lies in the application.

  1. Is this a one-off project, meaning that we customize it to suit the job without the expectation of every making a second one?
  2. Is the footprint of the machine big or small? If the footprint is, say, 10 ft by 15 ft, do we gain any advantage by mounting the drives on the machine at the location of the motor? For a larger machine, is there clusters of control where two or more servos will be in the same general location?
  3. Is there space on the machine frame to mount the distributed servo drives?
  4. The routing of cables is always an important part of the design. Is there a cost savings and/or labor savings to machine-locating the drives, or do we eat up the materials savings by needing more time and people to prep the machine body to accept the field-mounted devices?
  5. Is it a worthwhile investment to put design time into a more modular approach, using a decentralized system, at the outset? This would come into play where the future design of the machine will expand to include more functions.
  6. Have you done a cost comparison to the actual physical hardware for a centralized system versus decentralized? Perhaps we save on machine cable but lose the advantage in the overall cost of the components to go to the decentralized method.
  7. Does the prospect of adding local I/O connectivity to the distributed drive/motor make this a more attractive direction to take?
  8. Is there a requirement for coordinated motion between the various axes? This would tend to point to a centralized solution.
  9. Could we incorporate a hybrid solution where part of it is centralized for the coordinated motion parts and the standalone axes could be part of a decentralized architecture? Again, this would be with an eye to keeping the heat signature in the panel to a minimum.

I hope that the questions above can provide some avenues of thought for those who might consider the transition from centralized to decentralized motion control architecture.

Now approaching four decades in the automation business, for me, subjects like this really bring focus to where the journey takes us in our careers. I remember my first exposure to motion control and the electrical cabinets I worked with were big enough to step inside. Most times, the huge enclosures were to dissipate the heat generated by the components inside and not necessarily due to the number of components needed to control the process.

Many environments do not allow for panel cooling that involves direct exchange of air from outside the enclosure, so our only choice was to make the surface area of the cabinet big enough to count on the movement of air outside the enclosure to draw heat off the outside surface.

Awareness of the presence of a newer technology does not always translate into using that newer technology. Over the course of a career, we tend to develop good solutions that we fine-tune from project to project. We become comfortable with grabbing what become canned solutions to different parts of our new project, and this can lead to inadvertently sliding behind the times.

About the Author

Rick Rice | Contributing Editor

Rick Rice is a controls engineer at Crest Foods, a dry-foods manufacturing and packaging company in Ashton, Illinois. With more than 30 years’ experience in the field of automation, Rice has designed and programmed everything from automotive assembly, robots, palletizing and depalletizing equipment, conveyors and forming machines for the plastics industry but most of his career has focused on OEM in the packaging machinery industry with a focus on R&D for custom applications. 

Sponsored Recommendations

Simulation for Automation Guide

How digital twin solutions are expanding the capabilities of plant engineers.

Enhancing HMI Security and Accessibility with Cloud VPN Solutions

Enhance HMI security and remote access with Beijer’s cloud VPN solution. Enjoy advanced encryption, easy setup, and secure access via laptops, smartphones, or tablets. Cut costs...

Motor Encoders: What They Are and How They Work

Motor encoders are rotary encoders adapted to provide information about an electric motor shaft's speed and/or position. Like rotary encoders, motor encoders are most commonly...

C-Face Solutions for Motor Feedback

EPC's C-face encoders use an internal flex mount that accommodates shaft run-out while maintaining alignment.