Here’s a closer look at software development for programming motion systems and how these choices affect software reusability.

By Chuck Lewin Performance Motion Devices

Software development can be the single greatest engineering cost for many machine design projects. This observation is especially true for motion control projects because of the inherent complexity of managing such real time tasks as profile generation, events, and throughput.

Do you protocol?

It’s easy to be a bit overwhelmed with the range of choices in motion control protocols, languages, interface standards, and control architectures. However, as it turns out, a few basic concepts provide the necessary foundation for understanding motion programming languages.

A motion protocol is a set of commands, typically 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”, and so on.

The most common openly defined motion protocols in use today are SERCOS (IEC 61491), and CANOpen. 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 high speed Ethernet.

Either way, motion protocols do not have the high level branching, looping, and logic instructions associated with fully programmable languages. Thus, to be functional, motion protocols require a host computer to manage overall sequence and logic control.

A motion instruction set is a general term for a set of dedicated motion functions that are usually accessed through a callable software library. Like a motion protocol, however, a host computer is needed to correctly sequence motion instructions to achieve the desired machine behavior. In this sense, motion instruction sets are similar to motion protocols.

Dedicated integrated circuit (IC) chips often contain the purest and most common form of motion instruction sets. These hardware devices provide profile generation, servo loop closure, and other motion functions. They come with callable libraries that allow the host software to send commands to and from the motion IC, thereby offloading the host from these complex and time-sensitive functions.

Adding to the confusion, though, some motion ICs contain 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 standard, multi-vendor interface formats.

Do you speak my language?

Motion protocols and motion instruction sets set up the lexicon to execute motion-specific functions. They don’t, however, provide a language in the sense of allowing decision making and overall machine sequence control.

Today, machine-tool manufacturers use one of three approaches to motion languages. 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 approach is open language standards such as IEC 61131-3.

As anyone who has worked in motion control knows, it takes a bit of specialized knowledge to build a state-of-the-art machine controller. Timing can be critical with complicated motion profiles and servo control techniques. It is the need to manage this complexity that has impelled engineers to develop special fully programmable motion languages.

A special language packaged with motion capabilities can absolve you of managing the details of what happens behind the scenes to make the motors move when and where commanded. In addition to motion-specific commands, these languages include features 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. Software developed for one motion language cannot be easily used in another vendor’s system. This state also 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 of their origination. Therefore, some vendor-specific languages may seem rather out of date today.

On the positive side, however, such vendor-specific languages can be advantageous for relatively simple applications or where a general-purpose language might be more complex 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 that it is specific to a vendor 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 languages are BASIC and C/C++, however in principle any language can be used.

Such an arrangement works because 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. The motion-specific capabilities are packaged as callable routines, with standard programming languages providing the more familiar branching and looping instructions to determine overall machine behavior.

Third time is the charm?

A third programming option for motion-based machines is IEC 61131-3, an open standard that has the interesting characteristic of multiple languages (four altogether, two graphical and two textual) for programming.

Also called 1131 for short, this language was primarily intended to support programmable logic controller applications, but has gained traction for use in motion control applications, perhaps because of the notable lack of a standard, open motion language.

For all of its benefits, 1131 is not widely known to software engineers and consequently not particularly popular in North America, although it is fairly well known in Europe. It remains to be seen to what extent 1131 will affect the greater motion control world.

On top of 1131, there is one other standard motion ‘language’ worth mentioning, namely G code. G-Code is an EIA standard RS274 (technically there are two sets of related codes, G-codes and M-codes), language of dedicated instructions for CNC machines. However, G-codes are not directly comparable to 61131-3, or for that matter any programmable language, because they do not provide language facilities for general-purpose applications.

If other industries are any guide, the motion control world will move, albeit a bit slowly, toward open, standard protocol and product approaches. For a given application however, you will need to weigh the pros and cons of specific languages.

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

New motion modules
OEMs that designed cost sensitive machines typically steered clear of ‘box’ solutions such as PLCs and standalone drives. Big and bulky, these products often required that you learn special motion languages and they tended to be expensive.

The latest generation of motion modules is different. They measure just inches on a side and connect by high-speed network to the central controller, usually a PC, which holds the user’s software control program. They use the same motion instruction in module format as is available in IC or standard card formats. This allows code developed for one hardware format to be reused in another.

The ION digital drive from PMD is an example. Measuring just 4 in. by 3 in. by 1.5 in., it offers serial or CANBus connectivity and can control dc brush, brushless dc, or step motors. It has the same motion instruction set found in IC and card products, and provides Field Oriented Control, S-curve profiling, PID position loop with bi-quad filtering, and MOSFET drivers. At $200 per axis in OEM quantities, they are often a big cost improvement compared to motion cards or PLCs.

www.pmdcorp.com