Breaking Protocol

While Modbus is a versatile protocol, integrating different manufacturers’ components across machines inevitably presents challenges.

Design Engineering Motion Control
Share or bookmark this post:
  • LinkedIn
  • Digg
  • Facebook
  • Google Bookmarks
  • Reddit
  • Twitter
  • StumbleUpon

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 Challenger III, the newest automatic carousel textile press from M&R, presented instructive design challenges for Myostat Motion's design team.

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.