57
ICC
8.7.9
Mitsubishi MELSEC/SLMP Client
The MELSEC client protocol can be used to access information on Mitsubishi
PLCs and motion controllers which support the MELSEC server protocol using
3E and 1E frames. The MELSEC client protocol also supports SLMP (Seamless
Message Protocol) to communicate to CC-Link IE Field networks via an Ethernet
adapter that supports the SLMP server protocol using 3E frames. Both MELSEC
and SLMP can be used simultaneously. Similar to other master/client protocol
drivers on the gateway, the MELSEC client driver uses service objects to issue
read and write requests to the MELSEC server device. MELSEC service objects
also make use of an additional gateway construct called a “connection object” in
order to target MELSEC server devices. A connection object can be thought of
as a communication channel or “pipe” which is created between the gateway and
the MELSEC server device, independent of the service objects that may later
make use of that communication channel to transfer service object requests.
A connection object defines a connection to a specific endpoint (IP address and
port). Multiple connections can be established with a single remote MELSEC
server device residing at a given IP address: as long as the assigned port
number in each connection object is unique, then the connection objects will be
accessing non-conflicting endpoints, and will therefore be independently
managed within the gateway.
Because service objects must always be configured to utilize a specific
connection object, at least one connection object must initially be created before
any service objects can be created. For more information on service objects,
refer to section 8.5.
Figure 10 provides a graphical representation of the MELSEC client concept, and
demonstrates the associations among service objects, connection objects,
MELSEC servers and internal server devices. This example system contains five
service objects, four connection objects, and three MELSEC servers (MELSEC-
capable PLC’s or motion controllers). The “internal devices” in each of the
MELSEC servers can be any of the supported internal device types (data
registers, internal relays, motion registers, etc.)
The blue connections in Figure 10 show a situation in which two gateway service
objects have been mapped to two internal device types on a single physical
MELSEC server. In this case, both service objects share a single connection
object. The advantage of this configuration is that connection object usage is
minimized, thereby allowing connections to more physical servers. The
disadvantage is that these service objects must be serialized (first one is dealt
with, and then the other), as a single connection object can only process one
request at a time.
The red connections in Figure 10 show a similar situation (two service objects
mapped to two internal device types on a single physical MELSEC server). In
this case, however, two separate connection objects have been defined for
MELSEC server #3 (each with a different destination port number). This allows
each service object associated with MELSEC server #3 to have its own dedicated