1.1 How to Use This Guide
This user guide provides background information on how the gateway works, and an overview of the
configuration process. There are several sections for groups of tabs found in the web interface in the
gateway which is accessed by opening a web browser and browsing to the IP address of the device.
You should at least read the overview sections to gain an understanding of how the gateway functions.
You can use the remaining sections as reference material to look up as needed. There is a "Quick Help"
section at the bottom of each web page in the gateway which is generally sufficient for quick reference in
setting up the gateway.
Throughout this user guide, screen shots taken from a Babel Buster BB2-6010-GW are used to illustrate.
However, the same instructions apply to Babel Buster SPX-GW and Babel Buster SP-GW with each
available screen looking nearly identical.
1.2 Overview of Gateway Devices
The Babel Buster BB2-6010-GW, Babel Buster SPX-GW, and Babel Buster SP-GW are non-mapping
Modbus gateways used to simply forward Modbus RTU requests and responses to Modbus TCP, and vice
versa. Most Control Solutions gateways involve mapping, and the gateway itself contains registers or
objects which hold copies of data found in other devices. This intermediate data buffering is what allows
access to the same data from multiple protocols. The non-mapping gateway discussed here does not
contain any of its own registers. It simply forwards whatever request it receives to the other side and
simply repackages and retransmites exactly the same request (regardless of whether it was a correct
request).
The process of "repackaging" the Modbus request or response is illustrated below. The core of a Modbus
data packet is the same for RTU and TCP. It contains a slave address (or unit number), a function code,
and some data. The "data" is most often a starting register number, register count, and register data (if
writing).
If the data packet is being sent via Modbus RTU, the first character transmitted is the slave address, and
the last two characters are a CRC type checksum. If the data packet is being sent via Modbus TCP, there is
a TCP header at the beginning of the packet, and the last byte of that packet is the same slave address or
unit number that would have been sent via RTU. The RTU checksum is not included because Ethernet has
1. Overview
file:///C:/AAA_CSI/Literature/2015 User Guides/BB2-6010-GW User G...
1 of 2
12/23/2015 9:28 AM
