Toshiba XLTR-200 사용자 설명서
25
RS485A port. And, because the RS485A 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 gateway’s RS485A 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 gateway, it can then be retrieved by any protocol (or ALL
the protocols) currently assigned to the gateway’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 gateway 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, any
new data value that is written to point #5 from any other port connection will
automatically cause a “write holding register” transaction to occur on the
RS485A 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 “NONE”. 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.
Although the various configuration possibilities may seem overwhelming at first,
it is clear that the gateway can perform powerful and flexible routing algorithms.
Through configuration experience, the “in” and “out” data flows will become
more clear.
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 gateway’s RS485A 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 gateway, it can then be retrieved by any protocol (or ALL
the protocols) currently assigned to the gateway’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 gateway 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, any
new data value that is written to point #5 from any other port connection will
automatically cause a “write holding register” transaction to occur on the
RS485A 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 “NONE”. 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.
Although the various configuration possibilities may seem overwhelming at first,
it is clear that the gateway can perform powerful and flexible routing algorithms.
Through configuration experience, the “in” and “out” data flows will become
more clear.
11.4 General Configuration Procedure
Now that we have had a brief tutorial on port and point configuration, we can
proceed on to how these elements fit into the overall configuration procedure.
The general configuration procedure steps can be summarized as follows:
proceed on to how these elements fit into the overall configuration procedure.
The general configuration procedure steps can be summarized as follows:
1. Access the serial console configuration interface via Hyperterminal or
other text-based console program.
2. Assign (or enable/disable) the desired protocols and their
characteristics to the specific communication ports.
3. Perform the desired per-protocol mapping and definition assignments
for each point, including the name, timeout and “source port”
assignments.
assignments.
4. Exit the serial console, which will update the gateway’s internal
configuration file and reboot the unit.