For automation applications, one of the larger misconceptions in the industry today is that when someone uses the phrase “motion control,” they can just as easily use the term “robotics,” as if the two are interchangeable. When most people think of robotics, they think only of robots, and because motion is being controlled by the robot, they assume motion control means the same thing. It does not.
Although the end result when it comes to motion control and robotics applications may be similar, the way those results are achieved are very different.
When someone refers to robotics, generally that person is talking about a fully realized, off-the-shelf system. The components inside of a robotics application have been pre-engineered. The end user will need to have minimal knowledge of the working components as a robotics application consists of simply a robot and its controller.
Motion control, however, can be characterized in most cases as a subsystem of robotics. The components that make up a motion control application are more modular than simply a robot and a controller, meaning there must be more knowledge on the end user side of the equation. A motion control application will generally consist of a motion controller, a human machine interface (HMI), the drive, the motor, and the mechanics. The end user finds having a technical background helpful to effectively put everything together and program a motion control application in order to achieve the desired results. From a product design standpoint in automation, it is important to understand the difference between these two applications and which will satisfy the particular end user the product is being designed for.
Time vs Money
This is another exercise in the thought process of knowing your audience. Who exactly is the end user for the automation application product that is being designed? Or at least the user(s) putting the system together? This is a critical piece of the puzzle that the product manager in charge of managing the product development process must understand before the project is under way. How knowledgeable is the user for a specific application in the field of motion control? If there are knowledge and experience limitations for the user, it might be best to design a robotics application that features a turnkey solution for the customer. If there is a qualified engineer on the other end, it becomes more of a possibility to deliver a more cost-effective motion control solution. This is assuming time and money are not a major factor in the decision-making process. But what if they are?
A user may be qualified to optimize a motion control application to do the work they require but have time limitations. When delivering motion control products to a customer, there is still a little programming and engineering required in order for everything to function properly. This process can take a significant amount of time and manpower. A significant amount of time could be dedicated to programing, setup, and ultimately troubleshooting when elements are not operating properly. If the customer is in a situation where time is not a concern but cost is, a motion control solution will likely be the preferred solution.
On the other hand, if a customer either does not have the engineering knowledge and experience on staff, or does not have the time to dedicate to properly programming and installing the motion control components, a robotics solution could be the answer. Perhaps a customer is in a time crunch and needs to get the operation up and running quickly. In this case, the customer would be best suited for a robotics application. Robotics solutions tend to be more costly than a motion control product because all of the pre-engineering has already been done in order to make it a turnkey solution for the customer. The motor, the drive, the mechanics, and the HMI all must be optimized and engineered for the motion control solution to have its desired outcome. It takes more time for the operation to be up and running. This is not the case with an off-the-shelf robotics solution. But even the robotics solutions need to be programmed and properly implemented. So again, where does the customer want to spend their resources? Is it in their money or in their time?
Hardware vs Software – Functionality and Ease of Use
After a motion control or robotics solution is decided upon, the customer is then going to decide on a product, more specifically a controller. What are they looking for? What is a key differentiator for a customer to choose one controller over another? The answer tends to lie more often in the software than in the hardware.
This was not always the case. More than a decade ago, hardware drove purchasing decisions by those tasked to do so. We have reached a point in the technology in which the hardware does not matter as much as it used to. We are now only seeing very small variations from one motion controller to the next in terms of capability when comparing apples to apples. So what drives a customer to choose one controller over the next now? Two main factors – ease of use and functionality.
Functionality is a key differentiator for controller software in the market today. A customer wants the controller to be able to perform all of the tasks they need in order to make their job easier. The more that can be controlled, the easier life becomes for the operator. From an economic standpoint, functionality means less money spent on additional components and less time spent on monitoring operations in an inconvenient manner. Additionally, not only does an operator want to be able to control more with their controller today, but they want to be able to do it with relative ease.
The second biggest driver in choosing one controller over the next is that controller’s ease of use. When a customer watches a demo of a controller, and they easily understand everything about the interface and how it operates, they are much more likely to choose it. By using an easy-to-use controller, less time and money is spent on figuring it out. Convenience will always lead to less time spent on troubleshooting and less frustration.
Designing products for automation applications is all about knowing the customer and the market needs. Determining a customer’s pain points — between time, money, functionality and ease of use — will allow a product designer to know where to put his or her efforts in developing the optimal solution.
>> Read more by Corey Foster, Product Design & Development, May 1, 2017