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.

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:

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.

4.Exit the serial console, which will update the gateway’s internal configuration file and reboot the unit.

25