Breaking Protocol

Last year, Myostat Motion was approached by a North American manufacturer of screen printing equipment and challenged with providing an integrated servo motor solution that would integrate into their existing equipment framework. For this installation—an 8-axis machine with a master network controller—the customer specifically requested Modbus, which had been heavily evangelized by one of their main controller suppliers.

Generally, Modbus is a versatile and inexpensive communication protocol. It’s especially useful when trying to tie two or three devices, like PLCs and panel interfaces, together with motor controllers or VFDs (variable frequency drives). It’s also used extensively in industrial environments as it is openly published, mature and a readily available interface on a variety of common automation components.

In this case, we used an integrated servo motor with two Modbus slave ports. The client wanted to be able to have a main operator interface controlling all motors with each axis having a secondary operator interface. This required the integrated servo to not only take Modbus commands on two different serial channels but also pass Modbus commands along a network from the main interface to all secondary interfaces and vice versa.

The master network controller can control all the settings, change the speed, start and stop the press as well as read their position and status. Each station then has a small master HMI that can be used to change the individual axis speed.

The advantage is that the operator can stand at a station and adjust the speed while monitoring the action. The operator doesn’t have to return to the main network controller to set the speed, allowing the main network controller to act as a master to the motor slave nodes. This solution eliminates excess wiring, and means that the primary master controller has only one device per axis to control, which simplifies programming.

As is often the case, the customer changed operator interface manufacturers many times as the design progressed. Each interface manufacturer implemented the modbus protocol in a slightly different way and the integrated servo, which was acting as the slave motion controller, needed to be changed and adapted as a result.

Our first challenge presented itself at system initialization. By monitoring the serial line and watching for unexpected data requests, we realized that one of the systems required a specific memory address to be checked at power up as a verification routine. This registry check didn’t seem to be part of the Modbus specification and, once discovered, was easily handled by preloading the requested register with the appropriate data.

Dealing with variations in individual systems timing constraints can also be challenging. We quickly discovered that some hardware’s message timing requirements were far more rigid than others. This constrained hardware required exact timing between messages while the more flexible hardware allowed for greater delays.

When attempting to integrate hardware from other manufacturers, it’s important to look at the implementation for each device. Initially, we assumed that the less expensive hardware would be more difficult to work with but this didn’t turn out to be true in all cases. It may be that stricter timing requirements are necessary for equipment which is typically used in higher performance environments. Or it may be due to the fact that the equipment has been designed to work specifically with other pieces from the same manufacturer.

Endianess is another issue which, while not unexpected, is still worth mentioning when looking at Modbus components. Each manufacturer defines the data structure as either big or little endian. When connecting different pieces of hardware, it’s important that all the settings are consistent. Not all manufacturers allow you to set this so you may have to configure all equipment to meet the pre-set standard and swap out any components which conflict and can’t be changed.

Modbus is an established protocol; however, it’s important to understand that each implementation is unique. Keeping these issues in mind, and researching other possible challenges when sourcing from different manufactures, will help reduce machine design time and costs and minimize frustration when troubleshooting communication errors.

Mark McCann is the Lead Design Engineer at automation solutions provider, Myostat Motion Control. During his eight years with the company, Mark has worked on hardware, electronic circuit design, software, microcontroller firmware development and windows application programming.