Resources / Articles / Motion Software - Part II

Motion Software - Part II

~ Chuck Lewin

Part II of a two-part deep dive into the world of motion software - both the kind that lets you tune your system, and the kind used to write your machine's application code.

When we talk about motion control software we are talking about two more or less separate types of software. The first is an exerciser program, also called a setup program, that lets you tune your system, exercise your hardware, and optimize performance. That was the subject of last month's deep dive.

The second is the language or system by which you will specify the overall behavior of your machine. Rather than an executable program, this is generally a language that you compile and download, or just download to the motion controller. But there are a large variety of approaches and we will look at the most important ones in this month's deep dive we will explore that specific subject, the programming language or system. So grab yourself a flow charting tool, sit back, and relax as we take this deep dive into motion control software.

Give Me A Language, Any Language

With the first half of our deep dive on setup/exerciser software completed, it's now time to stop optimizing the motion and start coding the application!

Considering today's landscape of motion control protocols, languages, interface standards, and control architectures, the average engineer can be forgiven for being a bit overwhelmed by the choices. As it turns out though, a few basic concepts provide the necessary foundation for understanding motion programming languages. Let’s begin with a discussion of a few important terms, specifically, motion protocols, versus motion languages versus motion instructions sets.

A motion protocol is a set of commands, generally hosted on a network such as CANBus or Ethernet that triggers motion functions in a drive or other remote unit attached to the network. Some motion protocols offer relatively high-level motion commands such as, "execute a point-to-point trapezoidal profile to location xxx," while some are rather low-level, with each node receiving rapid-fire commands such as "now drive the motor at torque x1, now drive it at torque x2", etc...

The most common openly defined motion protocols in use today are SERCOS (IEC 61491), and CANOpen (IEC 61800-7-201). SERCOS is most often used in the CNC-machine tool world, while CANOpen, originally designed as an application-specific layer on top of standard CANBus communications, has been upgraded to allow use on other buses such as EtherCAT.

Either way, significantly for our discussion of motion languages, motion protocols do not have the high level branching, looping, and logic instructions associated with full programmable languages. So to be functional, motion protocols require a computer that provides overall sequence and logic control.

In this sense, motion instruction sets are similar to motion protocols. A motion instruction set is a general term for a set of dedicated motion functions, usually accessed via a callable software library. Like a motion protocol, however, a host computer must be used to correctly sequence motion instructions to provide the desired overall machine behavior.

The purest and most common form of motion instruction sets are provided by dedicated motion ICs. These hardware devices provide profile generation, servo loop closure, and many other motion functions. They come with callable libraries that allow the host software to send commands to/from the motion IC, thereby offloading the host from these complex and time-sensitive functions.

Adding to the confusion, some motion ICs provide serial or CANBus communications, and so the motion instructions that are sent on the serial wire could just as easily be referred to as a motion protocol. In common practice however, the term motion protocol usually refers to standardized, multi-vendor interface formats.

What We Have Here Is A Failure To Communicate

As we have now seen, motion protocols and motion instruction sets provide the lexicon with which motion-specific functions can be executed. They don't, however, provide a language in the sense of allowing decision making and overall machine sequence control.

For this we turn to our discussion of motion languages and introduce three approaches currently in use today. The first is vendor-specific motion languages. The second is standard programming language such as C/C++ or Basic in combination with callable motion instruction set libraries. The third solution is open language standards such as IEC 61131-3. Each of these approaches is discussed in the sections ahead.

As anyone who has worked in motion control knows, quite a bit of specialized knowledge is required to build a state-of-the-art machine controller. Timing can be critical, motion profiles and servo control techniques are complicated. Managing this complexity has been the impetus for the development of specialized fully programmable motion languages.

By packaging motion capabilities into a special language, the user is absolved of the details of what happens behind the scenes to make the motors move when and where they are commanded. Most importantly for our discussion, in addition to motion-specific commands, these languages provide language facilities for testing parameters, making decisions, and executing different code sequences under different circumstances.

Unfortunately, there is at present no open standard for a motion language. Thus all motion languages available today are vendor-specific. This means that software developed for one motion language cannot be easily utilized in another vendor's system. This also usually means that there is little incentive to upgrade the motion language to reflect improvements in language technology. Vendor-specific languages tend to remain in the language paradigm popular when they were created.

Because of this, some vendor-specific languages may seem rather out of date today. On the positive side, this can be an advantage for relatively simple applications, where a general purpose language might be more complexity than needed to accomplish basic motion.

Separation of Church and Sequencing

On top of these pros and cons however, the most obvious drawback to a vendor-specific computer language is suggested by the name, which is to say that the language is vendor-specific and therefore not interchangeable, and not taught in engineering schools.

To address this problem, many motion providers dispense with a full-blown programmable motion language, and instead provide callable motion libraries for various standard computer languages. The most common supported language is C/C++, followed somewhat distantly by BASIC, however in principle any language can be used.

This works thanks to the fact that there are really two separate functions provided by a programmable motion language. The first is access to motion-specific capabilities such as profile generation, or PID (proportional, integral, derivative) setting, and the second is overall sequence control. In this paradigm, motion-specific capabilities are packaged as callable routines, and standard programming languages are used to provide the more familiar branching and looping instructions to determine overall machine behavior.

So using standard programming languages such as C/C++, the vendor simply provides compilable source code for their library functions or some form of DLL (Dynamic Link Library) that allows the motion calls to be accessed from the standard language.

Many vendors, including PMD, provide both. Source code is particularly useful when the execution engine is a microprocessor or other low level device. If the execution engine is a Windows/PC environment, then DLLs are preferred.

Third Time's The Charm?

A third programming option for motion-based machines are 'engines' that process graphical or text constructs or commands and then send them to specific motion hardware.

The two major examples of such 'language engines' are IEC 61131-3, an open standard that has the interesting characteristic that it provides multiple language paradigms (four altogether, two graphical and two textual) for programming, and LabView, a proprietary (but widely used) graphical language system hosted on the Windows/PC world.

Of these two, 61131-3 is much more of a complete open language. Also called 1131 for short, this language was primarily intended to support PLC (programmable logic controller) applications, but has gained traction for use in motion control applications, perhaps because of the notable lack of any other available standard, open, motion language.

For all of its benefits, 61131-3 is not widely used in North America, although it is fairly well known in Europe. It remains to be seen to what extent 1131 will impact the greater motion control world.

Labview began its life in the instrumentation/data acquisition world, and has expanded its domain to include general purpose machine control. Nevertheless, it is rare to see a standalone machine controller programmed via Labview. This method is still largely used for laboratory prototyping rather than production units.


To get your system up and running make sure you work with a motion vendor that provides state-of-the -art setup/exerciser system. This system should provide Axis Wizard type setup, auto-tuning, and high-performance motion analysis tools.

Once you are ready to build the machine application, you will need to settle on a programming system. There are some vendor-specific languages available, but if other industries are any guide the motion control world will move toward open, standard protocol and product approaches. For a given application however, you will need to weigh the pros and cons of specific solutions.

Be sure to consider the life-cycle costs of choosing a vendor-specific language versus a more open approach. Most hardware motion systems provide similar performance features, so be sure to choose the software architecture that represents the best balance of convenience, flexibility, and migration freedom for your application.

I hope you have enjoyed this part II deep dive installment, as well as part I on the subject of motion control software. Till next time, happy servoing!

Article written by:
Chuck Lewin
Founder & CEO
Performance Motion Devices, Inc.