Toshiba T300MVi - Manual (Page 28)

15
if an Ethernet/IP connection consumes new data that changes the value of a
point, how do we know where this new value will exit the interface to arrive at its
final destination? The answer is that any new point values written by “slave”
protocols will generate “write” transactions only on the “source port”.
This concept may best be further explained by way of a representative
scenario. For example, let’s assume that the interface’s RS485 port has been
designated to be a Modbus Master. Let’s further assume that the “Modbus
Master” portion of point #5 indicates a “Source ID” value of 8 and “Register”
value of 14, and that point #5’s “Source Port” selection is set to “RS485”. What
this means is that independent of any other interface traffic, point #5 will
continuously attempt to update its internal value by making requests to the
RS485 port. And, because the RS485 port has been designated as a Modbus
Master, then the “Modbus Master” portion of point #5’s configuration will be
referenced by the update task, and point #5’s value will therefore always be
mirroring the value of holding register #14 of remote Modbus station address #8
connected to the Modbus subnet attached to the interface’s RS485 port.
Perhaps holding register #14 of Modbus station address #8 is a monitor item,
indicating the pressure in compressor tank. Whenever the tank’s pressure
changes, therefore, the value of point #5 will automatically update to reflect the
new value read from the remote device. Once the tank’s pressure reading has
been brought into the interface, it can then be retrieved by any protocol (or ALL
the protocols) currently assigned to the interface’s other communication ports.
As a modification to the previous example, let’s assume this time that holding
register #14 of Modbus remote station address #8 is the speed command of a
conveyor belt. In this case, point #5 of the interface will be mirroring the current
speed command of the conveyor, in a similar fashion to how it previously
mirrored the compressor tank’s pressure. This time, however, the speed
command represents something that can also be written to. Therefore, let’s
assume that point #5 has been included in the output assembly member list of
the Ethernet/IP protocol, and that a new data value is consumed by an
Ethernet/IP connection object that causes the value of point #5 to be changed.
In this case, this new point value will automatically cause a “write holding
register” transaction to occur on the RS485 Modbus master port, updating the
value of holding register #14 on remote Modbus station #8, causing the
conveyor to accelerate (or decelerate) to the new speed.
Note that it is also perfectly acceptable to have a point’s “source port” assigned
to “no source”. All this means that this point will not be autonomously updated
(i.e. that it will not automatically mirror anything.) In a sense, it will simply be
“scratchpad memory” that the various ports and protocols can use to exchange
information among themselves. For example, a Modbus TCP/IP write
transaction could update the value of such a point, which then can be inserted
into the produced assembly data of an Ethernet/IP connection, causing the
interface to act as a Modbus TCP/IP –to- Ethernet/IP router, while
simultaneously performing its other network functions.
Although the various configuration possibilities may seem overwhelming at first,
it is clear that the interface can perform powerful and flexible routing algorithms.