Design of a Seamless Gateway for Mechatrolink

Jin Ho Kim, Dang Thanh Tuan, Jae Wook Jeon

Sungkyunkwan University
The School of Information and communication Engineering
Suwon, Korea
{besteng83, dangthanhtuanit}@gmail.com, jwjeon@yurim.skku.ac.kr

Bok Sun Yeom
Fastech Corporation
Automation Research Center
Bucheon, Korea
bsyeom@fastech.co.kr

AbstractRecently, the Real-time Ethernet based protocol has
alternated a low speed fieldbus using RS-485 or CAN. To connect
a low speed fieldbus and a real-time Ethernet, a gateway is an
essential component. In this paper, we propose the seamless
gateway for Mechatrolink . The seamless gateway abstracts the
network protocol (e.g. EtherCAT, PROFINET) and profile (e.g.
CiA 402, PROFIdrive). Using the proposed gateway, the master
can control all device using a single network protocol and profile.
In this paper we explain the concept of a seamless gateway and
implement a prototype seamless gateway between Mechatrolink
and RS-485.
KeywordsGateway; Mechatrolink; Real-Time Ethernet;
Fieldbus; RS-485
I. INTRODUCTION
The Real-Time Ethernet (RTE) has several merits for
factory automation communication protocol as a high
bandwidth, low cost and reliability [1]. Therefore, major
automation component manufacturing companies, such as
SIEMENS and ROCKWELL have developed RTE protocols
and RTE based components. For example, SIEMENS
developed the PROFINET [2] and ROCKWELL developed
Ethernet/IP [3].
Despite of effort to standardize a single fieldbus, several
fieldbuses were standardized [1]. As a result, several RTEs
such as EtherCAT, Ethernet/IP, PROFINET are included in the
IEC 61158 standard. Moreover, several low speed fieldbus,
such as ControlNet and PROFIBUS, that use RS-485 and CAN
are included in the IEC 61158 standard.
Although RTE has several merits, a low speed fieldbus
based legacy system can be used because it has already been
verified and can decrease total cost. Therefore, both RTE and a
low speed fieldbus may be used in a single system. It is also
possible to use different type of RTE in a single system. In
order to connect sub-systems that use different protocols such
as above mentioned systems, the gateway needs to be used.
There are several previous studies [4-8] about industrial
gateways. J. Jasperneite and J. Feld proposed gateway concepts
for PROFINET IO in [4] explaining the multi-device approach
for the gateway between PROFINET IO and PROFIBUS and
the slot/sub-slot approach for gateway between PROFINET IO
and INTERBUS. R. T. Qu and R. LIM proposed an
architecture for interconnecting heterogeneous fieldbuses in [5].
L. Gang-yan and X. Jun proposed a gateway between
PROFINEET and PROFIBUS in [6]. S. S. Yoon et al. propose
a gateway between EtherCAT and RS-485 [7]. Anybus [8] and
NetTap [9] are two of the most famous COTS (Commercial
Off-The-Shelf) gateways for industrial networks.
Previous studies [4-9] explained the method or architecture
for connecting different protocols. However, they did not
consider mapping of different motion profiles (e.g. CiA 402,
PROFIdrive). In this paper, we propose the seamless gateway
for Mechatrolink . The seamless gateway abstracts the
network protocol (e.g. EtherCAT, PROFINEET) and profile
(e.g. CiA 402, PROFIdrive). Therefore, the master can control
all devices, including devices that use different protocols and
profile, without considering difference of protocol and profile.
In this paper, we explain the concept of a seamless gateway. In
order to verify our concept, we implement a prototype seamless
gateway to connect the Mechatrolink and RS-485 based
closed-loop stepping motor drive system [10].
The remainder of the paper is organized as follows. Section
explains background technologies. Section explains the
concept of the proposed gateway. Section describes the
implementation of a prototype gateway. Section describes
the analysis and measurement results. Section concludes the
paper.
II. BACKGROUND
This section describes the Mechatrolink and Ezi-Servo
Plus-R[10].
A. Mechatrolink
Mechatrolink is an RTE protocol for motion control,
which was developed by Yaskawa. The Japanese National
Committee presented a proposal to approve Mechatrolink
978-1-4673-4569-9/13/$31.00 2013 IEEE 1246

Figure 1 Mechatrolink communication

Figure 2 RS-485 based communication protocol for Ezi-Servo Plus-R
specifications for an IEC standard and this NP (New Proposal)
passed the vote of the international standardization community
[11]. Mechatrolink will be officially approved in the final
publication stage in 2013 [11].
Table shows the important features of Mechatrolink .
The transmission cycle time is determined by the message
length and number of connected nodes. The message length
can be configured to differently for each node. Mechatrolink
supports the multi-slave function; this means that some nodes
can be configured to have several communication addresses.
For example, when a node uses the multi-slave function, the
node has several node addresses and it can communicate using
all addresses.
TABLE I MECHATROLINK SPECIFICATION
Feature Specification
Physical layer Ethernet
Baud Rate 100Mbps
Transmission Cycle time 31.25us ~ 64ms
Length of message 8/16/32/64 bytes
Number of Slaves 62 max.
Topology Cascade, Star, Point-to-Point
Supported Com. Cyclic and event-driven Com.
Multi slave supported

Mechatrolink uses a message-related method [12].
Therefore, the Mechatrolink master node sends a request
message to a specific slave and the node that receives the
requested message sends a response message. Figure 1 is the
communication method of Mechatrolink [13].
Mechatrolink supports both the motion profile [14] and
IO profile [15]. These profiles define the standard operational
method and standard interface method. Therefore, devices
developed by several vendors can be controlled in the same
manner using these standard profiles.
B. Ezi-Servo Plus-R
Ezi-Servo Plus-R (abbreviate Ezi-Servo Plus-R to Ezi-
Servo for convenience in below) is an RS-485 based stepping
motor drive which was developed by Fastech. Fastech designed
the own RS-485 based protocol for Ezi-Servo. Figure 2 shows
the RS-485 based protocol, which is used to control Ezi-Servo.
This communication protocol consists of sending and response
frames. The master sends a sending frame to control the Ezi-
Servo. When the Ezi-Servo receives a sending frame from the
master, it processes the received request and then it sends a
response frame to the master to inform the result of the
processing. The sending and response frames consist of a
header, frame data and tail. Frame data consists of a slave ID,
frame type, data field and CRC(Cyclic Redundancy Check).
Slave ID is the ID number of Ezi-Servo, which is the
destination node of this frame. Frame type is the command
type(e.g. servo on, move to absolute position and etc). Data
field has variable length and it is determined by the frame type.
The CRC field stores a 16 bit CRC code, which is used to
check for communication errors. Table shows the actual
sending and response frames for the servo-on command for
Ezi-Servo. The detailed specification about the RS-485 based
protocol for Ezi-Servo is described in [10].
TABLE II RS-485 FRAMES FOR SERVO-ON COMMAND FOR EZI-SERVO

RS-485 frame data
Header
Slave
ID
Frame
Type
Data CRC Tail
Sending
Frame
AACC 01 2A 01 FEA0 AAEE
Response
Frame
AACC 01 2A 00 3F60 AAEE
III. CONCEPT OF THE SEAMLESS GATEWAY
In this section, we explain the previous gateway
technologies as background information and then explain
seamless gateway technology.
A. Previous Gateways
Previous gateways are implemented by I/O (Input/output)
profile (e.g. CiA 401[17] or Mechatrolink 3 standard I/O
profile command[15])or manufacturer specific message
protocol. The I/O profile based gateway has input and output
channels. The master can send a command to the gateway
using the output channel and receive the response message
from the gateway using the input channel. The I/O based
gateway uses a standard I/O profile but there is no standard
method to define the input and output channels for the gateway.
Therefore, I/O based gateways are different for every
manufacturer. Similarly, manufacturer specific message based
gateways are also different for every manufacturer. Therefore,
1247

Figure 5 Master aspect topology using proposed gateway

Figure 4 System architecture using seamless gateway


Figure 3 System architecture using previous gateway

Figure 7 Prototype gateway embedded system
in order to use these gateways, the master needs special control
algorithms to control the fieldbus based motor drives that are
connected to the gateways, considering the manufacturer
specific I/O or message protocol. Figure 3 shows the system
architecture of a previous gateway. The previous gateway uses
the fieldbus based motor drives but it has difficulty using the
legacy control algorithm, which is supported by a commercial
master program or legacy systems.
B. Proposed Seamless Gateway
As described above, previous gateways need a special
control algorithm which must consider manufacturer specific
I/O profiles or message protocols. In these gateway
technologies, the master cannot reuse the control algorithms,
which are supported by a commercial master program or
legacy systems. Therefore, this paper proposes the seamless
gateway that abstracts the network protocol and profile. Figure
4 shows the system architecture using the proposed seamless
gateway. The master using the seamless gateway can control
the fieldbus based motor drive using a standard motion profile.
Therefore, it can use the legacy control algorithm, which
supported by a commercial master program or legacy systems.
Figure 5 shows the master aspect network topology with
the proposed seamless gateway. The Mechatrolink master
can control all nodes, including the fieldbus based motor drive,
by using the Mechatrolink motion profile because the
proposed gateway abstracts both communication protocol and
motion profile. Therefore, the proposed gateway makes it
easier for the master to control all motor drives with the use of
a standard motion profile.
Figure 6 shows the block diagram of the proposed gateway.
The proposed gateway has a Mechatrolink communication
interface and a fieldbus interface. The host controller of the
proposed gateway includes the communication gateway
module, the profile conversion module and the device
monitoring module. The communication gateway module
carried our conversion between Mechatrolink and the
fieldbus, and it supports network independent data to the upper
layer (profile conversion module in this paper). The profile
conversion module converts the Mechatrolink standard
profile command to the manufacturer specific control
command for the fieldbus based motor drive. The profile
conversion module uses the communication gateway module to
communicate with Mechatrolink and the fieldbus. The
device monitoring module monitors the status of the fieldbus
based devices. It monitors the information that is required by
the master, such as the status flag and current position. The
device monitoring module uses the command conversion
module to make a message for the fieldbus based device and
the Mechatrolink master. The configuration module has the
user configuration of the manufacturer specific command. The
manufacturer specific command is determined by the
manufacturer of the fieldbus based motor drive. Therefore, the
configuration module can be configured by the user using a
GUI(Graphic User Interface) program. The profile conversion
1248

Figure 6 Block diagram of the seamless gateway

Figure 8 Flow chart of proposed gateway
module reads the configuration module to determine the
corresponding manufacturer specific command for each
Mechatrolink profile command and vice versa.
IV. IMPLEMENTATION OF PROTOTYPE
In this section, we describe the implementation of the
proposed gateway. The proposed gateway can be used as a
gateways between many types of RTE and a fieldbus based
motor drive, but in this paper, we implement the gateway
between Mechatrolink and Ezi-Servo, an RS-485 based
motor drive. We divide the section into hardware
implementation and software implementation subsections for
convenience in explanation.
A. Hardware Implementation
We implement an embedded system that supports
Mechatrolink and RS-485 communication to implement the
proposed gateway. The proposed gateway connects the
Mechatrolink and RS-485, and converts the Mechatrolink
standard profile to a manufacturer specific command.
We use the JL-102 for the Mechatrolink communication
controller and the TMS320F2812[18] for the host controller,
which is a DSP(Digital signal processor) developed by
TI(Texas Instrument). JL-102 and TMS320F2812 are
connected using data and address buses.
Mechatrolink uses a dedicated chip(JL-102) for the
communication controller but it uses a standard Ethernet
transceiver. The signal between the physical layer chip and
media is isolated using a pulse transformer. Although
Mechatrolink uses an Ethernet transceiver for the physical
layer, it does not use a standard RJ-45 connector but an
industrial MINI I/O connector [16]. Figure 7 shows a picture of
the gateway embedded system.
B. Software Implementation
The proposed gateway consists of communication gateway,
profile conversion, configuration and device monitoring
modules.
The commutation gateway module carries out conversion
between Mechatrolink and RS-485 and it supports network
independent data to the profile conversion module. The profile
conversion module is called when Mechatrolink or RS-485
receives a new message. The profile conversion module
retrieves the command from the received message and finds the
corresponding vendor specific command or standard motion
profile by searching the configuration module. The gateway
sends the RS-485 or Mechatrolink message after
determining the corresponding command. When the gateway
receives a Mechatrolink message, it must immediately send
a response message to the master to prevent a communication
error in the Mechatrolink network. For example, when the
Mechatrolink master sends a control command to the RS-
485 based motor drive, the gateway which received this
command must send a response message to the master
immediately to inform the result of the communication.
However, the gateway that received message is not the real
destination of the command. The real response message from
an RS-485 based device is received after several
communication cycles because RS-485 is slower than
Mechatrolink . Therefore, the proposed gateway must send
the response message to the master immediately when it
receives the request message from the controller. The
immediate response message notifies the master that the
gateway has received the request from the master correctly. In
order to prevent a new request before completing the previous
request, the gateway sends a response message with a false
value of the CMD READY flag until it receives a response
message from the fieldbus based motor drive. The master does
not send a new request to the gateway until it receives a
response message with true value of the CMD READY flag.
Each manufacturer of a motor drive can define a
manufacturer specific command to control the motor drive.
However, the control methods of a motor drive are similar.
Therefore, the proposed gateway uses the configuration module
to determine the command corresponding to each Mechatrolink
standard profile command. In this paper, we use a
predefined table for the configuration module.
The device monitoring module monitors the Ezi-Servo. The
controller needs real-time information such as actual position,
speed and status of the motor drive for precise motion control.
The frequency of the device monitoring module is important
for precise motion control because it determine the information
update period of the Ezi-Servo. Therefore, the proposed
gateway uses polling to monitor the Ezi-Servo (running an
endless loop in the main function). Figure 8 shows the flow
chart of the proposed gateway.
1249

Figure 9 Experiment environment
C. Experiment for verification
Figure 9 shows the experiment environment that was set up
to verify the proposed seamless gateway. The Mechatrolink
master program, proposed gateway and Mechatrolink based
motor drive are connected using Mechatrolink . The
proposed gateway connects to Ezi-Servo, which is an RS-485
based motor drive.
The master program runs on a PC using NT112A. NT112A
is the Mechatrolink master interface card that uses a PCI
interface. The master program, which was developed by
Yaskawa, supports servo on, servo off, monitoring alarm, reset
alarm and posing commands using the Mechatrolink
standard motion profile.
Using the proposed gateway, the master program can
control both a Mechatrolink based motor drive and an RS-
485 based motor drive using the Mechatrolink standard
motion profile without considering manufacturer specific
gateway protocols. This means that the proposed gateway
supports the seamless gateway functionality by abstracting
different communication protocols and motion profiles.
V. ANALYSIS AND MEASUREMENT
In this section we analyze and measure the worst case
response time of the proposed gateway. The response time is
the time from when the Mechatrolink master program sends
a request message to the fieldbus based device to when it
receives a response message from the fieldbus based device.
A. Analysis of the response time
Table explains the abbreviations in the analysis of the
worst case response time.
TABLE III DESCRIPTION OF ABBREVIATIONS
Abbreviation Description
Tworst_response
Worst case response time from controller to fieldbus
based device using proposed gateway
Tm3
Time between the controller send Mechatrolink msg. to
gateway and receive Mechatrolink msg. from gateway
Tgw_fieldbus
Total time to spend for gateway, fieldbus communication
and fieldbus device
Tm3_request
Time for the controller send Mechatrolink request
message to gateway
Tm3_response
Time for the gateway send Mechatrolink response
message to controller
Tm2f
Time for the gateway forward Mechatrolink message
to fieldbus message including profile conversion
Tf2m
Time for the gateway forward fieldbus message to
Mechatrolink including profile conversion
Tf_request
Time for the gateway send fieldbus message to fieldbus
based device
Tf_response
Time for the fieldbus based device(e.g. Ezi-Servo) send
response message to gateway
Tm3_interval
Time interval between request msg. and response msg. for
Mechatrolink
Tf_processing
Time for the fieldbus based device process received
request message
Tcycle Configured transmission cycle time of Mechatrolink
The worst case response time can be denoted as equation
(1).

fieldbus gw m response worst
T T T
_ 3 _
+ = (1) o + | = _. (1) (1)
T
m3
can be denoted as equation (2). It consists of the time
for sending the request message, the time for receiving the
response message and interval time between the request and
response messages.

erval m response m request m m
T T T T
int _ 3 _ 3 _ 3 3
+ + = (2) o + | = _. (1) (1)
T
gw_fieldbus
must be

multiple of T
cycle
because the gateway can
send a Mechatrolink response message when it receives a
request message from the Mechatrolink controller. The
Mechatrolink controller sends a request message every T
cycle
.
If the gateway receives a response message from the fieldbus
device before it receives a request message from the
Mechatrolink controller, this response message can be sent
on the next cycle (receiving next request message from
controller). Therefore, T
gw_fieldbus
can be denoted as equation (3).
cycle
cycle
m f response f g proces f request f f m
T
T
T T T T T

(
(
(
(

+ + + +
=
2 _ sin _ _ 2
s gw_fieldbu
T
(3)
B. Measurement and result
In this section we measure the response time when the
Mechatrolink controller controls the Ezi-Servo using the
proposed gateway as figure 9. The configuration for the
experiment is described in table .
TABLE IV DESCRIPTION OF CONFIGURATION
Parameter Configured value
Tcycle 500 us
Mechatrolink request data length 48 byte
Mechatrolink response data length 32 byte
RS-485 baud rate 115,200 bps
RS-485 request data length 7 byte
RS-485 response data length 12 byte
1250

Figure 10 Measured performances
Figure 10 shows the measured performance of the proposed
gateway when the Mechatrolink controller sends a SMON
command to the Ezi-Servo. The SMON command [14] is
converted to the FAS_GetActualPos command [19] by the
profile conversion module. In this case, the measured response
time is about 3570 us.
T
m3
is even less than T
gw_fieldbus
, as shown in figure 10,
because the communication speed of Mechatrolink is much
faster than that of RS-485. Therefore, the response time
strongly depends on the baud rate, length of command of the
fieldbus and the processing time of fieldbus devices.
VI. CONCLUSION
In this paper, we proposed a seamless gateway for
Mechatrolink . The seamless gateway abstracts the network
protocol and profile. Therefore, with the proposed gateway, the
master can control all devices using a single network protocol.
In this paper, we implemented a prototype gateway between
Mechatrolink and an RS-485 based motor drive. Using the
prototype gateway master program could control both
Mechatrolink and the RS-485 based motor drive by using
Mechatrolink motion profile without any additional
configuration. The response time was analyzed and it strongly
depended on performance of fieldbus and fieldbus based motor
drive. The measured response time for the prototype gateway
when it send SMON command from the Mechatrolink
master to the RS-485 based motor drive was less than 3570 us.
ACKNOWLEDGMENT
This research was supported by MKE, Korea under ITRC
NIPA-2012-(H0301-12-3001) and PRCP through NRF of
Korea, funded by MEST(2012-0005861).
REFERENCES
[1] M. Felser, Real-Time Ethernet Industry Prospective, Proc. Of the
IEEE, Vol. 93, No. 6, June 2005
[2] PROFINET, Available:
http://www.profibus.com/technology/profinet/
[3] ODVA. Available: http://www.odva.org
[4] J. Jasperneite and J. Feld, "PROFINET: an integration platform for
heterogeneous industrial communication systems," IEEE Intl. Conf. of
ETFA, 2005.
[5] R. T. Qu and R. LIM, An architecture for the interconnecting
heterogeneous fieldbuses in industrial automation, IEEE Intl. Symp. on
CIRA. 2003.
[6] X. Xie, D. Deng and X. Deng, Design of Embedded Gateway Software
Framwork for Heterogeneous Networks Interconnection, Intl. Conf. on
ICEOE, 2011.
[7] S. S. Yoon, J. C. Lee, S. J. Cho and J. W. Jeon, Gateway between high-
performance Fieldbus and serial communication, Intl. Conf. of ICCAS,
2010.
[8] Anybus, Available: http://www.hms.se/
[9] NetTap, Available: http://www.hilscher.com/
[10] Ezi-Servo Plus-R, Available: http://fastech.co.kr/
[11] MMA-FLASH, Vol. 23, Aug. 2011.
Available: http://www.mechatrolink.org
[12] J. Jasperneite, M. Schumacher and K. Weber, Limits of Increasing the
Performance of Industrial Ethernet Protocols, Intl. Conf. of ETFA,
2007.
[13] Mechatrolink specification
Available: http://mechatrolink.org
[14] Mechatrolink Standard Servo Profile
Available: http://mechatrolink.org
[15] Mechatrolink Standard I/O Profile
Available: http://mechatrolink.org
[16] Industrial MINI I/O Connector
Available: http://www.te.com/catalog/pn/en/1981386-1
[17] IEC61800-7-201, Generic interface and use of profiles for power drive
systems Profile type 1 specification, Nov. 2007
[18] TMS320F2812 Datasheet
Available: http://www.ti.com/product/tms320f2812
[19] Ezi-Servo Plus-R Communication Manual
Available: http://fastech.co.kr/
[20] T. Sauter, M. Lobashov, How to access factory floor information using
internet technologies and gateways, IEEE Trans. Industrial Informatic,
VOL. 7, No. 4, Nov. 2011

1251
Powered by TCPDF (www.tcpdf.org)