I get a little crabby about some of the things I have seen over the years in the motion control and especially the American marketing mentality. In particular, the words “motion control” and “easy to use” should not appear in the same sentence without great care and thought about the statements being made. If there is any lesson in the last two blogs on simulations and analytical tools for system design, it is that the motion control field is complex.
It is certain that computers and ever more powerful software programs automate tasks so that we can work more quickly. The tools are evolving to make design faster and more thorough. Many programs embed software oscilloscopes to display important parameters of operation while we tune or test our work. And I love anything that makes my job easier, as I’m sure you do.
And it is certainly true that the majority of motion control and mechatronic applications can be subdivided into relatively simple systems. Most people with experience in motion control will tell you that 80% or more of all the motors sold perform simple tasks that can be handled with simple hardware and relatively simple control.
A fairly precise linear actuator can be created by combining a stepping motor and a lead screw with a fair amount of thrust to it. The motor, bearing, lead screw, control, can be purchased as a system for around $100 in low volume production quantities.
But there is a great tendency to depend on the performance of the tools and come to the conclusion that there are no issues when we specify a group of components for an application. Its easy to get lulled into a false sense of security that we know everything we need to know about a project. FORGET ABOUT IT! It is never going to be that way. Sooner or later, your boss or some customer will throw you a curve that you think is a piece of cake and about the time that your halfway into the project you are going to realize that you are in trouble.
You have to ask lots of questions. You have to examine assumptions. You have to explore lots of alternatives. When you start a project, put an outline together of the major issues. Use it as a fence to create boundaries AND connections so that you work through everything with a structure. Structured software, and project scripts, make debugging (which is where we spend most of our time) a whole lot easier. Approach to the big picture by assembling small tasks together that will result in achieving the final objectives. And measure everything against the project objectives.
If you want an assumption, here’s one: nothing is as easy as you think it is.